Practice: User Story-Driven Development |
This practice describes how to capture requirements as user stories, which are then used to guide planning, development, and testing.
Purpose
Consider adopting this practice if you are looking for a requirements approach that has the following characteristics: Requirements captured from the users' perspective Requirements defined in terms of incremental capabilities that can be developed and delivered Simple and straightforward technique requiring minimal training Requirements kept brief, with details intentionally deferred to implementation, to minimize overhead of changing requirements Informal requirements specification
Background
A user story captures the intended functionality of the system under development, from the User role's perspective. It is a simple, clear, brief description in business language, expressed within the context of the need or how the capability will be used in the system. Here are a few examples: As an ATM user, I want to use my debit card to pay my electricity bill. As a branch manager, I want to track transactions at my branch so that I can identify customers to upsell. As a student, I want to enroll in a course so that I can complete my degree. As an online customer, I want to search for items so that I can add them to my order.
Main Description
The User Story-Driven Development practice describes how to capture requirements with user stories and how the user stories influence or guide later decisions in the development lifecycle. Figure 1 depicts the relationships between this practice and other practices in these design, testing, and project management disciplines: Shared vision: One of the inputs to finding user stories is the vision for the system under development, but ongoing interaction with stakeholders is an essential part of finding out user stories. Release planning: User stories are initially prioritized and estimated. Iterative development: The high-priority stories are broken down into more granular stories (as needed) and into development tasks. As part of iteration planning, stories are assigned to team members, or they sign up for them, and the effort to complete each story is estimated. Evolutionary design: The details captured in the user story during conversations with stakeholders that happen in each iteration guide the design and implementation of the story. Test-driven development: The user story details also represent the conditions of satisfaction that guide the testing activities. This helps confirm that the story is complete and accepted by stakeholders. Note: The arrows in Figure 1 represent dependencies between practices. For example, test-driven development depends on the user stories that are defined as part of this practice. Figure 1. Practices dependencies
How to read this practice
The best way to review a practice is to familiarize yourself with the enablement materials and then review key concepts, work products, tasks, and the more detailed guidance. You can do this either by reviewing the guidance category directly or by navigating from tasks and work products to their related guidance. You might first want to become familiar with general requirements concepts: Requirements. Then become familiar with concepts related to user stories: User Story Concepts Overview Epics and Themes INVEST Model This practice focuses on two work products: User Story User Role User stories go through similar states: they are identified and outlined so that they can be prioritized, and then details are added. Tasks lists the relevant activities. In addition, guidelines and tool mentors associated with each task provide details about how to perform the task. Templates associated with the work products guide you in their completion and evaluation. Measurements can guide you on assessing how well you are following this practice.
Levels of Adoption
If you need a detailed requirements specification, or if there is a large number of requirements or complex dependencies between requirements, it might be better to use alternative techniques, such as structured use cases. For more on how to adopt this practice, see the How to Adopt the User Story-Driven Development Practice roadmap.
Additional Information
### Books and Articles
Mike Cohn 2004. User Stories Applied: For Agile Software Development. Adisson-Wesley Signature Series.
| This book presents the concept and technique of user stories as a way to gather customer requirements.
Scott Ambler 2004. The Object Primer Third Edition: Agile Model Driven Development with UML 2. Cambridge University Press.
| This book covers the basic fundamentals of object-oriented software engineering and modeling techniques.
For more information on this practice, see the practice resource page IBM® DeveloperWorks®.
Relationships
Content References | How to Adopt the User Story-Driven Development Practice Key Concepts Epics and Themes INVEST Model Requirements User Story Concepts Overview User Role User Story Tasks Capture Confirmations Identify User Roles and User Stories Refine User Roles and User Stories Managing User Stories with IBM Rational Team Concert
Inputs | [Project Work] [Technical Specification]
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.