In our prior blogs we talked to you about creating a vision (read here) and a canvas (read here) to guide your team toward the highest impact and to allow your clients to see what you want to be and support you on your journey with valuable feedback.
Now we will look at how to build a dynamic backlog of enabling items that you will adapt as your team completes work and you gather feedback.
A story map starts with the vision you created. From that vision, you can create components that can be used to move you toward the vision. Each component interfaces to other components so that when complete they would together fully satisfy the vision. Think of the components as services or products that independent teams or business units can fully deliver value to the client. If your vision is for only a single team, that is okay. In these cases, the components are optional and can be used to help organize your work for the single team.
For our STEM Zone example some components could be:
- Robotics Arena (from our nonprofit canvas blog) Computer Game Programming
- LEGO Architecture City
- Parent Outreach
Now for each component what are the tests that you would like the component to ‘pass’ that it currently ‘fails’. We will focus on the Robotics Arena component.
Robotics Arena:
Test: A 10-year-old can build a robot from a kit we provide.
Test: Robots can compete head to head on a field that fits in our space Test: Ideas are being shared between students
Test: A tournament format is being used to encourage friendly competition Etc
Now for our Minimum Viable Product, we want to have it meet two criteria:
- Minimum
- Viable
This seems obvious, but let’s investigate this further. Minimum means the simplest way to change the test results from red to green for the tests we want to pass. Viable means the tests are passed with enough quality in our solutions that our clients are happy to be part of this first product.
By doing this, we are able to test our hypotheses quickly to know if we are headed in the right direction.
The story map shown below is arranged in priority order. Each row of stories might represent one iteration or Sprint of work. After each iteration, we have an increment of new functionality that our clients can provide feedback on. Because of this, each row represents an opportunity to adjust what we would like to provide in the next iteration and with the release as a whole.
The stories represent client and other stakeholder needs and wants and do not propose how the team satisfies those needs and wants. By writing them as user stories, we are giving the team the main user, their need or want, and an idea of what value satisfying that need or want will accomplish for them. This way our story map represents value or impact that we plan to deliver without getting wrapped up in how we will deliver it.
The story map easily adapts to change by rearranging the stories into different iterations or releases based on feedback. Because we haven’t spent time discussing all the how’s and getting into details, the acceptance of change will be higher for the team as they won’t be attached to the solutions. Because of the focus on the client, the changes will be easily understood given the feedback. The team can then focus on the next iteration and how they will accomplish that while knowing the larger picture from the updated story map.
Happy Scrumming!
Join our email list! Be the first to know about upcoming events & trainings, new blog posts, discounts, and so much more. Bonus – lookout for the letter from the president each week. Let us help you create twice the impact in half the time!
