User Stories are part of an Agile approach that helps shift the focus from writing about requirements to talking about them. All Agile User Stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
User Stories provide a light-weight approach to managing requirements for a system. User Stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a <type of user>, I want <some goal> so that <some reason>.
User Stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
Thus, we can consider a User Story is made up of a Card, Conversation, and Confirmation.
A short statement of function captured on an index card and/or tool encourages the conversation. The details are figured out in future conversations between the Development Team and the Product Owner or customers. This approach facilitates just in time requirements gathering, analysis and design by the following activities:
- Slicing User Stories down in release planning or Backlog Refinement
- Tasking User Stories out in Sprint Planning
- Specifying acceptance test criteria for user stories early in development
As you have probably figured it out, the Confirmation part of a Story is entirely related to the acceptance criteria. Each story should have acceptance criteria. This is often the basis for tests. Acceptance tests confirm that the story was developed correctly.
Good quality Stories – INVEST guideline
Dependencies lead to problems estimating and prioritizing. Ideally you can work on a single story without pulling in lots of other stories.
Stories are not contracts. Leave or imply some flexibility
Valuable to users or customers, not developers. Rewrite developer stories to reflect value to users or customers.
We need to be able to estimate our User Stories so that we can use them to create a plan.
Complex stories are intrinsically large. Compound stories are multiple stories in one. A story is sized appropriately when it can be completed in one iteration.
You should have an easy and binary way of knowing when a story is finished. Done or not done; not patially finished or “done…except…”.