06 August 2009

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.
    Share/Save/Bookmark

    1 comment:

    1. I really like the personas idea! But, with all respect, I don't see how breaking a story down like this captures the essence of the story? I'd use a story like "As Doug the Delivery Dude I need to manually register packages so that if the scanner fails I can still feed the tracking system". Then have the team figure out a usable solution using the personas card for creating usability and functional acceptance criteria and negotiate it with the PO.

      ReplyDelete