An expanded version of the user story mapping lightning talk, with more information about the three questions guiding discovery workshops and more contexts in which the user story map can be used.
Find out more about our services: http://cakt.us/customwebservices
3. Getting a Project Started with Discovery
1. What is the problem we’re trying to solve?
2. For whom are we solving this problem?
3. How are we going to solve the problem?
4. Getting a Project Started with Discovery
1. What is the problem we’re trying to solve?
○ What are we doing?
○ Why are we doing this work?
○ What are the business goals?
○ What are the project goals?
○ What constraints and risks do we need to be aware of?
○ How will we know the project has been successful?
(See blog post, Product Discovery Part 1: Getting Started on www.caktusgroup.com)
5. Getting a Project Started with Discovery
2. For whom are we solving this problem?
○ Who are the users?
○ Where do users come from?
○ What are their goals?
○ What outcomes do they seek?
○ What pain points do they have?
○ What user roles does the application have to support?
(See post, Product Discovery Part 1: Getting Started on www.caktusgroup.com)
6. Getting a Project Started with Discovery
3. How are we going to solve the problem?
○ What user flows, tasks, subtasks, and alternative actions do
we need to support within the application.
(See blog post, From User Story Mapping to High Level Release Plan on www.caktusgroup.com)
9. Examples of high level user tasks
Manage
an order
Process
payment
Define
number of
patrons
Divide
order
between
patrons
Add tip to
separate
receipts
Waiter Patron(s)
11. Examples of high level user tasks
Manage
an order
Process
payment
Define
number of
receipts
Divide
order
between
patrons
Add tip to
separate
receipts
Waiter Patron(s)
Create
order
Edit
order
Add
/delete
order
items
Charge
credit
card
Refund
charge
Specify
number of
patrons
Edit
number of
patrons
Divide the
receipt by
number of
patrons
View total
per patron
Divide the
receipt by
order items
Based on the
receipt value
divided by #
patrons
Based on
itemized
order values
13. Examples of high level user tasks
Manage
an order
Process
payment
Define
number of
receipts
Divide
order
between
patrons
Add tip to
separate
receipts
Waiter Patron(s)
Create
order
Edit
order
Charge
credit
card
Refund
charge
Specify
number of
patrons
Edit
number of
patrons
Divide the
receipt by
number of
patrons
View total
per patron
Divide the
receipt by
order items
Based on the
receipt value
divided by #
patrons
Based on
itemized
order
values
Add
/delete
order
items
16. Contexts for Applying User Story Mapping
● As part of the discovery workshop
● On its own, as an internal team activity
● To map out an entire application
● To map out a subset of features
17. Writing User Stories
● Front of the card: As a [user type], I want
to [feature, functionality], so that [benefit]
● Back of the card: Acceptance criteria
20. “Plans are useless, but planning is indispensable.”
General Dwight David Eisenhower
21. What Works
User story mapping
● Understand what the required tasks are, how they break down, how they relate to each
other, and which ones are higher priority.
● See the entirety of the project in one physical representation. It makes it easy to keep
discussions at the right level (rather than too high-level or too detailed).
Writing user stories
● Get the first iteration of a backlog done in 1-2 hrs.
● Share knowledge about the project across team members.
Release plan
● See project milestones at the onset of the project.
22. Lessons Learned
User story mapping
● Need to spend more time during the mapping activity updating the stories in the map as the
group's understanding of the project evolves.
Writing user stories
● Need to get together with the entire dev team, including people who did not attend the
workshop, and talk through the workshop outcomes prior to writing user stories.
Release plan
● Need to strengthen the understanding of a release plan as a transient tool rather than a
commitment to doing certain things in certain sprints.
My name is Basia Coulter, I am a UX Designer at Caktus Group where I facilitate discovery workshops. Today, I want to talk to you about how we use user story mapping to arrive at a high level release plan.
Caktus Group is a software development company that specializes in building Django web applications. We’ve been around for 10 years this year!
Although Caktus is not a business or marketing consultancy and we’re not advising our clients on their business or marketing strategy, it is crucial that we have some basic understanding of the client’s business goals. A lot of valuable information comes out of these discussions that is relevant to a successful development effort, so I encourage people to always have those conversations. Sometime, for example, we find out that the client has not answered some of these questions for themselves, and having that conversation flags potential difficulties. Sometimes stakeholders for the first time articulate the project goals clearly.
Identifying user roles is often the most challenging activity. For example, one of our clients in response to the question about user types listed about a dozen of “user types” that simply represented a variety of professions their users may have. It was through a guided exercise during the workshop that we were able to narrow down that list to 3)
User story mapping has been popularized by Jeff Patton who has written a book, “User Story Mapping.” It is a visualization technique that uses sticky notes to map out a digital application.
User story mapping starts by outlining the narrative flow (or a backbone). The narrative flow consists of high level user tasks or user outcomes within the application.
It’s important to make that as complete as possible before moving on to mapping out details
Imagine an application that helps the restaurant divide checks between patrons. Examples of high level user tasks might include “Manage Account,” “Manage To-do List,” “Share To-do List.” If there are multiple user types, it may be good to have segments of the narrative flow dedicated to respective user types. It’s helpful to finalize the narrative flow before moving on to detailed tasks otherwise, it may be logistically difficult to move the sticky notes around
Once high level tasks are identified, we move on to unpacking what detail tasks they consists of, what subtasks the user might have to conduct, or what alternative actions might be possible.
Once we’ve mapped out the entire application in this way, we define the set of most valuable features. We ask our stakeholders which features the application could go live without and still deliver on user value.
Why are we doing all this in a workshop setting with stakeholders involved? In order to build a shared understanding about which features are essential for the product.
Here is an example of a user story map from an actual workshop. You can see the narrative flow, tasks, and the MVP line
Here is an example of a user story map from an actual workshop. You can see the narrative flow, tasks, and the MVP line
We then, as a team, translate the brief phrasing from the sticky notes into fully fledged agile user stories that follow the prescribed format and have acceptance criteria
The devs then estimate the stories by first arranging them from low to high effort, and than assigning story points using a modified Fibonacci scale. This activity is facilitated by our Scrum Master, Charlotte Fouque
Based on the dev team’s past velocity, the project manager translated the estimated user stories into a release plan
Although the release plan changes as the project moves forward, this process gives the dev team a good foundation on which to begin the base the development effort.
Some of the stories written earlier in the workshop weren't quite in sync with our final understanding of what we wanted.Writing user stories: It was a bit frustrating at times. Since some of us were in the workshop and some weren't, we were trying to communicate complex ideas quickly to the people who weren't there, not always all that successfully.