In my role as Agile Transformation Lead at AgileNX, I’ve observed a pattern among several development teams where ‘Epics’ are being used to simply to organize related stories. Creating meaningful Epics is something we’re passionate about, so simply grouping a bunch of stories together into a “bucket” type thing doesn’t seem to add much value.
In this article, AgileNX explores how to get the most out of an Epic in today’s agile practices. Traditionally, Epics are stated simply as a ‘Large Story’ which might represent a new feature, customer request, or some business requirements that have a common objective. These Epics are then broken down into smaller Stories. The theory behind this sounds good, but in many Agile workflow tools such as Jira, the tendency is to use Epics to categorize, rather than to represent bodies of work.
The first question to ask is “why should we use epics in our agile practices at all?”. In the spirit of agile, everything we do should deliver value. This is normally focused on customer value, but it’s fair to say that the agile practices themselves must deliver value to the business, the team, AND deliver customer value. Therefore, if we invest time in creating and maintaining Epics, they must yield value. Let’s imagine for a moment that as a product owner, you’re tasked with planning a new feature set. Typically, one would visualize a chart with a series of blocks representing the things that need to be built, either in a linear timeline, vertical stack, or combination of both. Thus, we can surmise that the concept of Epics is inherent to outlining scope.
Transposing these outlined blocks into an agile workflow is where things can go awry. Tools like Jira force a hierarchy between epics and stories, so it’s not possible to prioritize an epic among stories, and unfortunately, that’s where the bucket phenomenon creeps in.
To gain ongoing value from an Epic, the practice that AgileNX suggests is to establish a boundary of what the Epic represents. The first step is to write a one or two sentence description of the “what” and the “why”. Once you’re happy with it, craft the title of the Epic. Wait, whoah! Write the title after the description? Yes, in the same way as an executive summary is written for a white paper. Synthesize the description into a meaningful title so that anyone on the team can understand what it’s about.
Next, add a bullet list of capabilities that will be delivered from the Epic. These capabilities are what drive stories, a single capability may require one or several stories, and that’s OK. What’s important is that at a point in time, one can safely state that a capability is delivered. So what happens when a capability grows or a new one emerges? Well now you have an alarm bell for scope creep! These changes can be added – as long as they continue to deliver on the common objective – but with the understanding that there will need to be trade off in prioritization.
Using this pattern, the product owner can assess delivery progress of a body of work and if needed, prioritize the capabilities within the Epic or consider removing one or more of them in favor of something that delivers more value. The pattern enables independent prioritizing of stories from multiple Epics in a backlog and works well for Scrum and Kanban. This approach adds some overhead, but it’s fairly lightweight and yields high value for the business and team by providing insight to progress, prioritization, and achievement when all the capabilities are delivered.
AgileNX is the Agile Transformation Group of Syrinx Consulting.
For more information on AgileNX, call Matt Berg at 781.487.7800, ext 15.