James Balestriere breaks down what makes a good Epic.
Epics are a powerful management tool that can provide teams with big-picture detail. I looked for guidance on how to write good Epics and found very mixed descriptions. There is even disagreement on how big an Epic is. Where I find agreement is “Epics are often thought of as user stories that are too large or too complex.” but, what makes a good Epic?
This was the question I asked myself a few weeks ago when I was working with some clients building out an MVP and the corresponding product roadmap. The development team was happy and understood the roadmap, but the business stakeholders were clearly not happy — something in the MVP was not meeting their requirements. The backlog was deep and feature-rich with Release Markers and milestones in place. They had full access to review every story and to advise us on the priority but something was missing in the communication.
I thought I had fixed the problem; which was to move the established MVP line to include a few features we “non-domain experts” considered irrelevant, but they still weren’t happy. I was staring at my Epics wondering why the roadmap was not obvious when it finally dawned on me. Even though every story had a business reason, the Epics were written to be solution-centric. We had a prescriptive list of Epics that read like
· Feature A
· Feature B
· Feature C
If you drilled into the Epic you could see the business value from the user stories but a casual user would not do this. A casual user was looking at Epics as a list of milestones that needed to be burned down and missed the nuances of the Release Markers. They saw Epics as milestones — not the Release Markers. In hindsight I can understand why, especially when you consider the relative prominence of Epics vs. Release Markers.
I’m going to digress for a moment to add some background. The traditional way is to use the Epic to hold a functional decomposition for a feature. This is great because you quickly identify all the possible bits of functionality you may ever need for that function, and because it is localized you can quickly detect and add escapes.
The mock project below shows how I quickly generated a bunch of user stories based on an Epic. (Let’s not get hung up on the stories themselves, as I want us to focus on the Epics.)
The big question for a Lean Practitioner is, how many of these stories do I really need right now?
When you “go lean” one of the things you start to notice is that functional Epics tend to get to 30–40% complete and never really complete. You never build all the things you could build so something is perpetually in the Icebox.
In this case, as we top-down decompose the story we realize there could be two Epics, an admin account, and a user account. We could shuffle things around into two Epics and won’t end up with as many “iced” stories and Epics in the 30% state.
You now get the results of your customer research. What does our ideal customer really want to do to manage their account?
We find out they want to register and manage their email subscriptions. They rarely edit their account and they do not want to talk to someone who can manage their account on their behalf. Some think they might want to close their accounts. You have been advised to never close or delete an account, as you will lose stats and contact information. Shuffle the backlog again.
Sure enough, we end up with one Epic that will get to 40% complete and a lot of stories that perpetually sit in the Icebox. The backlog looks good; the roadmap looks challenged because you never complete an Epic.
What if we changed the Epic style to be Problem-Centered?
In our scenario, let’s write some new epics but from a perspective of “What problems are we solving?”
Now shuffle the earlier stories derived from functional decomposition into the Problem-Centered epics.
I now have a set of Epics that could be driven to 100% complete.
What I find really satisfying is that I am able to consume all the functional stories and at the same time define a priority order based on business (problem) value.
Let’s go back to my problem with the stakeholders. What would happen to my backlog if I reframed the Epics to be problem centric?
It turned out to be less disruptive than I had originally thought. All of my stories stayed the same. I changed the Epics to be more Problem/Business-centric and matched the way the business viewed the first deliverables. My Epics were problems we would solve on the way to the MVP and post-MVP. We no longer talked about Release Markers. Some of the strange functional Epics (epics which were mostly Icebox or would need to be returned to) started to disappear and I could now quickly explain to anyone how we progressively added value. Post-MVP features became an ordered list of business problems and the market segments we would progressively incorporate.
Suddenly, things quieted down. Casual stakeholders could now look at the Epics and derive the roadmap and assess the business value themselves. We explained they were free to prioritize the Epics after the MVP however they wanted, and got the response “We don’t understand why we need so many prioritization meetings.” Just goes to show, once you can establish effective communication you need to communicate less.
To summarize,
· Don’t stop doing functional decomposition. Use it as a tool in your utility belt but not as the final tool.
· Break your project into functional pieces and additionally break your product into a set of user problem that need to be solved along a path.
· Prioritize your user problems then populate them with the functional details.
You now have a product roadmap that means something to the business stakeholders and is also functionally complete.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
How to Engage Business Stakeholders Through the Use of Epics was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
