07 August 2009

Usage-Centered User Stories & Story Mapping 2

Forward-thinking post-agilists, like Jeff Patton and David Hussman, have been thinking about and speaking of ways we might help product developers enrich poorly conceived user stories and ease challenging planning sessions.

Our challenge as product owners and developers is to consider and to incorporate user experience and user activities into our thinking and software planning.

In this 2- part series, Part 1 presents the how-tos of usage-centered user stories and personas. In this post an overview of usage sequencing and story mapping is given.

Jeff Patton, David Hussman, and others, champion a particular sticky note scaffolding call Story Mapping for considering how people will use your software; a simple structure that positions stories in the context of tasked performed and software usage. See Jeff Patton's post User Story Mapping.
Story maps support the primary intent of user stories: rich discussion ~Jeff Patton
User Story Mapping is an approach to organizing and prioritizing user stories. Mapping seeks to frame stories in the context of the user's tasks/roles and by the values derived from the software by the people using it. Following Jeff Patton's story mapping technique, you'll get a sticky note festival of
  • Functionality of your software product,
  • Personas who derive value from it,
  • Activities the personas engage in, and the
  • Usage Sequence the personas follow
User Story Mapping gets its legs from activity modeling (cf. Constantine's Activity Modeling and Usage-Centered Design) and from Jeff Patton's interest in context specific approaches.

Problem - Size Matters

When tackling user stories we're often overwhelmed by the size of the job in front of us (e.g., That's Not A User Story, That's An Epic!).

We deal with largeness by breaking it down into smaller pieces. We're just following an evolutionary rule of survival
Never eat anything bigger than your head
Breaking things up helps, but often an epic deconstructs into a slew of disconnected stories.

How can we deconstruct a large story or epic in a way that communicates more than a random hodge-podge of work bits?

Solution - Story Mapping

The building blocks of Story Mapping are persona activities and tasks. Activities have characteristics relevant to our software. An activity is comprised of a sequence of persona tasks.

To start a mapping, begin with a persona activity (e.g., Persona identifies himself).

List the activities your persona performs on separate index cards. Arrange the activity cards in usage sequence from start to finish as if you were answering the question What does this persona do with our software?, as shown below.

Add persona tasks on yellow sticky notes below the time line in the order that you would tell the story of the activity. Try to preserve the order of workflow from left to right. Arrange the yellow stickies as if you were answering the question What does this persona do in Activity n? as shown below.

If your persona does some of the tasks simultaneously, stack them vertically. Imagine you're narrating the story of a workflow.
Whenever you'd have an OR in your sentence, you'll probably stack the task vertically as in the persona does this or this

Whenever you'd have a THEN in your sentence, you'll probably arrange task in a sequential, horizontally fashion as in the persona does this then this
An illustration of persona tasks performed simulaneously (vertically stacked yellow stickies) and sequentially (horizontally sequenced yellow stickies) is shown below.

One of the questions that arose in the Practical Agility session was
Where are the stories I can start queuing up in my backlog?
If we consider each activity as a large story or epic, then these epics deconstruct into child stories as shown below.

Each of the persona tasks (Child Stories) in the mapping above could be pulled into a backlog planning tool as user stories. Subsequently these stories would be tasked and estimated by developers.
Important Caveat - To avoid confusion,
Persona tasks are completely different and unrelated to developer tasks.
A persona task is something a person does with our software. A developer task is something a developer writes to meet the criteria contained on a story card.
Story mapping provides a scaffold to post and arrange your index cards (Activity or Epic) and stickies (Child Stories) in a meaningful way. By representing persona activities across the top of the map, we can visualize end-to-end use of our software. A successful story map shows the decomposition and workflow across a system. It communicates the persona experience.

Queued Reading