Few things are as exciting and intimidating as beginning a startup. There are so many things to take into consideration, and it’s easy to get overwhelmed. How do you get started? You have all these visions of grandeur, but how do you get there from square 1? Building software is an iterative process, but when you have the end goal in mind, iteration can be hard to envision.

User story mapping is an incredible mechanism used to define the first value for your product. It lays out the pathways you need to take to get a working product. It aligns your team with the vision and understanding of how the business works. Best of all? It only takes a day or two to execute.

The most important outcome of user story mapping is the shared understanding of your team.

Get Together

To build a shared understanding of the domain, you need to get your development team together with an expert. Somebody in your startup is an expert, find them. You hired your developers for their development skills, not their business knowledge. You need to pair them with somebody who can teach them the ins and outs of the domain.

While user story mapping can work with a distributed team, it works even better if you all are together. This might be the time to fly everyone in. It is easier to ask clarifying questions, get validation, and make sure everyone is on the same page before starting development.

Begin the Discussion

With the development team and the expert together, it’s time to talk business. Everything about it. Discuss all scenarios a business flow can have. What is the happy path? What are the sad paths? Leave no stone unturned with this conversation. Establish ubiquitous language across the team.

Image by Christine Sponchia from Pixabay

This is your opportunity to discuss your approach to the problem. Do not discuss how your competitors handle it. You are making this product because you think you can do it better. Is there a process out there that you think you can revolutionize? Introduce that into the business flow. See if it makes the process better.

Have the expert walk the development team from the beginning of the process to the end. Do not leave any details out. The development team can and should be asking clarifying questions the entire time. Any terms the expert uses should be clearly defined for the team. Use the business terms often so you can start talking the talk.

The better the team understands the business, the higher the quality product they will build.

Phase Discovery

The magic begins with phase discovery. Phase discovery is a high-level discussion of the different stages of the business workflow. The goal is to come up with as fewer phases as possible. Aim for 4–7 phases.

For example, if you were doing phase discovery for a simple online ordering service, you might have Shop, Order, Package, and Ship phases. Each one of these is a significant stage in an online ordering business, and we get a general overview of the primary operations you can perform.

To do a phase discovery, everyone in the room needs a pad of sticky notes. Take 5 minutes and write down all the phases you think are part of the business process. Make sure everyone keeps their phases to themselves. You want to take this as an opportunity to make sure the team understands the earlier discussion.

After 5 minutes, the team goes up to the board one by one and puts their sticky notes up. After explaining why they chose each specific one, they sit down and the next person goes. Once all the sticky notes are on the board, try to consolidate and group up similar phases as much as possible. You likely will have a significant amount of overlap at this point in the process.

Remember to keep the phases at the highest level possible. It is easy for developers to jump into the weeds at the beginning, but at this point, we just want to talk about the stages of the business lifecycle. Once agreed upon, we can move on to the next part of user story mapping.

Task Definition

Now we are going to build on the phases from the previous step. We need to define the types of tasks or operations that are performed in each phase. In the Shop phase from our earlier example, tasks might include Search, View Item Details, and Compare Items. Once again, these are high-level tasks that can continue to be broken down, but it gives us more clarity into what we mean when we say Shop.

This part of user story mapping is run the same way as phase discovery. For each phase from step 1, everyone takes 5 minutes and write down the tasks. Once the time is up, go up to the board, discuss the tasks you came up with, and group up/consolidate the similar ones.

Some tips with defining tasks:

• Limit to 3–5 per phase
• A task must be able to be broken down into two or more workable parts
• It’s ok to be vague

Once you’re done with each phase, you can start to see the various business operations start to take shape up on the board. Ideally, what you have up on the board should cover the majority, if not all, use cases to the business from a high level.

Limit the Scope

You cannot reasonably come up with user stories for every use case upfront. You wouldn’t want to do that anyway. You are going to need multiple iterations to see your product start taking shape before you know how you want to handle all use cases. For now, you need to define a limited scope for your first value product. Consider it the easy path.

What is the most straightforward business flow that gets you from end to end? Are there basic iterations you can perform on this business flow? Good. Focus on that. Ignore any configuration you will have to build to set up your workflow. Hardcode what you can.

Getting a simple workable product in front of you is infinitely more valuable than a full-solution product on paper.

Another way to go about thinking what your scope should be is from a sales point of view. Don’t think of your first value product as production-ready. It won’t be. But think of it as something you or your sales team can show to prospects. Prove to them you have something great on your hands. It will be fully featured eventually, but you need something out there now so you can start building up a pipeline and filling in your backlog.

With your limited scope in mind, it’s time to start making user stories you can feed to the development team. They should be ready to get started!

Create User Stories

Back to the sticky notes. This time you are not working individually. Break into two teams and start tackling the board. Your goal here is to come up with actionable user stories the development team can take back, add some detail, and begin working on them.

Back to our online store example, under Shop, we had the Search task. Examples of user stories you could have under a search would be generate a list page of results, display faceted search criteria, and enable post search filtering.

A digital example of a user story mapping board

Notice here that the stories are more verbose than the tasks and the phases. We are finally at a level where detail is important. Being descriptive is key with a good user story. If you’ve ever been a developer before, you know that generate a list page of results is not granular enough to be an Agile user story, but it does get the point across in enough detail to provide direction.

During this part of user story mapping, you are going to take about half an hour to go through all the tasks. Teams will grab a task, write as many user stories they can think of, then move on to the next. The teams should not collaborate or look at each other’s stories. It’s ok if there are duplicates.

It is critical to the process that you stay focused on not getting to the nitty-gritty when building user stories. You don’t want to come out of this process with 300 user stories. Write the building blocks of your stories and move on.

Given the limited scope you defined, it’s possible a task might not have any user stories in it. That’s ok. Just skip it. There will be user stories needed in other tasks. You know the task is necessary to the business, so if it doesn’t apply to your first value scenario, just march on.

User Story Review

Now the teams can start the discussions amongst each other. Look at what the other team wrote and see how it aligns with the stories you wrote. Remove any duplicates. When putting the stories together from both teams, does the business process make sense? What’s missing?

Add any missing user stories to the board. It’s likely a story that one team wrote opens a pathway the other team didn’t think about. Record that on a sticky note. Discuss it as it relates to the limited scope. Does it make sense to include it for your first value? If so, keep it on the board. If not, put it in the backlog for later. You don’t want to forget this feature.

After the discussions, walk through the limited scope business flow one more time. Have the expert talk through each phase and see if it directly maps to a user story on the board. If something is missing, add it. If a user story isn’t mentioned in the flow, remove it.

Only build the minimum required to get from end to end — place value on iteration. Once you have something out there, you can iterate and make it a masterpiece.

Once you get the minimum process down, you can start walking through the next iterations on how you would improve the product. You can separate the user stories into different sections, or releases, which will stand for the second or third iteration.

When building your iterations, be sure you are extending the process from end to end. Do not get focused on building out one phase entirely. Make sure to have incremental additions to every phase every iteration.

Next Steps

Now that everything is defined, you need to get approval that what you are planning to build makes sense. If you have a sales department, walk them through your stories and thoughts on scope and iteration. See what they can live without and what they must have. After all, they are going to be the ones working with the prospects.

Once you have approval from sales, the development team can start thinking about service decomposition. How are they going to turn the user stories into microservices? What endpoints need to be created? What is the scope of each microservice? Many development tasks can begin at this point.

Congratulations! You have defined the business process, created a shared understanding across the development team, chosen the scope for your first iteration, and come up with the user stories required to get there. You have the approval of sales that you’re on the right track and a clear vision in front of you. You’re ready to get started!

Best of luck to you as you start your startup journey! Staying organized and having a clear vision is the key to success, and user story mapping is the perfect way to get on track.

Have you done user story mapping before? What has been your experience with it? Let me know in the responses.