In a recent Product Owner Course I was asked to provide a picture of the flow from Vision to User Stories, with all the steps in between.
I think the attendee was hoping for something like:
There are a couple of challenges. Scrum, being a framework, doesn’t tell the Product Owner or the Dev Team (aka Doers) how to do their work. As a result, none of these particular tools are required and some excellent ones (such as Personas and Impact Mapping) are missing from this simple picture.
The deeper problem is that a picture like this implies a strict linear flow. But there is no standard flow or right order. Each tool is independent of one another.
A picture, were we to draw it, would be more like an interconnected web. Each tool leading to every other and, just as important, gaining feedback from the tool that comes after it.
Some examples to help:
In the first Sprint, the Team might decide to go from a Vision straight to a few User Stories with Acceptance Criteria. In the same sprint, they build out and deploy two of these stories, finally testing them with their target market (aka Lean Startup and Lean UX). Once they get some initial feedback, they hold a Product Backlog Refinement meeting and start populating their initial Story Map backbone. They use the early version of their Story Map to explore the flow from the key persona’s viewpoint. Next, they create the first few User Stories for each item in the Story Map to make sure they understand it well. By now the Team have created thirty Stories and the Product Owner wants to make sure she is prioritizing the stories that will have the greatest effect for the key personas. She turns to Impact Mapping (effectively Mind Maps for User Stories that explore the Why, Who, How and finally What – only exploring the What after we understand the context).
All the while the Team is building software and validating it with market as they go.
In a separate but parallel universe…
Our Team might start by building a vision using a collaborative game like Product Box with their stakeholders (including actual customers). They move from this to designing Personas that represent their core constituencies and then create a Story Map backbone. They take a couple of extra days to create the initial User Stories and initial acceptance criteria. Then, like the first example, they start building their application and validating in the marketplace. As they gain feedback, they update their existing Vision, Personas, and Story Map(s) to reflect their new understanding of the world.
Aside from my personal preference to the first version of the Team, which is wasting the minimum extra time before testing whether their ideas meet actual customer needs, there is no correct version. All approaches are valid.
Instead what matters:
- Continuous Collaboration between the Product Owner, Dev Team, and Stakeholders
- Frequently updating their artifacts (Vision, Personas, Story Maps) as they discover meaningful change. Since we don’t want to reinvent waterfall, this implies that all artifacts are kept small and light.
- We don’t assume that our Personas, Story Maps, etc. are true versions of reality and we’re always trying to test them with working software validated in the marketplace.
So instead of trying to visualize the “flow” to write User Stories, which suggests something linear without feedback, maybe it would be more helpful to imagine it as a mesh or interconnected web.