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.
Relationships
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. User stories are an important input to other practices.

User stories are prioritized, estimated, decomposed into tasks, and scheduled as part of project management practices.  User story details guide the design, implementation, and testing of the story.

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:

This practice focuses on two work products:

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