A remote story mapping workshop needs a decision to reach, a shared map, and enough structure for people to contribute before the meeting turns into a conversation between the two loudest voices.
This two-hour agenda takes a small cross-functional group from one user goal to a proposed release slice, a visible list of assumptions, and named follow-up owners. It is designed for one journey. It will not produce a validated roadmap for an entire product.
The timing is a facilitation template you can adapt. The worked example is a fictional fitness class booking product: an existing member wants to find and reserve a class after work.
Prepare before the call
Send a short brief in advance. Name the user, starting situation, desired outcome, and decision the workshop should inform. For the example, the decision is: “What should an initial self-service booking release include for existing members?”
Include the evidence the team already has, with links to relevant research or observations. Distinguish observations from assumptions. If you have no direct research, say so and treat the output as a hypothesis to test.
- Scope: one member booking one class; membership sales and staff scheduling are outside this session.
- Starting point: the member has an account and a valid membership.
- Constraints: class capacity and cancellation rules need to be respected.
- Decision owner: the product owner will take the proposed slice into a feasibility and evidence review.
- Expected output: a map, proposed first slice, open questions, and assigned next steps.
Prepare a shared board with an empty journey area, space for stories, a release boundary, and a parking lot. Add a small legend for assumptions and open questions. Test edit access with a participant account and send the board link before the meeting.
Choose a group small enough for everyone to explain their reasoning. Five to eight participants is a useful starting arrangement, not a rule: product, design or research, engineering, and someone close to customer problems. Name a facilitator and a scribe; the facilitator should not also have to capture every sentence.
Agree how to contribute if the board is inaccessible. A scribe can add cards from chat or spoken contributions. Provide the brief and outputs in a readable text format as well as visually.
The 120-minute agenda
| Minutes | Focus | Output |
|---|---|---|
| 0–10 | Confirm goal, scope, and working agreements | One decision and one user journey |
| 10–25 | Tell the user’s story | Agreed starting point, end point, and broad activities |
| 25–45 | Map concrete steps | A readable left-to-right backbone |
| 45–60 | Add stories and exceptions | Capabilities beneath the relevant steps |
| 60–65 | Take a break | A genuine pause from the board |
| 65–85 | Propose the first release slice | A coherent path through the journey |
| 85–105 | Challenge the slice | Risks, dependencies, assumptions, and tests |
| 105–120 | Read back decisions and assign follow-up | A saved map and an owned action list |
0–10 minutes: establish the decision
Ask everyone to add a practice card so access problems appear immediately. Then state the decision and exclusions aloud. A participant should be able to explain why the group is meeting without referring to the tool.
Use this opening prompt: “By the end, we want a proposed booking slice we can challenge. Which user are we helping, and what must they be able to accomplish?” Capture disagreement before adding features.
Agree to write briefly before discussing, distinguish evidence from guesses, and park questions that do not change today’s decision. Keep the timer visible. Explain who can decide scope and who must still review the outcome afterward.
10–25 minutes: tell the user’s story
Invite someone close to the user problem to describe a concrete situation. Avoid starting with a tour of the existing interface. Ask what the member is trying to achieve, what happens first, and how they know they are finished.
Give participants two minutes to write broad activities silently. Then compare and merge overlapping cards. For the booking example: find a class, reserve a place, and manage the visit.
Read the activities as a narrative. “The member finds an appropriate class, reserves a place, and can find the booking again.” If the group cannot agree on that narrative, reduce the scope or record the research question. Do not hide the disagreement beneath more cards.
25–45 minutes: build the backbone
Under each activity, add the actions the member takes. Start with four minutes of individual writing, then group and order the cards together. Use the activities, tasks, and stories guide when cards mix different levels.
Ask: “What does the member do next?” For this example, the steps include browsing sessions, choosing one, reviewing availability, confirming the booking, and finding the reservation afterward.
Use verbs. Replace “Calendar page” with the action it supports. Move implementation tasks such as “Build an endpoint” into linked notes rather than the user’s backbone. At minute 40, have someone who did not arrange the cards narrate the journey back to the group.
45–60 minutes: add stories and exceptions
Give everyone three minutes to add useful product behaviors beneath the steps. Then discuss the items that change the proposed release. Under confirmation, a story might reserve an available place and display a confirmation; another might offer a waitlist when a class is full.
Ask: “What could prevent the member from finishing?” Capture capacity changing during booking, an interrupted connection, or unclear eligibility as questions to resolve. Avoid writing detailed acceptance criteria for every idea in this session.
Label untested assumptions explicitly. A card reading “Members need an instructor filter” does not become research evidence because everyone in the meeting agrees with it.
60–65 minutes: take a real break
Stop the discussion and invite people away from the screen. Do not make decisions while some participants are absent. Leave the return time and the next question visible on the board.
65–85 minutes: propose an end-to-end slice
Ask participants to identify the smallest set of behaviors that would let the chosen member complete the journey under the agreed constraints. Give them three quiet minutes before discussing trade-offs.
Draw the proposed slice across the steps. The booking example might include browsing available sessions, reserving a place, seeing a confirmation, and finding the reservation again. Discuss cancellation explicitly rather than silently pushing it below the line.
Use this challenge: “If we shipped only the cards above this boundary, where would the member get stuck?” Check operational support as well as interface behavior. A staff-assisted workaround needs an owner, a way for members to discover it, and a capacity check.
The result is a proposed scope, not a delivery commitment. Mark items that need research, technical investigation, or a policy decision before the slice can be accepted.
Continuing the booking example from the hierarchy guide, this map keeps cancellation visible as a decision still to resolve. The empty cells in the lower lane mean no additional story has been selected for those steps.
85–105 minutes: challenge the proposal
Spend a few minutes reviewing silently, then hear concerns in a round so each function contributes. Separate four kinds of uncertainty: whether the user needs the behavior, whether they can use it, whether the team can build it, and whether the organization can support it.
For each material uncertainty, write a next action. “Check capacity handling” is too vague. “Engineering will verify how simultaneous booking requests are handled before refinement” gives the group something to follow up.
Do not use voting to settle a factual question. Votes can show preferences; they cannot establish what customers do or whether a dependency exists. Keep minority concerns visible when they could invalidate the slice.
105–120 minutes: close with a decision record
Read the proposed slice aloud from the member’s perspective. State what the group agreed, what remains provisional, and who will review it. Ask each action owner to confirm their next step and date.
Save a dated version or export of the map and share a short text summary:
User and goal: Existing member books a suitable class.
Proposed slice: Browse, reserve, confirm, and retrieve a booking.
Unresolved decisions: Cancellation policy and capacity handling.
Next review: Date, decision owner, and required evidence.
Actions: One named owner and due date for each open question.
Send the summary and map link after the session. Arrange the next review around the missing evidence, not simply another meeting with the same agenda. The living story map checklist provides a follow-up routine once delivery and research start changing the picture.
What to do when the session stalls
- One person dominates: return to quiet writing, then ask each person to explain one card before open discussion.
- The scope keeps expanding: compare each suggestion with the agreed user and goal; park separate journeys with an owner.
- People disagree about the current workflow: record the competing explanations and assign an observation or interview to resolve them.
- The board fails: continue with a shared text outline and a scribe; reconstruct the visual map afterward.
- The slice is still unclear at minute 105: end with the unresolved decision and evidence needed. A clear next question is more useful than a forced agreement.
Remote workshop questions
Can we map an entire product in two hours?
Usually that is too broad for this agenda. Choose a specific journey or decision. Use separate sessions for materially different users or workflows, then reconcile shared capabilities.
Should we estimate every story during the workshop?
No. Surface feasibility concerns and major dependencies, then refine and estimate the selected work with the people who will deliver it. Detailed estimates can consume the time needed to understand the journey.
Can part of the workshop happen asynchronously?
Yes. Collect evidence and initial story suggestions beforehand. Keep the live session for resolving differences, examining trade-offs, and confirming ownership. Give absent contributors a defined review window afterward.
For additional preparation, read how to prepare for a story mapping workshop. Use StoriesOnBoard as the shared map and bring this agenda to the call.
