We talk a lot about slicing stories but then when it comes to slicing larger types (epics, features, etc), we tend to wave our hands and say “it’s the same, only bigger”, which while true, is rarely helpful.
Recall that a story is the smallest piece of value passing through your workflow. By extension, any larger types must also be the smallest piece of value at that level.
An example will help. Imagine that we have Epics that are made up of Features and that those Features are made up of Stories. So we have a hierarchy like this: Epic → Feature → Story.
Note that there is no defined hierarchy of story-like items. The Epic / Feature / Story hierarchy I describe here is fairly common but is not required and what you do in your company may be different.
In this example, Stories are the smallest unit of value that a team can implement. A feature will be made up of many stories and will likely span multiple teams. It needs to be something that is also valuable on its own however. An Epic will be an even larger unit of value, composed of many features.
Using a hierarchy like this, one of my clients once decided to enter a new market. They created an Epic to “Enter the German speaking market”. This is an extremely large piece of work but it’s clear that what the value is. Once the company had successfully entered that market and was signing up customers, that Epic would be done.
Then they created a number of Features within that Epic. Each of those features covered pieces of value that were required to satisfy the Epic. They had Features about changing printed materials and preparing systems to accommodate this new language. Each of these features were distinct and it was clear when each one would be done. They were still too large for a single team to work on them and so they were kept at this level.
Then the teams created their own Stories, based on the Features. Each of these delivered one small piece of value that when combined, would complete the Feature.
So at each level, the work items (stories, features, epics) each had value on their own. They were the smallest unit of value that could be achieved at their respective level.
At every level, the work items must be the smallest unit of value, for that level
You’re probably thinking that this seems pretty simple so far, and yet almost every company does it wrong.
The specific thing they do wrong is that they treat higher level types as just containers of “stuff”. They’ll create an Epic for technical debt or a Feature of bugs. There is no distinct unit of value to these - they’re just being used as a container.
Why does this matter?
We already know that there are great flow metrics for stories, that give us all kinds of actionable feedback — we can make effective decisions from these metrics. Additionally, we can use probabilistic forecasting to determine when the work will be done. These are significant benefits.
We can use all of those same flow metrics and the same probabilistic forecasting at each level, if each level is made up of value. We can look at throughput of features or cycle times of epics. We can generate good forecasts at the Epic and Feature level, which at some points in the planning cycle are far more valuable than the equivalents at the Story level.
The moment we start using higher level work items as dumping grounds of “stuff”, however, all of those metrics and forecasts become useless.
Sometimes we make a conscious decision to misuse our epics and features in this way and sometimes we fall into by accident. I’ve seen features explicitly called “Bunch of stuff for X”, where it was very deliberate that we hadn’t tried to find value.
The accidental case is more interesting. Imagine a feature “Translate all reports to German”. It appears to have clear value and we can tell when it will be done. Then imagine that when the work is in progress, we determine that we aren’t going to convert one of the reports at this time. For us to maintain clear value on the feature, we would have to remove any stories related to that report so that we could close the Feature off. Yet, what we often see is that the Feature remains open indefinitely — it’s now just become a container of stuff. This messes up any metrics that we might have used to make decisions.
If you allow your epics and features to just become containers of stuff then you lose the ability to make actionable data-driven decisions from those items.
If you’re in the position of not needing to make effective decisions off these high level items then you should really question why you have them in the first place. It’s a lot of extra work to maintain a hierarchy if it isn’t providing any value.
Once you do have an effective hierarchy, with well sliced work items at all levels, then this puts you in a better position to scale1 the flow of your system.
-
See Scaling Simplified: A Practitioner’s Guide to Scaling Flow by Prateek Singh for a great introduction to scaling the flow of your system. ↩