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."
|