Story Mapping
The map
A story map organises work as a user journey. There are three levels:
- Activities - what personas do. These form the backbone of the map, reading left to right like a user's journey through the product.
- Tasks - decompositions of each activity. The steps within an activity.
- Stories - the work. Each story delivers a thin vertical slice of value.
Personas
Activities belong to personas. A user role that interacts with your product in a distinct way.
Multiple personas on one activity (e.g. Customer and Ops) means both experience it. Personas keep the map honest about who benefits from the work. If there is no persona associated with an activity, why build it?
Why there is no backlog
The map is the backlog. Everything lives on the map, in context. One place, one structure.
On backlogs
A backlog is a landfill. Every item in it is an assumption. It stays an assumption until it is released to real users.
The backlog grooming meetings, hours spent ranking items, the bottomless "icebox" that just grows. Estimation sessions from last year.
Is there not enough work already in progress? What is the team focused on right now? Why can't they focus on that thing only?
The question should not be what to add to the backlog, but what to remove from it. If something matters, it will come back.
Release slices
Release slices let you plan horizontally across the map. Instead of sprints (fixed time boxes that batch work), slices cut across activities to define a coherent release. This should consist of the smallest set of stories that delivers a usable increment.
Slices are not sprints. They have no artificial time box. They are done when the stories in them are released.
Writing stories
Every card is a user story.
Bugs are stories
A bug is a story written from the user's perspective. "Customer sees stale price after updating quantity" not "Fix cart cache bug." Put it on the map under the activity and task where it belongs. If it has no place on the map, ask: does a user actually care about this?
Tech work is a story
If the work has no user outcome, question whether it needs doing. If it does, frame it as the user outcome it enables. "Customer checkout loads in under 2 seconds" not "Optimise database queries." The framing forces you to articulate why the work matters. If you struggle to, question whether the work matters.
Refactoring is how the pair writes code, built into every story. Every story includes leaving the code better than you found it.
Story lifecycle
A story moves through four states:
- Planned - on the map, not yet started
- Active - someone is assigned, work is in progress
- Deployed - code is in production, users do not have it yet
- Released - users are experiencing the change
Each transition is an explicit action. Assign starts work. Deploy records that code reached production. Release marks the moment users get the change. Archive removes the card from the active view.
Splitting stories
One story is one story.
Mainline tracks this automatically. The split threshold is self-calibrating from the team's own released cycle times (80th percentile by default). When a story has been active longer than the threshold, it gets a label indicating that it may be too large. That's it. It's not too slow, but it might be too large or sliced in such a way that it's difficult to finish.
Cycle time data from your own team's released stories gives you something estimates never can: an empirical distribution of how long work actually takes. If your median is 2 days and a story has been active for 10, that story is telling you something. No planning poker required.
On estimation
Mainline tracks cycle times instead of velocity or story points. Instead of asking "how many points is this?", ask "given our historical data, what is the probability of completing this in X days?"
Story sizes
Every user story in Mainline is a user story of size user story.
The mode of work -- be it pairing, solo, or ensemble, is unrelated to sizing, which is always one. Switching between the three modes of working is possible at any time.
By default, a story requires two people assigned to become active. This serves as a natural "kick off". The moment where at least two people read the story, agree on what done looks like, and start together. Teams familiar with the three amigos pattern (developer, QA, analyst) will recognise this: the conversation that usually happens in a separate meeting happens here, at the point of work, with the people doing it. No meeting required.
This can be turned off in settings if the team would rather kick off solo.