 |
User stories are one of
the primary development artifacts for XP project teams.
A user story is a very high-level definition of a
requirement, containing just enough information so that
the developers can produce a reasonable estimate of the
effort to implement it. A good way to think about a
user story is that it is a reminder to have a
conversation with your customer (in XP project
stakeholders are called customers). As you can see in
Figure 1 user stories are small, much smaller than use
cases. In XP a user story must be able to be
implemented by two people in a single iteration/cycle,
therefore if you’re working in one week iterations each
user story must describe less than one week worth of
work. |
|
Figure 1. Example user stories.
- Students can purchase monthly parking passes
online.
- Parking passes can be paid via credit cards.
- Parking passes can be paid via PayPal ™.
- Professors can input student marks.
- Students can obtain their current seminar
schedule.
- Students can order official transcripts.
- Students can only enroll in seminars for which
they have prerequisites.
- Transcripts will be available online via a
standard browser.
|
Each of the statements in
Figure 1 represents a single user
story. User stories are often written on index cards as
you see in Figure 2. Index cards are very easy to
work with and are therefore an inclusive modeling
technique. You can easily maintain a stack of
prioritized requirements by moving the cards around in
the stack as appropriate. You can see that the
user story card includes an indication of the priority;
I often use a scale of one to ten with one being the
highest priority. Other prioritization approaches
are possible – priorities of High/Medium/Low are often
used instead of numbers and some people will even assign
each card it’s own unique priority order number (e.g.
344, 345, …). Pick a strategy that works well for your
team.
Figure 2.
User story card.
You also see that the priority changed at some point in
the past, this is a normal thing, motivating the team to
move the card to another point in the stack. The
implication is that your prioritization strategy needs
to support this sort of activity. My advice is to keep
it simple.
The card also includes a unique identifier for the user
story, in this case 173, and an estimate for the effort
to implement the user story. One way to estimate is to
assign user story points to each card, a relative
indication of how long it will take a pair of
programmers to implement the story. The team then knows
that it currently takes them on average 2.5 hours per
point; therefore the card in
Figure 2 will take
around 10 hours to implement.
An important concept is that your
project stakeholders write the user stories, not the
developers. User stories are simple enough that people
can learn to write them in a few minutes, so it makes
sense that the domain experts (the stakeholders) write
them.
You often create a stack of user
stories during cycle 0 to identify the scope of your
system. During development cycles you will identify new
user stories, split existing user stories when you
realize that they’re too large to be implemented in
single cycle, reprioritize existing stories, or remove
stories that are no longer considered to be in scope.
The point is that your user stories evolve over time
just like other types of requirements models evolve. A
significant advantage of user stories is that because
they’re often described using a very simple technology,
index cards, and because they’re small that they are
very easy to work with and to evolve.
User stories can be used to
describe a wide variety of requirements types. For
example in Figure 1 the
Students can purchase parking passes online user
story is a usage requirement similar to a use case
whereas the Transcripts will be available online via
a standard browser is closer to a technical
requirement. The point is that although the name “user
story” is similar to “use case” that user stories are
simply a small version of a use case, they are in fact a
different type of development artifact.
Because user stories contain so
little information you will need to flesh them out a bit
when you first work with them. During the estimation
effort it is quite common to list programming tasks
required to implement the user story. When you start to
work on implementing the user story you may decide to
create some rough sketches of what you’re going to
build, perhaps a
sketch of a screen or a
UML activity diagram representing the relevant
business logic. User stories are merely the starting
point.
"Formal" User Stories
In
User Stories Applied Mike
Cohn suggests a more formal
approach to writing user
stories. He suggests the
format: As a
(role) I want (something) so
that (benefit).
For example, the user story
of
Figure 2 could be rewritten
as "As a Student I want to
purchase a parking pass so that
I can drive to school".
This approach helps you to think
about who a certain feature is
built for and why.
This artifact description is excerpted from Chapter 5 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
This book is the
defacto standard for how to write user stories.
Period. |
|
|
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
|
User Stories (Don Wells) |
|
A good white paper. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
Translations
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full
description of what I do, and how to contact me, can be
found here.
|
