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

Usage-Centered User Stories & Story Mapping 1

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, this post presents the how-tos of usage-centered user stories and personas. In Part 2, an overview of usage sequencing and story mapping is given.
Last night, I attended DevJam‘s Practical Agility session held in the garage-band basement below Java Jack’s Coffee Cafe. David Hussman, with props and praise to Jeff Patton and Allan Cooper, hosted and gave an engaging session to our group titled Story Mapping and Personas.
Following is my synthesis of the informational highlights of the usage-centered user stories and personas portion of the session.

Problem – Our User Stories Stink

With David’s prompting, Practical Agility participants shouted out the following reasons our user stories stink:
  • Titles – Bad, non-descriptive titles are all-too common
  • Acceptance Tests – No list of assertions developers can write tests against
  • Templates – Overuse of and Mindless filling in of As a User… templates
  • Software Tools – Crummy software tools that are hard to use and introduce counter-productive habits.
  • Confusion about what’s a story and what’s a task

Solution – Entitlements
Take time for a title. The word Placeholder is almost always insufficient. The assorted hindrances of the “Agile” software your company purchased and decreed you must use is no excuse. Shouldn’t a story title indicate a function, feature or activity? Often story titles are a verb phrase like view list.
Make it short. Make it burn.

It is with words as with sunbeams. The more they are condensed, the deeper they burn. ~Robert Southey


Solution – Personas

Use personas, please. Creating and using personas is a simple, useful productivity boost. Why doesn’t every software team use them? Without a Vulcan mind meld, have we truly realized the ways in which people will use our software?
Dude has to know who he’s selling to ~David Hussman
Marketing professionals have long created personas to understand the whims and proclivities of their buyers. We should too. There is a reason staunch cola loyalists can’t distinguish between Coke and Pepsi in blind taste tests. It is because the caramel-colored, sugar water snake salesmen know precisely what triggers your buy impulse…and it’s not taste.
Want to try personas? Make a persona page for each category of persons who will use your software. If there’s significant overlap between personas, pare your personas to the most common usages, then evaluate sub-cases.
A persona is happy if it has the following:
  1. A Picture. Go crazy.
  2. A Name. I like alliterations like Doug the Delivery Dude. Go crazy.
  3. Columns for Characteristics and Values (i.e., the utility derived from the software).
Imagine the software we’re about to write is attached to a scanner that tracks what goes in and out of Doug the Delivery Dude’s van. In 95% of the cases, packages are hand-scanned by Doug without incident. In 5% of the cases, the package doesn’t scan. That’s where our software comes in…
Our software indicates an error condition when scanning fails and requires manual entry by Doug. Doug needs to confirm his identity, confirm the time, confirm his location, and most importantly, key in the package identifier.
In the characteristics column we need to consider:
  • The context the software task or activity is performed in (e.g., standing in a dimly lit space)
  • What the task performance or activity is (e.g., data entry)
In the values column we need to consider the criteria for the software to support task performance. What value would Doug hope to derive from our software?
Here’s a swing at a persona page for Doug.
Doug Doug the Delivery Dude
Characteristics Values

  • experienced, but could be new employee
  • might have big fingers
  • impatient, since compensation is throughput-based
  • distractible
  • data keying done in dimly lit van
  • might need reading glasses

  • Feedback if data entry is spurious (sound)
  • Instantaneous confirmation (sound)
  • Alternative if software locks up
  • Reminder if anything missing (sound)
  • Bright and high contrast (delivery van is dark)


Solution – Do Lists

A Do List is another name for Acceptance Criteria. There is fuzziness about the phrase acceptance criteria. Developers complain about story cards not including acceptance criteria. Why? Because developers use acceptance criteria to declare a task or story is done. As a product owner, give developers a bulleted Do List of every result that should happen. Developers, in turn, will convert the Do List into tests as a starting point for writing software. QA testers use the same Do List as a functionality checklist.
Product Owner’s Do List Developer’s Test

  • Doug’s identity is confirmed
  • The time is confirmed
  • Doug’s location is confirmed
  • This package is identified
  • Is Doug’s identity confirmed?
  • Is time confirmed?
  • Is location confirmed?
  • Is package identified?
  • Story Card Wrap


    We’ve got a persona and a do list. Now, what’s a good story title? While it might seem backwards, it’s advantageous to decide on a story title after you have a persona and a do list since you will have done more noodling about the essence of the story. At least revisit a working title to refine it after you have a persona and a do list.
    What is Doug’s activity when he’s using the software? Remember the context. Doug’s scanner has failed, so he must use our software to manually key data. How about Enter Data as the story title?
    The Not So Hot Classic Template:
    As a User I need to __________ so that ________.
    A Better Thingamajig That Mustn’t Be Called a Template:
    As Persona I need to Story Title so that
    do item – acceptance criterion
    From our example:
    As Doug the Delivery Dude I need to Enter Data so that my
    identity is confirmed
    As Doug the Delivery Dude I need to Enter Data so that the
    time is confirmed
    As Doug the Delivery Dude I need to Enter Data so that the
    location is confirmed
    As Doug the Delivery Dude I need to Enter Data so that the
    package is identified
    In Part 2, we’ll dive into usage sequencing and story mapping.