Create a Story Map

Create a Story Map2018-08-20T16:43:40+00:00

Story Map Workflow

Context

Summary

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.

Purpose

What is the overall goal or intention of this practice?

Create a Story Map is used:

  1. to clarify and articulate the Backlog by organising stories and other Backlog items into distinct areas (e.g., by functional grouping, business impacts, etc.).
  2. to help map out which stories will be implemented during which Release.

SLA

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.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

  • At least 2-3 releases should be mapped.
  • Mor ethan 4 is seldom realistic.

Entry conditions

What pre-conditions must be met before this practice is used?

  • The Backlog you want to analyse is stable.

Outline process

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.

#StepInstructions
1 Set up Story Map
  • Select the right technology (electronic, wall space, etc.).
  • Create an empty Story Map matrix.
2Agree product areas
  • Agree which areas of your product each column represents.
  • Add area titles in column headers.
3Group stories by area
  • Group stories by area.
4Sequence stories by release
  • Organise stories into releases.
5Move later stories to backlog
  • Place any stories that cannot be realistically assigned to a release in the Backlog section.
    • Typically any story that cannot be assigned to the next 3-4 releases.
6Verify Story Map
  • Confirm that the Story Map provides the optimum solution.
7User Story Map
  • Display Story Map prominently.
  • Use the Story Map to track progress, manage ceremonies, etc.
8Maintain Story Map
  • Keep aligned with other information radiators.
  • Make sure Story Map is fully maintained.

Detailed process

#StepByOutputInstructionsNotes
1Set up Story MapIteration Lead.

Iteration team.

Story Map framework.
  • Select the right technology (electronic, wall space, etc.).
  • Create an empty Story Map matrix.
  •  If not using an electronic tool, find a suitable wall:
    • Large, empty & visible to the entire team & its visitors.
    • Unlikely to be disturbed by other teams, cleaners, etc!
  • If using an electronic tool:
    • Make sure it is visible to all team members.
      • It should be a constant point of reference.
    • Make sure it is frequently reviewed.
  • Consider additional elements, such as:
    • Features column for shared system components & properties.
    • A dependencies column, to identify precursor/successor or parent/child relationships.
  • Consider adding special codes, tags, stickers, etc.:
    • To identify highest priority stories.
    • To identify stories with pending issues, obstacles or dependencies.
    • To distinguish story types.
      • E.g., strategic, stakeholder & foundational.
    • To show stories that rely on the Extended Team or other third parties.
    • To warn of especially complex, innovative & risky items.
    • To identify story owners.
    • To mark ‘nice to have’ & cosmetic items that can be delayed without serious loss of value.
2Agree product areasProduct Owner.

Iteration Lead.

Iteration team.

Updated Story Map framework.
  • Agree which areas of your product each column represents.
  • Add area titles in column headers.
  •  Typical ways of grouping include:
    • By type of functionality.
    • By business area.
    • Etc.
  • Ideally they should be assigned so that delivering of all the stories in a single cell adds more value than the sum of the individual stories.
3Group stories by areaProduct Owner.

Iteration Lead.

Iteration team.

Preliminary Story Map.
  • Group stories by area.
4Sequence stories by releaseProduct Owner.

Iteration Lead.

Iteration team.

Updated Story Map.
  • Organise stories into releases.
That is, divide the stories into rows as well as columns.

  1. Begin with their current priority in the backlog.
    • Begin with the release schedule outlined in the Product Plan.
    • The Product Plan defines the purpose of each release, so should help with assigning stories to releases.
  2. Assign current backlog stories to the Story Map in their current order of priority.
  3. Divide the stories into releases.
    • The first release should represent the initial Minimum Viable Product (MVP).
    • Each release should create a coherent extension or update to the product.
      • For internal products, successive releases should represent the next possible MVP.
      • In a commercial environment, a larger release may be commercially necessary.
    • Use story estimates to make sure that releases are sized evenly.
      • This will help the team to maintain a regular cadence.
      • But it may also mean you need to change the release schedule…
      • … and even the Product Plan as a whole.
5Move later stories to backlogProduct Owner.

Iteration Lead.

Iteration team.

Updated Story Map.
  • Place any stories that cannot be realistically assigned to a release in the Backlog section.
  • Typically this will include any story that cannot be assigned to the next 3-4 releases.
6Verify Story MapProduct Owner.

Iteration Lead.

Iteration team.

Agreed story map.
  • Confirm that the Story Map provides the optimum solution.
  • From a business/product perspective:
    • Do your releases match the product strategy?
    • Do you need to validate changes to releases?
      • With the Product Owner & other key stakeholders?
    • Do you need to renegotiate the release schedule?
    • Do you need to update other parts of the Product Plan?
    • Do your releases form coherent packages of updates & extensions?
    • Are there gaps in the stories?
    • Are there conflicts between stories?
    • Does it suggest ways to rationalise the product as a whole?
    • E.g., by shared features, eliminating redundancies, etc.
  • From a delivery/team perspective:
    • Does your Story Map maximise the delivery of value?
      • Does it define the optimum path for delivering the most value as quickly as possible?
    • Typically starting with the smallest system that offers a basic but usable product.
      • Or the initial ‘Minimum Viable Product’ (MVP).
    • Does your Story Map minimise cost?
    • Does it help you to identify shortcuts or synergies?
    • Does it ensure that the whole team is continuously adding value?
      • Without unnecessary pauses, waiting or delays.
7Use Story MapIteration Lead.

Product owner.

Iteration team.

  • Display the Story Map prominently.
  • Use the Story Map to track progress, manage ceremonies, etc.
  • If you’re using an electronic tool, make sure that it is accessible to – and often seen by – the whole team.
    •  It should be the focus of regular, if not constant, debate.
  • Use the Story Map to:
    • Manage planning sessions.
    • Assign stories & tasks.
    • Refine your backlog.
    • Plan Showcases.
    • Organise Retrospectives.
8Maintain Story MapIteration Lead.

Product Owner.

Iteration team.

Current Story Map.
  • Keep aligned with other information radiators.
  • Make sure Story Map is fully maintained.
  • Be careful to update any added markers, tags, colours, etc.
  • Keep the Story Board fully aligned:
    • With the Story/Task Board.
    • With the Burn Chart.

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.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?