Epic-driven development is popular. Partially, such thinking is promoted by the so-called “agile” tools like Jira that have built-in features for roadmap management with epics.
So, what is the problem with the epics?
#1 Epic-driven product backlog will promote large-grained prioritization (same as sequential projects)
Note: the text below and the images describe an antipattern: how not to manage product backlog.
That means that such a backlog will contain a list of epics. Top managers will love it! They won't have to understand the nitty-gritty details. But they all can understand statements, like:
the teams are currently working on the epic 'introduce new payment methods'
the next quarter, the teams will start the 'adapt the product to new legal requirements' epic
The management can understand that level of abstraction. And this is too bad. Because this also implies they believe know how to work with them.
Those epics represent some relatively large scope of work. They look like projects that need to be managed. Luckily, many organizations know how to do it – the scope of each epic (now project) needs to be detailed, estimated, planned and implemented.
I saw many product development organizations that should not have any projects going. But all they do is project management. Why? Partially, because they think of and work with epics. But epic-driven development triggers other interesting dynamics.
#2 Epic-driven product backlog will promote implicit sub-backlogs
You have a product backlog with epics, that are understood by the management.
However, the teams, in order to work with them, will have to split them up. So, here comes the split: each epic receives a list of user stories – smaller pieces of scope. Those can be ordered based on estimated relative value. And someone who manages that backlog will likely arrange them in lists.
Lists. In plural. Where each epic can be double-clicked to open a sub-view that represents a list of associated user stories.
So, how many backlogs do we have now? You can say “one with sub-lists”.
I say: “as many as there are refined epics plus one”. Simply put: we have many backlogs.
The big idea of a product backlog as a list in Scrum is that with a single list ordered by value, everyone knows the priorities. That creates a strong alignment and clear focus. It makes everyone work on the most valuable thing. Yes, priorities is a guessing game, but still working on guessed priorities is notably better than to work chaotically on whatever.
So with a single ordered-by-value product backlog, one can control investments to product development.
But now, with many backlogs, it is less so. You can also be hearing things like:
“We need to focus on one thing”
“Limiting the work-in-progress (WIP) is required for better flow”
“Stop starting, start finishing”
So one could deduct that if the Epic A is more important than the Epic B, then working off the sub-list A before moving to the sub-list B is the right thing to do: better focus, less WIP, etc. That is intuitive, and most people would agree with that logic.
But do you see the trap yet?
#3 Epic-driven product backlog triggers the law of diminishing return
When the epics are seen as sequential projects, the law of diminishing returns kicks in. Allow me to explain.
If the person who manages the backlogs (the sub-lists with stories) was doing her work correctly, then each sub-list is ordered by (guessed) value. Is that a safe assumption? I'd say so.
So, the people who work on those stories (s) are likely pulling them in that same order. And those people will assume they are working on the highest value first. But are they?
What are the chances that the tail of a more valuable Epic A is less valuable than the head of the next Epic B? Think of that.
It depends. But if the epics are big, that probability of that is not zero! The tail of an Epic A can be less valuable than the head of the next Epic B.
And what does that mean? Oh, but that actually means that the efforts of a team (or even many teams) can be spent on something of higher value. How? By dropping the Epic A in the middle and switching to work on the head of the Epic B!
But what is your guess: will the team(s) drop the Epic A to switch to the next one?
Read on: try impact-driven product backlog.