The Storymap That Lost the Plot
A team is redesigning the onboarding journey for a fintech app. They built a storymap: a backbone of user activities (sign up, verify identity, connect a bank account, make a first payment) with tasks and stories underneath. The map has grown to 140 stories. Engineering says the top of the map is fine but the release slice is bloated and keeps changing. User research shows new users abandon most often at identity verification, citing confusion and fear about data sharing. The team is three sprints from a launch and is arguing about which stories to cut.
1. Diagnose why the storymap's release slice is bloated and unstable, using the storymapping approach.
Read the worked answer
A storymap's backbone should represent the user's narrative across activities, and the horizontal slice should be chosen to deliver a coherent, valuable outcome, prioritized by what matters to users - not by what is easiest or most requested.
Here the slice is unstable because it appears to have been assembled feature-by-feature rather than around the user's critical path. With 140 stories and no clear prioritization principle, every stakeholder adds 'must-haves,' so the slice keeps changing. The map has become a backlog with a narrative veneer.
The research gives the missing prioritization principle: identity verification is the abandonment point. A slice that does not make that step clear and reassuring is not delivering the journey, regardless of how many stories it contains. The slice should be re-cut around getting a nervous new user through verification successfully.
2. How would you re-cut the release slice for the launch, and what would you defer?
Read the worked answer
Re-cut around the critical path and the abandonment point:
- Define the slice's goal as: a new user can sign up, complete identity verification with confidence, connect an account, and make a first payment.
- Prioritize stories that (a) reduce confusion and fear at verification (clear explanations of why data is needed, what is shared, progress and reassurance) and (b) complete the end-to-end path.
- Treat 'connect account' and 'first payment' as needed to reach the outcome, but keep their stories minimal - enough to complete the journey, not to perfect it.
Defer: enhancements that do not block the critical path - nice-to-have personalization, secondary payment methods, polish on steps after the first successful payment, edge-case optimizations. Park them below the slice line with a clear rationale.
The test for each story: does removing it break the user's ability to complete verification-to-first-payment with confidence? If not, it is a candidate to defer.
3. Stakeholders keep adding stories and the slice keeps changing. Propose how to stabilize the slice and communicate the cut decisions.
Read the worked answer
- Make the slice's goal explicit and public: write the one-sentence outcome the launch must deliver and post it on the map. New stories are evaluated against it, not added by default.
- Establish a cut line with a rule: stories above the line serve the critical path and the verification problem; everything else goes below with a reason. Additions require removing something or moving to a later slice - no silent growth.
- Tie decisions to evidence: cite the research on verification abandonment to justify why reassurance stories are in and polish stories are out. This moves the argument from opinion to user data.
- Show the deferred list openly so stakeholders see their items are parked, not lost, and can be scheduled.
- Timebox the slice given three sprints: freeze scope at the start and route new requests to the next slice.
This converts 'which stories do we cut?' into 'does this serve the outcome?', which is a decision the team can defend.