Concept: User Story Concepts Overview |
This page introduces concepts related to writing a user story.
Relationships
Related Elements | Epics and Themes User Story
Main Description
### User story A user story is a brief description of a system requirement from the user's or stakeholder's perspective. User stories can be defined at a high level and decomposed as needed into smaller stories. User stories are a simple and straightforward way to document requirements. Because they are brief, the overhead is low for creating and updating them as requirements change. Because they are focused on delivering value, they are a good basis for prioritizing and implementing. User stories work well when a complete detailed requirements specification is not required or desired. They tend to be relatively informal and incomplete, leaving details to be resolved during implementation. A story does not include all of the information that makes up the requirement. It is just enough information to identify the requirement and to remind everyone what the story is about. Writing can be supplemented by a photo when that makes sense. This helps the team think of the product in terms of solving needs of real people. 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 I can complete my degree. As an online customer, I want to search for items so I can add them to my order. ### User role A user role represents a population of users that share similar attributes and interaction with the system. Each different user role has different characteristics or attributes that help identify different ways that each interacts with system. The use of roles while writing user stories helps us avoid writing the stories from a single user's perspective. It is typical that we start by identifying individual users of the system, then we need to organize, consolidate, and refine them into more generic user roles. ### Conversation Another important concept is not to worry about getting all of the details into the story. It really needs to be a commitment to have a conversation (actually, a lot of them). Stakeholders can make up their minds as the story is in development. Likewise, as developers need more information or need to ask questions, they should ask (and not expect everything to be spelled out up front for estimating purposes). What's important is to foster a healthy communication between stakeholders (or their proxies) and product owners with the development team. ### Confirmation It's usual that agile teams do a lot more testing along the lines of development, compared to traditional teams. In fact, they often write a test before they write sufficient production code to fulfill that test, and then they proceed develop the next iteration. These teams work very closely together and, ideally, work closely with their stakeholders. Changing requirements are seen as a competitive advantage, not as something that you need to prevent, as long as you can act on them. Agile teams deliver working software at every iteration, thereby providing concrete evidence of actual progress on the project. Daily builds, or even builds multiple times a day, are highly desirable. Shorter iterations are desirable, from as short as one to two weeks. Four week-long iterations are a common recommendation, although iterations of up to eight weeks will occur at scale.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.