Do epics tell the story?

In the previous post, I started exploring the way many Agile methodologies and tools structure work items as hierarchical to-do lists and the consequences of it. I looked at the way the structure encouraged a short term completion mindset and made it harder for teams to keep aligned to the product vision. I said we would be looking at some fundamental concepts to see what opportunities for improvement might exist.

The second opportunity we are going to look at considers the role of language and vocabulary. It goes without saying that words are important and our choice of words can affect how well our message is received. So let’s take a look at some language constructs common in Agile today.

Metaphors are a literary tool that are used to help understand a complex topic by relating it to something that is already familiar. In technology, metaphors often become abstractions and show up in code, in patterns and, as it turns out, in the tools we use. In all cases, they are supposed to help understand a specific topic.

Epics and stories are the go-to metaphor for planning software development activities today. It is a concept that has been part of the agile vocabulary since the early days and is familiar to all developers, project managers and product managers.

The purpose of a story, or user story, is to describe a small aspect of a system being built in the style of a narrative about the user’s interaction. Storytelling is a great way to communicate ideas, and it’s something that people have done for millennia. It’s a very relatable way to focus on something from the perspective of the customer.

Where a story is intended to be small - something that can be completed in a sprint - the original intent of an epic was that it was a big story. Something that was too big to fit into a single sprint. Put another way, an epic is the same as a story, only bigger and longer.

If we only consider the application of stories and epics to software development, the metaphor works. There are small work items and big work items, and they are expressed in a meaningful, story-like way. Of course, stories and epics are just one part. There are many other aspects of Agile development. So let’s consider how well it expands if we consider the broader ecosystem.

Recall that whether something is a story or an epic depends only on if it fits in a sprint. A sprint is another commonly used Agile term, but outside of Agile, a sprint is unrelated to storytelling. Sprinting is more readily associated with athletics, the Olympics or sport. It does not fit with the literary story metaphor.

If the intent of an epic is that it is a big story that cannot be completed in a single sprint, the implication must be that an epic is indivisible. If that wasn’t the case, then it would have been broken down into stories and the epic wouldn’t be necessary.

In practice, what most projects do is introduce a hierarchy into the relationship between story and epic. We have already discussed the limitations of hierarchies, and I’m not going to repeat that here. In the context of a literary metaphor, introducing a hierarchy here breaks the original intent of an epic as a large, indivisible piece of work. In an Agile project today, an epic represents a grouping of stories. In a literary metaphor, it is more like a series.

Where the literary metaphor really starts showing its limitations is when attempts are made to scale it. Take features for example. All products have features. So the concept of a feature as it applies to a product is understood. But as part of a literary metaphor, it doesn’t fit. Outside of software development, there is nothing that combines epics, features and stories. Even within software development, they are not defined consistently - sometimes feature is above epic, sometimes it is the other way around.

A metaphor is supposed to help understand a complex topic by relating it to real world experiences. The original story/epic metaphor could do this. Over time it has expanded and evolved into what we see today. Most Agile teams have been conditioned to use stories, epics and features. It no longer functions as a metaphor; it is now a hierarchy to scope groups of items in a to-do list.

Some may say “It’s only a metaphor, and no metaphor is perfect”. Does it really matter?

Here’s the thing: building software is not just about writing code and saying it is done. A huge part of a successful project comes down to communication, collaboration and alignment of everyone involved. There is a good reason why the Agile Manifesto values “interaction and collaboration over processes and tools”. It is within the interactions that the value will be discovered and for them to be effective there needs to be a common vocabulary to describe the product and the vision.

As much as this post has talked about tools and processes, the intention is for them to facilitate and support interaction and collaboration. These are not independent things. The output of any collaboration activity should be represented in the tools, and the tools should help inform discussions and decisions about the product. If there is any participant at any level, be it a developer, tester, business analyst, product manager or stakeholder who cannot easily use a common tool to find something that matches their understanding of the product, it increases communication friction and makes collaboration harder.

Stories and epics are simple for developers, but any hierarchy above that starts to lose relevance. Stakeholders will understand features and objectives, but the progression of epics and stories to deliver them is too complicated.

Does it matter? Yes, it does. Especially when you consider how much more cohesive collaboration can be under a suitably structured and unified metaphor.

Next: The Path to a Better Way

Previous: How Hierarchy Hurts