Provide a summary of this practice.
A Story Map supports an intermediate-level analysis of how the Product Vision will be realised, and can be used at various points between between the Product Backlog and the final Story Board. The Story Map performs many of the functions of the Release Backlog, for which it can sometimes be substituted.
What is the overall goal or intention of this practice?
Create a Story Map is used:
What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?
Create a Story Map should take no more than 2-3 hours to complete for a realistic (e.g., 3-4 release) Story Map.
What must have happened or been delivered for this practice to be considered complete?
What pre-conditions must be met before this practice is used?
This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.
|1||Set up Story Map|
|2||Agree product areas|
|3||Group stories by area|
|4||Sequence stories by release|
|5||Move later stories to backlog|
|6||Verify Story Map|
|7||User Story Map|
|8||Maintain Story Map|
|1||Set up Story Map||Iteration Lead.|
|Story Map framework.|
|2||Agree product areas||Product Owner.|
|Updated Story Map framework.|
|3||Group stories by area||Product Owner.|
|Preliminary Story Map.|
|4||Sequence stories by release||Product Owner.|
|Updated Story Map.||That is, divide the stories into rows as well as columns.|
|5||Move later stories to backlog||Product Owner.|
|Updated Story Map.|
|6||Verify Story Map||Product Owner.|
|Agreed story map.|
|7||Use Story Map||Iteration Lead.|
|8||Maintain Story Map||Iteration Lead.|
|Current Story Map.|
Issues & risks
What are the key concerns in making a success of this practice?
The Story Map is a powerful tool, so making the best possible use of it is essential.
- For a more detailed account of Story Maps, click here.
- A Story Map isn’t always needed. Use one if you have a very large but only weakly prioritised backlog.
- On the other hand, if you have enough space, a Story Map can replace the Release Backlog entirely.
- Story Boards are a powerful tool for sharing knowledge across teams – especially IT & non-IT teams collaborating on the same release.
- Story Maps add balance to a ‘pull’ process.
- For example, if you’re a support team using Kanban, a Story Map can help you to coordinate support across the users’ Big Picture rather just taking the next item in the queue.
- Do not over-complicate Story Maps. Add only as much detail & extra information as is useful for successful delivery.
- It’s OK to include immature stories, concepts, etc. in the later releases.
- This improves the intelligibility of the Backlog as a whole, and points out gaps where action is needed.
- But don’t go into too much detail, or let stories to remain immature for too long!
- You shouldn’t need separate processes for managing your Story Map.
- For example, priority within Releases should be defined by the standard Release Planning process, story status should be tracked using a story board, etc.
- Iteration-level breakdown is usually (but not always) too granular.
- That’s what the Story Board is for.
- Release-level mapping is enough.
- Don’t let the Story Map get out of control. Limit it to stories – not tasks. It’s a roadmap, not a work plan.
- To track individual stories, tasks, etc., use a Story Board.
- Avoid replicating other information radiators.
- E.g., Story & Task Boards, Burn Chart, Improvement Board.
- A separate tracks for bugs can be handy, but beware of letting this undermine the Quality First culture Agile relies on.
- Like all Information Radiators, maintaining the Story Map is important.
- And failure to maintain it can be very misleading.