Even though user stories are an informal technique for capturing requirements
in a lighter way, to promote interaction between teams and stakeholders, it
helps to know what makes a "good" user story. The INVEST model defines
them as Independent, Negotiable, Valuable, Estimable, Small, Testable. This
model was introduced by William Wake [WAK03]
and has been used by many other authors in the agile development-related literature.
The next sections explain characteristics of good user stories,
based on the INVEST model. For more information, see [WAT08] and
[COH04].
Independent
Identify and capture user stories that are as independent as possible.
Independent, in this context, means that you are able to assign that
user story to be completed in a defined period of time with as little dependency
on other stories as it is feasible to have. You may realize that completely
removing dependencies is not only impractical for some types of applications,
but also undesirable. In some cases, dependencies may make sense. For example,
the "Forgot user ID and password" user story depends on the existence of the
"Log in to the system" user story. In this case, it makes sense to group stories
into themes, which are a better way to plan for and develop together those user
stories that have some level of expected dependency. (See the definition
of themes in Epics and Themes.)
Another aspect of user stories being independent is to make sure that there
is no functionality captured by more than one user story, which helps avoid that
redundant work is done by two or more team members.
Negotiable
Identified user stories each contain a short description of a user performing
something in the system-to-be to achieve a goal. This description is initially
at a low level of precision, and by no means should be seen as a contract.
It is a reminder that we need to communication continually with stakeholders
to understand the stories better and refine their details, based on the dialog.
The trick is to capture just the right amount of detail, which may be constrained
by subjective interpretation. A good sign that a user story has too much
detail, too early, is when the team assumes that they already know all they
need to know to develop the story without further communication with stakeholders.
As stakeholders add details to stories, team members can capture high-level
design decisions to include in the stories, as well as elements that are candidate
for user interfaces. But stories need to remain works-in-progress and negotiable.
This means that when a team member is developing a user story, if she decides there
is a better way to implement it (despite of the details captured in the user
story) and still achieve the stakeholders goals, that should be option,
and the stakeholders should be open to negotiating that alternative.
Valuable
This might mean: User stories need to be valuable to stakeholders. But that
raises the question of "Which stakeholders? Users or owners of the system?"
That depends. Some stories are written with the end user in mind, and some may
be written with other types of roles in mind. Therefore, a better statement
would be: user stories need to be valuable to user roles, whomever those roles
represent. The easiest way to adhere to this is to write the user story from
a business perspective, rather than a technology perspective, and to use natural
language.
One caveat about capturing nonfunctional requirements (such as performance
or availability) as user stories: These typically affect many functional user
stories and should be worded in a way that expresses that dependency. See Handling Nonfunctional Requirements for more information.
From a development standpoint, the resulting implementation also needs
to show value to stakeholders. It is expected that developers will
implement a complete pass through all layers of the application. For example,
if a developer implements all of the database access interfaces at once, this
implementation may show nothing of value to an end user. On the other hand,
there is much more value from a user standpoint if a developer implements a
user story that "cuts a vertical slice" across the various layers of the
application, meaning that the developer is really implementing user interface,
business logic, and database access to support that user story.
Estimable
Valuable, agreed upon, and right-sized stories should be estimable —
something that you can use as a basis for an estimate. Failure in estimating
user stories size often leads to failure to deliver
the solution with the value that stakeholders expect.
There are are different reasons that it might be difficult to estimate user
stories size. For example, the user stories might be too broad; they might need
to be broken down into smaller stories or development tasks that are more granular
and easy to prioritize and estimate. Another example: the team may lack information
or knowledge about the domain or technology to be used, thus they can't
provide an estimate for user stories size until they have access to a domain expert
or can investigate the new technology to be used.
Small
As mentioned previously, "small" stories are easier to estimate. They
should also be able to be developed within a reasonably short time frame
(typically with one person working for a few days to a couple of weeks), to
provide value to stakeholders as soon as feasible.
The question is: how big is small? There is no right or wrong answer
here, but as a general rule, there are indicators of a user story being too
big. If the team has difficulty in estimating size and effort of a user
story, that might mean that the story needs to be broken down into smaller stories
or development tasks for a more accurate estimate to be provided. If it
would take more than a month for one person to develop the user story,
that's another indicator the story needs to be broken down.
Not all stories are broken down early in a project, even if it seems that
they need to be. Many larger stories (also called epics), remain
on the work items list as they are until it is time to develop them. At
that time, the team discusses the need to break them down for the purposes of
planning, estimating, and development. (Learn more about epics in Epics and Themes.)
Testable
Good user stories should be able to be tested and validated,
and this needs to be true even before development begins. Understanding how
to test a user story means that the user story is understood, the value
stakeholders want out of it is clear, and we know when development is successfully
finished. Discuss with stakeholders — and capture in each user story —
the conditions that will make the user story considered fully developed.
In general, larger user stories, such as epics, are harder to test because
of their size or complexity. Stories that represent nonfunctional requirements
also may be hard to test, because there needs to be a clear, quantitative definition
of test conditions. For example, define a test scenario that says "the
administrative report needs to run in 3 seconds or less," rather than saying
"the administrative report needs to run fast."
|