When we have a large amount of work, we need to break it into smaller pieces. If we know that what we have in mind will create the outcome we want, this is fairly straightforward. We can define the solution, divide it into manageable parts and implement them.
But when the outcome depends on how people behave or how a complex system responds, we cannot know the effect upfront. We can have data, experience and good reasons to believe our idea will work, but until people start using it and the system starts responding, we have a hypothesis, not an answer.
A requirement describes something we have decided to build. A Main Requirement can be broken down into System Requirements and then into increasingly detailed requirements. The pieces become more manageable, but they remain parts of a predefined whole. We build the parts, integrate them and test the complete solution. The logic is essentially: define the solution, break it down, build the parts, integrate and test.
An outcome-oriented Epic starts somewhere else. Rather than defining what to build, it defines the change we want to create. For example: Increase the share of first-time restaurant guests who return within two weeks from 18% to 35%. We know what we want to achieve, but not everything we need to build to get there.
This means we cannot simply break the Epic down into all the Stories required to complete it. We don’t yet know which Stories will be needed. Instead, we choose a small piece of user functionality that we believe could move us towards the outcome. We deliver it, see what happens and let what we learn influence what comes next.
The work becomes both incremental and iterative. Each slice adds working functionality and gives us an opportunity to learn before making the next decision.
The question is not how small the pieces are. It is what they are pieces of.
In breakdown, the pieces are parts of a solution we have already decided to build, and we may need to integrate them before we can test the complete solution. In slicing, each piece gives us something working that allows us to see whether we are moving towards the desired outcome before deciding what to build next.
Starting from an outcome also leaves more of the problem-solving with the team. Instead of receiving a solution whose important decisions have already been made, the team can use its collective expertise, together with feedback from users and the system, to decide what is worth building next.
And sometimes the most valuable thing we learn is that we don’t need everything we originally imagined.
If three Stories create enough of the desired outcome, there may be no reason to continue with Stories four through ten. They are not unfinished work. They are work we discovered we did not need to do. This is how we maximize outcome while minimizing output.
The difference can be surprisingly easy to miss. We can replace requirements with Epics and Stories, make the Stories small and deliver working functionality one Story at a time, while still deciding upfront what the complete solution should contain.
If completing all the predefined Stories means completing the Epic, we are still working towards a predefined solution. Learning may influence how we implement it, but it cannot answer the more important question: Should we build the rest of it at all?
That is The Work Breakdown Trap: we think we are slicing towards an outcome, while we are actually breaking down a solution we have already decided to build.
The real shift is not from large pieces to small pieces. It is from breaking down what we think we need to build to discovering what is worth building next.
More traps
The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.
See the bigger picture
The Work Breakdown Trap is one example of what can happen when we change the way we work without fully changing the underlying logic.
Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives — including strategy, execution, governance, teams, funding, culture and organization.
