Artifact: User Story |
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 | [Technical Specification]
Roles | Responsible: Analyst | Modified By: Analyst
Tasks | Input To: Capture Confirmations Refine User Roles and User Stories Identify User Roles and User Stories | Output From: Capture Confirmations Identify User Roles and User Stories Refine User Roles and User Stories
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. Team collaboration tool, such as IBM Rational Team Concert (RTC): The user story statement can be captured as a work item in the tool, and the story confirmations can be included in the description or as additional comments in that work item (see Managing User Stories with IBM Rational Team Concert for more information). 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
Concepts | Epics and Themes INVEST Model User Story Concepts Overview
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.