(This post contains affiliate hyperlinks. Please read my full disclosure.
Frances Place contributed this guest post.
I have spent years working in project teams and know that it is essential to have a clear understanding of the scope of the project from the beginning.
Frances Place, White October Account Manager. I’ve worked on many projects where teams followed the fixed requirements but ended up going in different directions. Or, we didn’t understand the vision or have missed a detail because the requirements weren’t precise enough.
It is difficult to find a technique that can explain scope within the context of the vision.
While traditional project specifications are useful in describing the scope of work, they don’t show how it all fits together. These requirements lists are focused on what will be done and when it will be done, but they don’t show what it means for the user.
The project team and stakeholders require additional briefing time to fully understand the context and the point of view of the user. This often takes away precious delivery time.
The specifications are set. There is no way to adjust as the project progresses.
What if there were a dynamic way to capture changing requirements within the context of the vision? That would brief and engage the entire team in the process.
User story mapping: A simple way to scope projects
Jeff Patton, an Agile consultant, was faced with the same problems. He needed to transform a list with requirements into something that communicates the vision of the project and shows its priorities.
He created user story mapping, a visual tool to organize, prioritize, and sort what you need.
The user story map is a visual representation of the entire scope of the project. It was created in collaboration with the product owner, the development team and other stakeholders.
This diagram shows how a map is constructed. The User Story Mapping book by Patton gives detailed instructions on how to use this technique for better project scoping.
Start by listing the tasks that a user wants to accomplish with the product. Next, group these into activities (high-level goals) to create the backbone of your map.
Each member of the team should work together to add user stories to sticky notes under each task. These provide the details of what must be delivered.
Participate the entire team in prioritizing the user stories into versions that will be used as the basis of the project plan.
User story mapping has many benefits
This technique has been my favorite for more than a year. I can’t begin a project without it. It is an invaluable tool for us for four reasons:
1. Visualizing the product is powerful.
Before you start building the product, you will be able to spot any gaps or errors in your thinking as the features are presented through a story.
Here you can see if you have captured stories to update the user’s profile, but forgot to add a requirement for creating the profile. Telling the user’s story will help you spot errors like these.
2. Prioritisation is meaningful
It’s very different from the virtual act to change the priority level of a feature on a spreadsheet or online tool the physical act of moving a sticky notice above or below a release point. It feels more real.
While the Product Owner is responsible for prioritization, the entire team can see the decision making. The whole team can challenge the decisions made, which allows them to push each other to build as little as possible at each stage and get the product to the user faster.
3. It allows you to learn as you go
The map is meant to be a living artifact that you can post on your office wall. It reminds everyone of the larger picture of the product.
It can be used to continuously review the backlog and adapt it as you learn about your users.
4. It is a