Plan release cycles by organizing user stories into a step-by-step segmented flow
Core team, stakeholders
Before mapping, create a short product or feature brief to frame and constrain what you map. Think of this as the big story. What is the product you are creating or the problem you are solving? Who are the customers or users? How does each user benefit? Why are you interested in building this and how do you benefit?
Hand out a stack of stickies (of the same color) to each of the participants. Explain that everyone is going to use these stickies to tell the story of the product through user tasks.
Give everyone a few minutes to silently generate user tasks that together compose the narrative flow of the product or solution.
Start putting user tasks on the whiteboard by asking each participant for a task, one at a time. If there are duplicates, use the one that best captures the step and discard the rest.
Check with the group after adding each task to make sure the order feel rights and critical tasks have not been skipped.
Optional: Use stickies to label groups of user stories by their corresponding epic.
Have the participants to come up to the whiteboard and engage with the map. Ask them to think about variations or deviations from the “happy path” already outlined.
Ask the participants to write these secondary tasks on stickies and place them underneath the backbone stickies in the appropriate order.
Decide how many releases you’d like to divide the map into (you can always adjust this later).
Use the tape to slice the story map into segments (releases) of user stories that will provide relatively equal value.
Define the goal of each release and write it next to each corresponding release.
Reassess the placement of each user story. Move stories if necessary.
You’re done when the team feels like they have an accurate representation of what will be built and a backlog of users stories.
A user task is a short verb phrase like “read an email” or “respond to a message”. Don’t get too detailed. Stick to tasks at the functional level. This means the resolution of the task is right when it’s as big as it can be without a person plausibly taking a break in the middle of it. (e.g. In the story of my daily routine, a task might be “taking a shower”. “Changing the temperature” of the shower is too detailed (sub-functional) while “Getting ready for work” is too broad.
Work on the happy path first. Then in the deep dive portion, capture the alternative paths a user might take through the product.
Completion of Discovery & Framing
Share out at Inception