The doomed land of fixed-scope projects
I've described earlier why to avoid epics-driven development. Now let's discuss how to do it. But before, here is one key reasoning on why working with epics is harmful for your product development:
When you manage your product backlog with 'epics' (which are essentially bulky items of work), then you are constantly making very difficult and expensive investment decisions. Say, if an 'epic' is worth just several sprints of work for a team, then its development costs are already in some tens of thousands of euros. These items and the associated investment decisions hold significant outcome uncertainty and execution risks. Therefore, it is not a surprise when your business stakeholders want to manage them in the most controlled way they know. And what's that? As fixed-scope & fixed-time projects.
This can also be reinforced by the product managers, who are used to communicate their roadmaps with an estimated duration of each epic along the time axis. The Gantt charts of the 21st century.
So by managing (or rather: trying to manage) those fixed-scope & fixed-time projects, you have quit the space of continuous product development with fast feedback. You are no longer practicing iterative-and-incremental (agile) development. You are now in a shaky project business, managing execution of a predefined output. Instead of managing for high value with less output.
Think impact, not scope
Many product companies these days do grasp the idea of the impact. But on the operational level, they still have issues connecting impact to tactical planning. So, they typically end up with a half-backed solution:
they use some sort of goal-setting technique (e.g., OKRs) on the strategical level,
and still rely on an epic-driven product backlog for the tactical, operational level.
Such mixed approach implies using the modern terminology (OKRs, epics). But under the hood, it is basically no different from the same project management with guessed scope and artificial deadlines. You can say that such a blend of methods is even worse for an organization. Because some managers and employees will truly believe that they “do agile”.
So, is there a way to come up with a holistic approach? Where the work can be naturally and continuously derived from the impacts? Where the benefits of iterative and incremental approach can be yielded? With the focus on learning acquired in the process of building the product? Without the process wastes that the scope management inevitable brings?
Holistic approach to derive product backlog items from impact
You are, probably, familiar with the Impact Mapping technique? Goals → Actors → Impacts.
The illustration below is focused on the right side of the mapping: from the impacts down to the candidate product backlog items (PBIs).
With this approach, the set of impact is what gets discussed and communicated to the business stakeholders, not the commitment of scope to a deadlines.
Examples of such impacts:
make existing users recommend the product for the viral effect
reduce dead-on-arrival user rate (with better onboarding)
make users in Mexico use the product that doesn't break the local tax requirements
increase rate of opened and read marketing emails
Note how these impact items are not prescribing the scope.
They might assume some product features – like the 2nd item with a better onboarding. Or the 3rd item with an implementation of the tax requirements. But they are not scope definitions per se. And that leaves a lot of space for the empowered product teams to figure out what needs to be changed in the product for these impacts to be reached. This is product engineering. This is good.
It is only when a team (or a group of teams in a multi-team setting) gets together for a refinement session, the product backlog item candidates got identified. Those emerging items are derived from the impacts. They define scope. But they are small, so they don't have a lot of execution risk in them to be controlled with a heavyweight project management method. A team can sprint on them and deliver a handful of those in a few days, maximum weeks. Pure Scrum can be used to help manage this.
Interestingly to know, these product backlog items typically come in two shapes:
experiments to implement and run to (in)validate a hypothesis
specific product features to implement
So, not everything a product team does are experiments and hypothesis testing. Occasionally, you will need to build a specific feature that satisfies some external requirement (e.g., a tax law in Mexico). And it is fine. But those features are defined by the teams in refinement. And this leaves a hope, that the engineers will find some creative simple and effective solution that realizes that complex requirement with very few product changes.
The product management mantra of maximizing outcome, minimizing output can be finally made real.
From impact mapping to requirement bubble maps
The above described technique links the impact mapping with the requirements-as-bubbles method that I've co-invented with a colleague of mine and back in 2018.
And by the way, since 2018 we have coached many of our clients to use this (awesome) backlog visualization method:
This technique helps to start having more meaningful product backlog refinement sessions where all the participants see the whole picture – share the same context.
This is because the 'bubble map' holds all the logical connections of larger items split into smaller ones. And this way, your regular refinement sessions turn into a continuous work of splitting large items, creating new smaller bubbles and detailing them. And then your sprint planning becomes literally a relatively simple process of finding small-enough and clear-enough items that worth building in the next sprint.
Now, connecting the bubbles with the impact mapping turns this into a holistic approach that fits all. You can track the work from the goals to actors to impacts down to specific backlog items of different granularity and clarity.
Give it a try. You will love this.
Do you still need epics?
With the simple yet powerful approach described above, do you feel like you still require epics?
If yes, probably, it is a symptom of some deeper organizational dysfunctions that need to be addressed by your scrum masters and managers.
A common example of why an organization might believe it needs a roadmap with epics (scope and time) is an inadequate team composition (i.e., component teams).
In such a set-up, the teams are not autonomous (not cross-functional, not cross-component) enough to implement a meaningful product change that satisfies an impact. So in order to implement that change, many teams have to be involved. And furthermore, it is very likely that each of those teams have its own “manager who owns a list of work for his/her team”. I won't call them “product owners” because they are not. They are sadly more of “team output owners”.
So to coordinate work across those inter-dependent teams, some sort of timeline with work and time needs to be set up. And here comes that roadmap with scope commitments.
If this is your case, then you need to address the root cause – the inadequate team composition. Only then, the above-described method of “impacts to bubbles” will work.
Then simplify your organization
And this advice can be generalized – if you feel like the above method of “impacts to bubbles” is far too simple and “it will not work in the real life” because of “x”…
… well, then you must simplify your organization, by removing that “x”.