Most business and product leaders get the concept of Outcome Roadmaps and how they help connect Product Strategy to a plan to execute. However, they have difficulty shifting to this approach in practice.
One reason for this is that it is unclear how to translate a roadmap filled with outcomes into an Agile development process. After all, when code gets ultimately written, it must be guided by some definition. Right?
Note: I leverage some terminology and practices from Scrum in this article. However, concepts from this approach should not be viewed as Scrum specific.
Sprint Planning
Taking a look at the typical Spring Planning process, the team contemplates which items in the Product Backlog should be placed into the Sprint Backlog. The Product Backlog is comprised of a prioritized list of outcomes to be achieved by the team. While the Sprint Backlog contains a forecast of functionality to be built, commonly described in terms of User Stories.
How to get from Outcome Roadmap to User Stories?
When working from an Outcome Roadmap, we can see that it is actually a time horizon way of planning for the desired outcomes contained in the Product Backlog.
Note: In practice, the Product Backlog does contain additional work that needs to be done by the team. For this article, I am simplifying and only considering the Outcomes.
In the vast majority of cases, it will not be possible to analyze the desired outcome and immediately arrive at a list of user stories that will achieve it. Since the Sprint Planning session will be time-boxed to less than a day, some of this work clearly needs to be done in advance.
How do we fit this discovery work in between the Product Backlog and Sprint Backlog?
Dual Track Development
The solution, it turns out, is quite logical, and is commonly referred to as Dual Track Development. Jeff Patton is widely credited with creating and evangelizing the concept but he credits Desirée Sy. In short, it says that the Product Team must engage in two separate parallel streams of work (1) Product Discovery and (2) Development.
Product Discovery
In Patton’s model, Product Discovery work begins with Opportunities (e.g. ideas, problems to solve). The slight adjustment we need to make here is to start back one step with the desired Outcomes. Identifying potential Opportunities then becomes a necessary part of the Product Discovery track.
The process is that the Product Team pulls Outcomes from the prioritized Product Backlog and performs discovery work to quickly identify potential solutions and validate them.
In this work, we are addressing Marty Cagan’s Four Big Risks.
- Value – Can we identify ways to achieve the outcome?
- Usable – Can they be designed in a usable way?
- Technically Feasible – Do we have the expertise and technical capabilities to build and with what effort?
- Business Viable – Does it work for our business?
If an idea can not be validated we throw out that idea or iterate on it further. When we have successfully validated an idea to satisfy the desired outcome, then it becomes ready for Development.
Any artifacts from the Product Discovery process become part of the specification to the Development track.
Additional Notes:
- Many outcomes will require a combination of multiple ideas to solve
- Sometimes multiple solutions may be available and should be prioritized
- Commonly the ideas are tracked as User Stories but this is not a strict requirement
Development
Sprint Planning sessions now will be limited to selecting validated ideas from the Product Backlog to go into the Sprint Backlog. Now, when going into a Sprint, the team has much higher confidence in the value of what they will be coding and reduced risks in design.
It is important to remember that while risks are reduced, the whole Product Team should continue to be engaged in Development. No Discovery process will address every unknown that arises during Development.
Outcome Development Process
The diagram below describes the entire process from Roadmap through to Potentially Shippable Increments of Done Stories. In short, it illustrates the Product Discovery process pulling Desired Outcomes to produce Validated Ideas. In parallel, the Product Team is also performing Development work on ideas already validated that are pulled from the Spring Backlog.
Worth noting is that this process diagram varies from Jeff Patton’s concept in a few specific ways if you are contrasting the two.
- As previously stated, I attempt to incorporate Scrum concepts while Patton does not. Hence, I use a Product Backlog and Sprint Backlog, instead of Opportunity and Release Backlogs respectively.
- It intentionally illustrates the Backlog artifacts once to affirm there is only a single instance of each. Patton’s diagram shows duplications of these which may be confusing.
- I have visually simplified the Product Discovery and Development learning loops, which are important sub-processes.
- I have incorporated the Sprint Planning event to describe how Validated Ideas get from the Product Backlog into the Sprint Backlog. The Sprint Planning can also be used to determine what should go into Discovery.
Implementation Variations
When implementing the development process within Scrum we are somewhat restricted by the need to work with a single Product Backlog and single Sprint Backlog per value stream. In the spirit of being agile, there are alternatives that some organizations may find more workable based on the constraints of tools being used and team preferences.
Variation 1: Additional Validated Idea Backlog
To ensure there is a clear differentiation between Outcomes prioritized in the Product Backlog and validated ideas that are ready to go into Sprint Planning, a third backlog artifact can be created. I refer to it as the Validated Idea Backlog.
There are two potential benefits to the Validated Idea Backlog.
The first is that the level of granularity of items in it will be Validated Ideas, not Outcomes. Since an Outcome may be solved by multiple ideas together this will help the team manage these independently.
Second, some Validated Ideas may support multiple Outcomes. By separating them out, it may become easier in some tools to track such related benefits.
Variation 2: Kanban instead of Scrum
Some organizations are shifting toward a Kanban approach to managing a flow of work through the development process. In practice, this means is that there may not be special planning event milestones, like Spring Planning, which also eliminates the need for an interim planning backlog artifact.
Second, some Validated Ideas may support multiple Outcomes. By separating them out, it may become easier in some tools to track such related benefits.
This approach can clearly simplify the process definition. In practice, there will be one or more additional in-process steps between the Validated Ideas (Backlog) and the Potentially Shippable content to support how the team prefers to track work in process.
For those working with Kanban systems to manage work in process, it is important to not lose sight of the parallel nature of the Product Discovery and Development work. Even under Kanban, these two activity tracks should always occur concurrently to minimize learning loops.
Conclusion
Outcome Roadmaps may seem at first to not readily fit with existing Agile development approaches. There are too many unknowns for Product Teams to get through a Sprint Planning event with only Outcomes as a starting point.
In practice, we can see that the very well-known Dual Track Development approach fits well. The concurrent Product Discovery track is an effective approach to translating Desired Outcomes into the validated ideas that Development needs to be most effective.
Moreover, since Product Discovery is performed by the Product Team together and not by some separated design team, more innovative solutions are likely to emerge over time.