 |
This artifact captures a concise, written description of a piece of intended functionality that has value to a user role of the system under development. This artifact also captures the stakeholders conditions of safisfaction about that piece of functionality. |
Domains: Requirements |
|
Purpose
- To capture functional requirements as short user scenarios that can be
prioritized, estimated, and developed within a short time box.
- To help the team and stakeholders know when the story is finished and implemented.
|
Relationships
Fulfilled Slots |
|
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Description
Main Description |
User stories capture the intended functionality of the system under development, from the user role
perspective. They are simple, clear, brief descriptions written using business language in the context in
which the need or capability will be used in the system.
A user story is in fact a reminder for further conversation between the team and stakeholders. User stories are
written down, but they are not meant to be contractual, or even interpreted without further discussions with the
stakeholders. The on-going interaction between stakeholders and the team (to discuss the details of a user story) are
more important than the resulting textual description itself.
|
Notation |
As a [user role] I want to [goal] so I can [reason].
|
Key Considerations
Well-written user stories possess the characteristics defined in the
INVEST Model. For example, one of the characteristics of a good user story is that
it can be tested even before development begins. This makes the user story valuable
to stakeholders in a practical way. |
Tailoring
Impact of not having | Without exploring the functionality of an application through realistic examples
of how a user might interact with it, the team might not be able to anticipate
the needs of each user role. Without this artifact, the team will create an application
that is less likely to meet the needs of the users, requires additional rework,
delays the implementation schedule, and dissatisfies the key stakeholders. |
Representation Options |
This artifact can be represented in the following ways:
- Index card: The user story statement can be captured on
the front of an index card, and the story confirmations can be included
on the back.
- Requirements management or composition tool,
such as IBM® Rational RequisitePro or IBM® Rational Requirements Composer: The user story statement can be captured as a descriptive
requirement in the tool, and the story confirmations can be additional
comments in that descriptive requirement.
|
More Information
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.
|
|