The best time to journey map
Before I estimate a single ticket, the stakeholder and I agree, in plain language, on what the end user should be able to do when the build is done. I use user journey slices for this.
I didn't invent them. Journey mapping and journey slices aren’t new. I do think they’re underused though. Most conversations about what the first iteration of a feature is supposed to look like exist in DMs between stakeholders or in ethereal video chats. That or they’re War and Peace length documents that require reference manuals to be useful. What I list below is my minimum, the least information I've found that still helps a team execute and still holds up when scope questions come up later. Steal it if it's useful.
- Business value
- Job to be done
- Out of scope
- What we know: 5-7 key callouts from the stakeholders’ must have list
- Questions we have: what the dev team still needs answered
- What done looks like
Keep "what we know" to five to seven concrete constraints, the kind that change how you build, like "we need real-time data on the dashboard" or "a six-hour delay is fine."
It's a living document. We don't build epics, features, or stories until the dev team's big, hard-to-reverse questions are answered, and for the smaller calls, a developer can check the slices for the intended experience.
Avoiding the junk drawer
Most companies add one feature at a time without considering how each piece fits what the user is trying to do. You end up with a banking app whose menu includes: send via Zelle, send via wire, transfer, instant pay, pay bills, manage bills, change PIN, and open a new checking account, every option bolted on instead of a cohesive, low-noise path for a user to take. It's like digging through the junk drawer to find the butcher's twine. You know it's in there but first you have to sort through the 42 fast food drink straws, 3 bottle openers, a set of Allen wrenches, some tape, and a pair of scissors. Slices keep you building around the customer's goal, so a new request gets folded into the existing application with a clear next step, instead of another button on the pile.
It's also how I catch scope creep before it catches me. Because we've agreed on what's in and out for this iteration, a new request is easy to place. I can point to what we wrote and say that's not in here. The out-of-scope line matters just as much, because it records what we agreed to leave out at the start. This also makes saying no a lot easier down the line in my experience. Clarity is kindness.
I was building a feature once when my stakeholder asked about the dashboard progress. Dear reader, no dashboard had been scoped. I went back to the journey slices and said that's not something we scoped. I'm happy to do it now and give you some estimates and you can decide if you want to make the investment right now. I did the back-of-the-napkin math. If these are the pieces you want, here's my conservative estimate, here's my generous one, and here's the Goldilocks estimate of how many sprints it would take. That conversation is easier when there's an agreement to point back to. It's brutal when there isn't. Again, clarity is kindness to yourself and your stakeholders.
The best time to write your slices is at the start. The second best time is now. If the only record lives in DMs and side chats, you're going to have a bad time.
If you're sitting on a scope conversation you're dreading, that's exactly the kind of thing to request in our Q&A, where we answer your questions on social media, or bring to office hours and we'll work it live