Agile and the Elusive Big Picture: How Storymapping Brings UX into the Agile Framework, by Elisa Miller
Where do user stories come from? Elisa read User Story Mapping, by Jeff Patton, and went to find everything else he read. She felt that it helps get developers out of the weeds. It’s not difficult, but it’s really useful to do story mapping to understand the big picture for agile.
A story map is a way of connecting user stories and organizing them.
Where do user stories come from?
- Product owners
- Business analysts
- Help desk/support team
- The project goals
- Conversations with users
- Sales teams
- UX team
- Monitoring user communities
There’s a lot of disagreement on who owns what and how to get feedback from users. If everyone can get to a user-centered perspective, we’ll get to more agreement.
Traditional user stories
Traditional user story: As a ____ I can ____ so that _____.
Problems with the traditional story:
- Roles are not a suitable focus of attention
- The form is unnecessarily wordy and repetitive
- The use of first person is counter-productive, since you are not your user
- There’s not a clear situation/use case/problem from the story
A good user story should focus on the persona, and it should be created collaboratively.
New user story
<persona [maybe role]> <performs a task> [if needed, add <so that obvious goal>]. The focus is on the persona, role is optional, it fixes the biases and changes the perspective, and the story isn’t needlessly long.
Context focuses on the user activity, to keep the project focused on the user. Then we build a map to tell the bigger story. But the key is understanding the user. We say the persona’s name, rather than “I” to focus on being different from the user. We focus on the task, not a “want.”
This can come out of customer journey mapping, so that we have an understanding of what the goals are first, and then the stories identify the tasks that accomplish those goals.
- Based on the customer journey, have the team start writing sticky notes of user stories
- Then, as a team, start organizing them
- Note any duplicates, remove them
- Put them in a basic order the user would follow (also might be based on a journey map)
- Manage email (overall task): compose email, read email, delete email
- Manage calendar (overall task): view calendar, create appt, update appt, view appt
- Walk through user scenarios, or even ask users to walk through their job functions, to check that no tasks have been left out
- Below sub-tasks, get even more granular. Within search, add “search by keyword, search by name, etc” – these are features.
- Prioritize the features.
- This turns into the breakdown of sprints.
Why do it?
- It allows you to see the big picture, and how that connects to sprints
- It creates a shared understanding of the project
- It is a tool for better decision making, for scrum breakdowns
- It encourages iteration
- It’s useful for discussing and managing scope