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

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

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

Google Wave and Collaborative Projects

My tea kettle is whistling with more than lukewarm ideas on how we might use Google Wave for collaborative software projects.

To separate the steam from the high-pitched whistle of market evangelism...

Google Wave is a communication platform.

How might we use a real-time communication platform to make the push-pull of our collaborative software projects easier?

The Google Wave model promises to be a comfortable fit for seeding and feeding post-agile software projects. We might use Google Waves for

• Generating user stories
• Planning iterations
• Estimating tasks (e.g., real-time planning poker)
• Managing task boards and
• Spawning dashboard artifacts like burn-down charts

I like its threaded conversations of wavelets, blips, and drag-and-drop multimedia. Some Google Wave features that should make collaborative software projects easier are

• Bots and Gadgets Developers can embed gadgets and build robots that automate tasks within a Wave. A robot might read the content of a wave and then perform an action.
• Drag-and-Drop Sharing - Unlike clunky email attachments, you just drag-and-drop screen prints, wire-frames, buttons, stock photos, etc. on a Wave.
• Wiki-like, Hopefully Better - Anything within a Wave is editable by others. One may correct, append, or add commentary. One can only hope this is where project artifacts live rather than die (as with many project Wikis).
  
• Real-Time - See what your teammate is typing, character-by-character, unless it's planning poker - in which case you'll have to close your eyes.
  
• Playback - Playback any part of a Wave to see what the SME actually said about how something works.
  

The immediacy of instant messaging, combined with the richness of an anabolic Wiki, might prove to be a worthy collaboration tool. I like the concept of having team-member participation in threaded conversations (a traditional bulletin board), but also having features like playback and custom-robots that interrogate Wave content to perform actions.

The possibilities heat my water to boiling point. Robots are like having another person participate in a Google Wave conversation, except that they’re automated and they operate on the content of a wave. All extensible by common day-laborers like me.

The actions spawned by a bot might range from notifications like build failed or single sign-on test succeeded to spawning wavelets of unit test methods that are peppered with scenarios plucked from business-side requirements, discussions, and feature assertions.

Imagine a bot that parsed a business thread for Behavior Driven Development keywords like

As persona [X}
I want [Y]
so that [Z]

AND, parsed a business thread for scenario keywords like

Given initial context,
When an event occurs,
then ensure some outcomes.

then spit out a unit test methods?

Challenges to Adoption

Widespread adoption of a technology-driven phenomena like Google Wave will likely have to first hurdle cognitive and social models in search of digestible user metaphors (see Adina Levin's excellent post Google Wave: still in the lab, potentially mindbending for adoption).

Many of the operational metaphors that make things easy for users to understand simply don't exist for Wave yet. The Wave model mashes the familiar (email threads, wiki documents, and streaming communication) together. Instant messaging in your favorite messaging client is an easy model to follow. It is a simple post, response, & repeat. Will a multimedia, multi-participant Wave be so straight-forward? How will users find content efficiently? How will users invited into to a Wave conversation get up to speed with the other participants? Wave touts a replay feature, but is that the most efficient thread content primer?

More...

• Shannon Greywalker's Google Wave changes everything you know about agile collaboration and technical documentation.
• Ben Parr's Google Wave: A Complete Guide.
  
• Abel Avram's Google Wave’s Architecture.
• Google's Google Wave API.
• Spread Google Wave's Sandbox Developers Preview and Understanding Google Wave Development Part 1.
• Google Wave Interest Group on LinkedIn.
  

User Story Tweets

Try Tweeting your user story as if conciseness mattered.






Hosea Ballou, first President of Tufts University and the father of American Universalism, said

Brevity and conciseness are the parents of correction.
--Hosea Ballou

The Twitter Constraint is a 140-character limit Twitter imposes on Tweets. If you constrain yourself to follow the first tenant of DUA (i.e., Don't Use Abbreviations), LOL, and you experiment with the 140-character limit, it might make you write better user stories.

But don't carry brevity to extremes. Ballou also cautions

Never be so brief as to become obscure.
--Hosea Ballou

It's a sure bet you'll weigh in under a buck forty if you use the standard agile template

As a [user role], I want to [goal], so I can [reason].

But don't let something like a template constrain you. It's a guide; a starting point. Don't be dogmatic - about anything.

There are zillions of posts advising you about Writing Good User Stories.

Discover the language what works for you and your team. For example, I like personas, like Help-desk Hector, that encapsulate the user role.

Laura Brandau's Bridging the Gap has an imformative post about the 140-character Twitter Constraint and writing good requirements. She asks

• Do you incorporate ambiguous words like “adequately”, “timely”, or “high-quality”?
• Do you use a long phrase when a single word conveys the same meaning?
• Do you combine multiple requirements into one long sentence?
• Do you include lengthy introductory statements that add little value such as “The ability to” or “The system shall”?

To paraphrase William Strunk, the senior author of the legendary The Elements of Style (1919):

Vigorous story* writing is concise. A story* should contain no unnecessary words...for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.
--William Strunk, Jr.

* The word story was inserted by me.

I don't advise you hold yourself to an arbitrary limit of 140 characters per story, rather I am suggesting you consider the 140-character limit as an exercise.

Perhaps you'll discover you can cross-cut your way to the crux without sawing off the scaffold of meaning.

I leave you in the capable hands of Sir Winston Churchill (1874-1965):

This report, by its very length, defends itself against the risk of being read.
--Winston Churchill

User Story a 2-bit Use Case?

A new member of Agile .Net Practitioners, a LinkedIn group I moderate, asked

When you talk about User Stories, how does that differ from Use Cases?

Alistair Cockburn said

A User Story is to a Use Case as a gazelle is to a gazebo

a catchy one-liner he later amended to

A User Story is the title of one scenario whereas a Use Case is the contents of multiple scenarios

A slightly better statement to which Jim Standley replied

...a story is a promise to have a conversation and a use case is the record of the conversation.

By all accounts Ward Cunningham coined the term User Story. By Ward's definition, a User Story is

...a story about how the system is supposed to solve a problem or support a business process. Each user story is written on a story card, and represents a chunk of functionality that is coherent in some way to the customer.

For those wondering how a User Story differs from a Use Case, see Ward's User Story and Use Case Comparison. A pithy excerpt from Ward's page comes from Alistair Cockburn:

"...Think of a User Story as a Use Case at 2 bits of precision. Bit 1 of precision names the goal of the use case, Bit 2 adds the main scenario. Bit 3 adds the failure conditions, Bit 4 adds the failure actions. Bit 5 adds data description of the in/out data. I would put Catalysis at a 6th bit
of precision, as they include a model also of the recipient of the message...."

My Story Paradigm

If a paradigm is 20 cents, here's a pair of dimes for you about user stories straight from the trenches of C-Sharpistan.

Following the advice of David Hussman, every developer's mantra could be to coax their business customers into "thinking and talking in tests".

For me, the most crucial item in a story is a list of business-stated test statements; preferably using mutually recognizable, and previously agreed upon, personae. For example, tell me, in concise, granular statements what “Albert the Anonymous Guest” can do:

1. Albert the Anonymous Guest may view a list of all groups that are internally designated as “Open Access”.
2. Albert the Anonymous Guest can filter groups by Subject Area.
3. Albert the Anonymous Guest can sort groups by Name.

These statements rapidly translate into unit tests like

• ViewGroupsByAccess,
• FilterGroupsBySubjectArea, and
• SortGroupsByNames.

What constitutes done is an ongoing challenge in agile. A list of business-stated test statements makes done rather cut and dried.

If my test harness can demonstrate and pass the aforementioned tests, the story is complete and Bob's yer Uncle.