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 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.

Queued Reading

Activity Modeling: Toward a Pragmatic Integration of Activity Theory with Usage-Centered Design by Larry Constantine.

About Face 3: The Essentials of Interaction Design by Alan Cooper, Robert Reimann, David Cronin.

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

User Story Mapping PowerPoint by Jeff Patton

How You Slice It blog post by Jeff Patton

Agile User Experience Design by Jeff Patton (March 2010)

Interview - David Hussman on Helping Organizations Adopt Agile