Why Product Owners must continuously bridge the gap between the strategic and the operational level of their product.
In an agile product development organisation, the product backlog is the main source for planning your next few sprints. All feature teams rely on this prioritized list of backlog items. But a product owner’s responsibility is not only to feed the feature teams with work for the upcoming weeks but also to define the strategic view of his product.
It is a long way from a product vision to a prioritized backlog. Scrum does not go into details about this topic. The large-scale scrum framework LeSS recommends some collaboration techniques to use in order to fill the gap between product vision and backlog. This post describes three techniques that help you to connect both ends during the lifecycle of your product.
Scrum – Five Levels of Planning
In large-scale development organisations agile planning should be based on these five levels of planning:
- Product Vision
- Product Roadmap
- Release Plan
- Sprint Plan
- Daily Commitment
LeSS uses the PBR (Product Backlog Refinement) to derive backlog items andbring them in a “ready” status so that they can be implemented duringa sprint. An “initial” PBRcreates enough backlog items at the beginning so that feature teams are able tostart their development.
The following three collaboration techniques can be applied on the strategic level with LeSS to bridge the gap between the vision and the sprint development:
- Innovation Games (Luke Hohmann)
- User Story Mapping (Jeff Patton)
- Impact Mapping (Gojko Adzic)
Innovation Games
Luke Hohmann’s Innovation Games provide a set of practices to support the definition of your product starting from its vision down to the planning of its releases. The main focus of all practices is to involve the customer right from the start in a very collaborative environment. You are in fact playing these games with your customers.
The list of games in Luke’s toolbox is quite large and addresses different aspects that might help you for your own product.
All games are intended to structure your product features regarding value, risk, effort, priority, etc. This data helps setting up a product roadmap, e.g. like this one:
Playing these games at regular intervals, e.g. every quarter, will fill your product backlog with enough prioritized items that can be refined for further development. Remember to invite your customers, too!
Story Mapping
Story Maps are a simple way of telling stories based on user experiences in your product.
A map tells a story about personae doing something to reach a goal. Activities and high-level tasks represent the backbone of the map arranged. User tasks are the basic building blocks of a map. The goal of a map is narrated in a flow from left to right. Releases can be easily identified by defining a minimum set of tasks that users will use to reach the mapped goal. Story maps are created during mapping workshops. As with the innovation games it is important to involve relevant stakeholders and feature team members during the creation of Story Maps.
Story maps are a concise visual representation of stories performed in your product. In contrast to innovation games it does not start with the product vision itself but focuses on the user experience in your product and starts from there. With the visualization of stories in such maps one can easily identify gaps in the use of your product. The integration of personas is an interesting additional view on your product too. For products where the user experience and its flow are crucial for success this technique is highly recommended. If release planning is important to you this technique will assist you well.
Story Maps are in fact a prioritized representation of your Product Backlog. Hence they are worked on during each refinement session. The maps represent the flow in your product and they prioritize features in release cycles. Together, this will give enough criteria to feed the teams with prioritized backlog items particularly because the Teams take part in the mapping process.
Impact Mapping
Impact Mapping is another planning method that can help your strategic planning in a collaborative and visual style based on goals to be achieved. Impact maps visualize goals, who can create an impact for or against this goal, and what needs to be delivered in order to create this impact all in one mind map (hence the name).
The main benefit with Impact Maps is that all your development can be based on real business goals. This way you are always able to trace your implemented backlog items back to an original goal achieved.
In the process of creating your impact maps it is important to prioritize the impacts as a first step towards a prioritized backlog for the teams. Metrics are set up in order to measure if the implemented features actually change the actor’s behaviour in the way we expected it. If so, we can continue elaborating this branch. If it turns out that the expected behavioural change did not happen, we should stop, analyse the situation and try something else in our impact map. This is a regular process we apply after each feature implemented as deliverable. The general prioritization rule with Impact Maps for the Product Backlog is to only select one impact at a time and focus on it until implemented and delivered. Work in progress should be limited (Lean Development). You as the Product Owner should regularly have a look at his Impact Maps and decide what impacts should be addressed next by the Development Teams.
Conclusion
In an agile working model product planning is as important as the management of the product backlog itself. Some rules to consider:
- Involve customers, stakeholders and developers in your agile planning process, similar to the product backlog refinements.
- Synchronize your strategy with your backlog regularly on a longer time frame (e.g. release intervals, quarterly, annually)
- Even though your product roadmap or strategy may not change as often as your backlog it is recommended to start every sprint with the roadmap. This way you keep both in sync at all times during the development.
- Even a combination of all three techniques described above is possible, e.g. you can use Innovation Games as the entry point to create roadmap items that can then be placed and elaborated on using Story Maps.
Not every technique might be applicable with your product. Try to find out what aspects of these techniques fit best to the nature of your product. Other techniques not mentioned here may be applicable too.