Epics Vs Stories – keep it simple stupid

Epics_vs_storiesEpics vs Stories – what’s the difference?

It’s one of those perennial discussions in Agile. Epics vs Stories. What’s the difference between these two types of requirement in Agile Development? In this article, they describe Themes in addition to Epics and Stories. So now you have Themes, Epics and User Stories. And of course some teams break User Stories down into tasks as well. So lets recap, that’s Themes, Epics, Stories and Tasks. Oh I forgot to mention that other teams also define Technical Stories!

Like the article referenced above many people try to make a distinction between all these things. But lets consider first what are Stories for and why have we ended up with different ‘types’? Then I’d like to explain how we try to keep things much simpler.

What are stories for?

It might be more prudent to try and argue the difference between a User Story and a Use Case but that’s a well trodden path. User Stories are here to stay and very popular for good reason. Fundamentally a User Story is a software requirement that describes something that needs to be delivered by the development team.

What makes User Stories different, from previous ideas of requirements, is the narrative that surrounds the idea of using Stories to ‘do’ Agile Development. By this I mean that every time anyone asks what a User Story is there is a cacophony of enthusiastic voices extolling the importance of the conversation. As one seasoned agiler once said to me “a User Story is the promise of a conversation”.

Others may say that the importance of the User Story is that it’s from the ‘user’ perspective, or that it’s a story rather than a formal Product Requirement Document written in abstract business terminology. What I see is better communication. Better communication between the business and the engineers, better communication between customers, users, Product Management and the team who have to build the requirement.

The User Story construct is simple, therefore easy to remember and, once you’ve got the hang of it, easy to implement. And once you’ve written User Stories, have you ever had to explain to a non-techie what they mean? As I say the narrative that follows the User Story around, like a rather pleasant smell, adds to its efficacy.

Simply put the purpose of a User Story is to effectively communicate value adding requirements, without ambiguity, in a form that is easy(ish) to estimate.

Why have different types of stories?

The main reason appears to be a conflict between ‘effective communication’ and the ability for an engineer to estimate the amount of work. Part of what makes agile so agile is that work tends to be broken down into small chunks that can be delivered in a short space of time. Instead of building a vast sprawling metropolis of features and functionality that no one uses, you deliver small parts that incrementally deliver value. If any of these small parts fail to deliver the expected value they can be easily brushed under the carpet out of view a lot easier than 100,000 development hours. What’s more, you’ve failed fast and, hopefully, learnt a valuable lesson.

Effectively communicating requirements requires storytelling, but storytelling doesn’t always come in small parts. So when a Story appears to be too large to deliver incrementally (i.e. too big to effectively estimate how long it will take to build) then it becomes an Epic. Or is that a Theme? I was once told that a Theme is a collection of Epics but others will say that a Theme is a different type of collection of stories…

Then, of course, some teams may break a Story down into tasks, sort of sub-stories, that they can deliver in the next sprint but the value is not realised until the main Story is finished. Sounds a bit like an Epic? Well it would be if the parent Story didn’t already belong to an Epic…

You can see the problem starting to emerge… confusion. If Stories are to support effective communication then they need to be simple. If we now have to explain to various audiences the differences between the levels that makes communication so much harder.

So what can we do?

Here at Skore Labs we prefer to stick with User Stories, the difference is that we accept that stories can be deconstructed to create more stories. One story can be made up of multiple smaller stories. And this deconstruction knows no bounds. We don’t force our stories into an arbitrary set of levels (e.g. Epics, Stories and Tasks, the story telling analogy ran out of levels pretty quickly). We keep deconstructing stories until we can effectively estimate how long they will take.

We do something else that’s different, we link stories together into visual flows. This may seem more like use case flows, or story mapping, but as we deconstruct stories these flows provide valuable context that would otherwise be lost. When you’re down in the detail you need to make decisions on whether individual stories can be delivered quickly or whether they rely on upstream or downstream stories.

We believe stories should be kept simple so as to facilitate communication, discussion and reduce ambiguity. This is our solution we’d love to hear how you deal with this?

Leave a Reply