The workshop went well. The backbone runs across the top, user stories stacked underneath, somebody drew the line for release one in a different colour. Everyone nodded. The photo of the board is in Confluence.
Then a stakeholder asks when release one ships, and nobody has an answer.
And that pause is the whole problem. A user story map is great at what you’re building and in what order a customer meets it. Agile teams run the workshop to get a shared understanding of the big picture, and it works — right up until someone wants dates.
The map says nothing about when, who’s free to do the work, or what happens when the person who’d build half of it is off in November. So it gets a round of applause, and three weeks later...it’s wallpaper.
Here’s the part that should come after the stickies to prevent this scenario.
First, get the map into Jira as structure
A photo of a board is a memory. Work items are something you can plan with.
- User activities become epics. Name them the way a customer would describe the step: Find a product, Pay, Track delivery. Not Payments service refactor. The whole point of a story map is the user journey, and epic names are where that either survives or turns back into a list of features.
- Stories stay stories, under their epic, in the priority order the map gave you. Break them into tasks later, when someone’s about to pick one up — not in the workshop, where you’ll invent detail nobody needs yet. You did the hard thinking in the room; don’t lose it in the import.
- Slices become fix versions. Teams skip this and it’s the most valuable thing the workshop produced. A slice isn’t a wishlist — it’s the thinnest complete journey that still works end to end. Tag it release-1 and you can filter by it, report on it, and spot the moment it starts growing. Labels do the job too if you’d rather keep the Release Hub clean.
If you mapped on a whiteboard in Jira Cloud, stickies convert into work items straight from the board, several at a time. Click, fill in the fields, done — less typing than it used to be, and it beats having someone create issues by hand from a photo the next morning. Everything else here works the same whether the map came from a whiteboard, Miro, or an actual wall.
Then define what a slice actually means
Before anyone says a date, pin down the slice. Three questions, twenty minutes:
- What has to be true for this to ship? Two sentences. If you can’t write them, the requirements aren’t clear enough yet, and no estimate will save you.
- What’s explicitly out? The stories just below the line are the ones people drag up later, one at a time, each perfectly reasonable on its own. Name them now and scope creep becomes a decision somebody has to make out loud. That’s the easiest way to avoid the version of this conversation where everyone’s annoyed.
- Who signs off? One person. “The team” means nobody checks and the slice ships because the date arrived.
Cheap conversation now, expensive one in week six.
Put the slices on a timeline
Epics need dates, and the slices need to sit where you can see them next to each other and next to everything else going on.
Jira's own timeline does this for one project. Fine if the whole journey lives in one place, and it rarely does — the mobile app, the API and the payments work sit in three projects, and your slice spans all of them. Plans handles multiple projects, but that’s Premium across the organization, which is a lot when a roadmap is the only thing you’re after.
My own tool fills that gap, so take this with the appropriate pinch of salt.
Planyway for Jira puts epics from as many Jira projects as the product touches onto one timeline.
➡️ Try Planyway free
- Group it by project, epic, team, assignee or label — whichever cut makes sense for the conversation you’re having.
- Releases, milestones (for the dates the map doesn’t own, like launches), and epic milestones get their own lane, so a slice is a bar you can point at in a meeting.
- Drag and drop to move things, and the dates write back to Jira.
- Zoom out to the year for stakeholders, zoom into a sprint when you’re planning the fortnight.
Check the order still holds
Story maps assume sequence. You can’t track a delivery you haven’t paid for. That’s obvious on the map and invisible the moment it becomes a backlog.
Link dependencies between epics with blocks / is blocked by, then look at them on the timeline. Work scheduled before the thing it needs shows up as a conflict instead of a surprise in Thursday’s stand-up. Dependencies that cross projects need a view that crosses projects — natively that’s Plans, otherwise an app.
The habit matters more than the tool: when you move anything, check what depends on it the same day. Some tools will reschedule the dependent work for you. None of them will tell your stakeholders.
Ask whether the people exist
This is the step that turns a plan into a commitment, and the one teams skip most.
A slice full of stories is a number — hours or points. Capacity is how many of those your team actually has, once you take out holidays, part-time schedules, the person who’s half on support, and that other project nobody mentioned in the workshop.
So: estimate the slice roughly, look at the people who’d do the work over the weeks you’re proposing, and if it doesn’t fit, you’ve got three moves. Move the date, cut the slice, or get more people. Pick one in the room, not in week five.
Btw, you can try the Workload view in Planyway for that. It checks the work against each person’s real availability, with regional holidays, vacations and days off already taken out, so you see who’s drowning before you promise anything. [And since it pulls in work from every Jira space, that “other project” shows up too.]
➡️ Try Planyway free
Because a release date nobody capacity-checked is just a guess with a calendar icon on it.
Give stakeholders something that updates itself
The map was a photo. The plan shouldn’t be.
Here’s the test: can somebody open it next Tuesday and see the truth without you touching anything? Save the view, customize what’s on it for that audience, and share the link with anyone who has Jira. Export to PDF for the people who don’t, and there are always people who don’t.
Otherwise you’re rebuilding the same slide every week, and a weekly rebuilt slide is always a week behind. Keeping one live view instead is the cheapest alignment you’ll ever get.
Bring it back to the map
A slice ships. The map isn’t finished, because the user journey still exists.
At your next backlog refinement, give it ten minutes. Pull the next slice’s stories into the plan, edit the ones that changed, look at what the last release taught you about your estimates, move the line. That’s the whole process. Ten minutes a fortnight is the difference between a map that’s useful for years and a photo in Confluence nobody has opened since March.
A note on personas while you’re there: if the workshop produced them, keep them next to the map rather than inside it. They help the team prioritize when two stories look equally important, and they go stale faster than anything else on the board.
The short version
- A story map gives you scope and order. It owes you nothing on dates.
- Get slices into Jira as versions or labels, or they stay a drawing.
- Define what each slice means before anyone says a date.
- Put epics and slices on one timeline, across whatever projects the product spans.
- Check dependencies and capacity before you commit, not after.
- Share something that updates itself.
- Revisit the map at refinement, or it becomes wallpaper.
No tool makes a perfect plan. What you’re after is a plan that changes when reality does, and tells you early enough to do something about it.
Over to you
How do you get from a story map to actual dates — versions, a plan, a spreadsheet nobody admits to? And if you’ve kept a map useful past the first release, what made that work?
