Definition
User stories are short, simple descriptions of a requirement told from the perspective of the person who would like a new feature.
User Stories are the basic unit of communication, planning, and negotiation between the Scrum Team, Business Owners, and the Product Owner. Stories consist of the following elements:
A description, usually in business terms
A size, for rough estimation purposes, generally expressed in story points (such as 1, 2, 3, 5...)
An acceptance test, giving a short description of how the story will be validated.
Stories help create small “chunks” of value that can predictably be designed, built, and tested in a shorter interval e.g., a Sprint. Properly written and executed, a user story enables rapid feedback that promotes faster learning over the course of iterative & incremental development cycles.
Definition of Done vs Acceptance Criteria
While the two terms are often confused, a simple rule of thumb is the Definition of Done applies to (almost) all work items, where Acceptance Criteria may be unique to just one. This graphic helps differentiate between the two.
Enabler Stories
Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance. They can be expressed in technical rather than user-centric language (as mentioned in above figure)
Stories are typically sourced from splitting Epics. [Following is an example from SAFe ©, if we have a good example at Canadian Tire that is generic enough we should use it]
Qualities of a good User Story
- Captures user’s expectations
- Is in the language of the user, not technical details/language
- Facilitates testing development
- Highlights the value of the story
- Helps in building a common understanding of the problem
- Helps team in sizing the story
- Contains acceptance criteria to capture the expected behavior of the story and aids the testing team in developing test cases.
INVEST Model
- Independent: Independent (among other stories) Stories should not be dependent on other stories.
- Negotiable: Negotiable (a flexible statement of intent, not a contract) Stories should capture the essence of the requirement and should not represent a contract on how to solve it.
- Valuable: Valuable (providing a valuable vertical slice to the customer) Stories should clearly illustrate value to the customer.
- Estimable: Estimable (small and negotiable) Stories should provide just enough information so they can be estimated.
- Small: Small (enough to fit within an iteration) Stories should strive to be granular enough in scope that they may be completed in as little time as possible, preferably a few days or a week with the preference to the smaller duration.
- Testable: Testable (understood enough to know how to test it) Stories need to be understood well enough so that tests can be defined for them.
Common Anti-Patterns
- Team is consistently unable to complete User Stories within the Sprint (frequent carry forward of incomplete Stories)
- Team and the Product Owner are not confident to deliver according to the Sprint Plan
- Too many defects and re-work
Splitting User Stories
- Split using CRUD (Create, Read, Update, Delete) boundaries
- Deliver incremental business value
- Split by User Roles
- Split by Acceptance Criteria
- Split by workflow steps or events
