Build Experiences not Features, part 1 of 2
Connecting Design Thinking to Agile Sprints with User Story Mapping
By Corrie Kwan, Eric Morrow, and John Murray | Hybrid Cloud Design @ IBM
Note: This is a 2 part series. This part focuses on the high level strategy of why you would want to use User Story Mapping to connect design thinking to agile development. Part 2 (read here) goes more granular and discusses the tactics of running a User Story Mapping workshop.
I have been frustrated in the past that a good design thinking workshop wouldn’t lead to material improvements in the product. The team would leave the workshop in agreement about what direction we wanted to go. But that agreement seemed to get distorted and lost by the time it was put into individual user stories that the developers were going to work on. All of the user research we had done and the insights we had applied to inform the next iteration of the product wouldn’t make it into the actual user stories that the development team was coding, and therefore not into the product itself.
This problem of connecting design thinking with agile development can be solved with a technique called User Story Mapping.
User Story Mapping generates business value by bridging design thinking with agile development
User Story Mapping helps product teams deliver business value because it:
- Creates shared understanding among the team: design, engineering, product management, sales, and marketing
- Requires teams to prioritize the most important work
- Provides a visual representation of your agreed-on product work
- Generates user stories that can be easily logged into your code repository
- Moves the team’s focus back and forth between the mission statement and the individual user stories, iteratively improving both in the process
Shout out to Patton and Parekh; We relied massively on your work and insights. Read more about user stories in agile development.
What exactly is User Story Mapping?
User Story Mapping is the process of generating user stories from a high level mission statement.
Let’s start with an infographic that walks through the whole process.
Teams should start with a high level mission statement (at IBM, we call them Hills) and a good understanding about who they are building the product for. Then they should imagine what their user’s experience will be like when using the product, as if the team had already built the product indicated by the mission statement. This process is called journey mapping (at IBM, a To-Be statement.)
A journey map is a collection of stages that the user will go through while engaging with the product. Each stage can be broken down into the specific tasks a user can accomplish at that stage. These tasks are the user stories.
Going through the design process can feel quite structured and like the methods need to be completed in a certain order, even though that rarely happens! Instead of fighting the chaos, User Story Mapping encourages a team to get one part of the process figured out as well as they can before moving onto the next part. For example, it’s fine to leave a mission statement roughed out and move onto the journey map. Once the details of the journey map are worked out, it’ll make the mission statement simpler to complete. There’s always the opportunity to return to previous work and improve it.
Ready for a real life example?
Do you think User Story Mapping can benefit your team and now want to run a workshop? Then head on over to Part 2 of this series where where we explain in detail how to run a User Story Mapping workshop.
P.S. Watch the video for a sneak preview
— — — — —
Eric Morrow is a Design Facilitator at IBM based in RTP. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
