Thursday, November 12, 2009
User Stories
User Stories
User stories have been popularized through the
agile software development methodology called Extreme Programming.
Agile methodologies advocate lightweight approaches to requirements
engineering, project management, and other aspects of software
development. Rather than developing a comprehensive set of use cases or
a detailed software requirements specification, the analyst (who is
often the developer) works with users to collect stories. Extreme
Programming defines a story as "one thing that the customer wants the
system to do" (Beck 2000). In Extreme Programming, users provide
stories that the analyst concisely writes on an index card in natural
language text using the business domain's terminology. The stories are
elaborated and modified throughout the project based on user input. The
entire story consists of this initial story card, plus all the
subsequent conversations that take place regarding that story among
project stakeholders and perhaps user acceptance tests.
The examples of user stories given in books on agile
development cover a wide range of requirement categories and
abstraction levels (for example, Beck and West 2004). They range from
individual functional requirements to scenarios, use cases, product
features, business objectives, constraints, quality attributes,
business rules, user interface issues, and desired characteristics of
the product. The analyst might break complex stories into multiple
smaller stories that can be understood better, estimated better, and
perhaps implemented independently.
But the examples of user stories I've seen for agile development don't
differentiate various types of requirements information. Anything the
customer "wants the system to do" constitutes a story.
I have a problem with this definition of the term story. The essence of user-centric and usage-centric requirements elicitation is to focus on what the user wants to do,
not what the user wants the system to do. Asking the latter question
takes us back to the shortcomings of the original system-focused
requirements exploration process. The "stories" generated in this
fashion can become near-random bits of information, all churned
together in the discussion between analyst and customers. They lack the
usage-centered organizing structure that use cases and scenarios
provide.
I think of stories somewhat differently. I consider a
story to be a specific, concrete instance of a user's interaction with
a system to achieve a goal. Stories lie at the low end of the
abstraction scale. Earlier in this chapter, Figure 9-2 illustrated a story for a package-shipping store's new software system:
Chris wants to send a 2.5-pound package by
second-day air from Clackamas, Oregon, to Elba, New York. She wants it
insured for $75 and she wants a return receipt. The package is marked
fragile.
During user requirements development, you can take a
top-down approach or a bottom-up approach. You can start at the high
abstraction level by having some users identify use cases and then
prioritizing them and elaborating them into further detail at the right
time. A story such as the previous one provides a good starting point
for a bottom-up strategy. You can say to the store's user
representative, "Please tell me about the last time someone came into
the store with a package to ship." The user might relate an experience
similar to the one about Chris. This is a very specific instance of how
a store employee might have to prepare a particular mailing label. If
you don't have access to real users who can tell you stories, consider
inventing stories for the user-substitute personas you've identified.
(See Chapter 6, "The Myth of the On-Site Customer.")
The analyst can abstract upward to generalize that one
story, or a set of similar stories or scenarios, to cover a variety of
mailing label possibilities within the same use case. If you were to
treat each of these specific user stories as a separate use case, you
would wind up with a vast number of use cases, many of which are
identical except for small variations, say in the package weight,
destination, or shipping method. Such a use case explosion provides a
clue that you need to climb farther up the abstraction scale.
Use cases, scenarios, and stories all provide
powerful ways to hear and understand the voice of the customer. Unless
you focus on the user's goals and vision, your team can easily
implement a stunning set of functionality that simply doesn't let users
get their jobs done in a way they find appealing. And that would be a
shame.
No comments:
Post a Comment