Why do we need User Stories?
Studies show a higher engagement level of our brain when we hear or read a story. Simply said, stories stick. A User Story is an opportunity for us to present a problem that we are trying to solve. Engaging with a story like this encourages a better understanding of the “big picture“, and also encourages innovative thinking and collaboration in an attempt to solve the presented problem.
Writing Perfect User Stories
User stories are never perfect but, can always be improved upon. Some best practices to writing User Stories are as follows:
- Communicate the PURPOSE from the USER’s perspective
- Capture the “who”, “what”, and “why” but, leave the “how” up to the development team
- Have enough detail in the story to start a conversation. This should create questions, answers, ideas, and ultimately, a well-crafted story that the whole team has been a part of creating
- DON’T USE “AND”
- User Stories should focus on the smallest achievable item that can provide value.
- Work items typically become larger than expected. Keep it small and achievable.
- Work should be completed within an iteration.
- Use Bill Wake’s INVEST model
| Independent | We want to be able to develop in any sequence |
| Negotiable | Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement and allow for innovation |
| Valuable | Users or customers get some value from the story |
| Estimable | The team must be able to use them for planning |
| Small | Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within an iteration. |
| Testable | Document acceptance criteria, or the definition of done for the story. Acceptance criteria should be easily translated into test cases. |
Acceptance Criteria
Writing good Acceptance Criteria is an art form. You can very easily go too detailed, specifically with telling “how” instead of keeping true to the “what” of the story. Conversely, you can be entirely too broad as well.
Common tips for solid Acceptance Criteria:
- Make sure Acceptance Criteria is written before implementation
- Should contain clear, concise explanations of the expected output of the User Story
- Writing the Acceptance Criteria using a Pass/Fail approach helps to easily translate each one into test cases
- Should be written from the Users’ perspective. This helps avoid falling into the “how” trap
- The Product Owner should include just enough Acceptance Criteria for the team to understand the desired result in backlog refinement. Further Acceptance Criteria is expected to be written as the team discusses.
- The Product Owner is responsible for signing off on Acceptance Criteria, and should therefore understand each one and how it relates to the desired result
Framework
Title:
This should be a clear summary of the goal. Anyone looking at the story in a list should be able to grasp the basic goal from the title.
Description:
As a <type of user>, I want <some goal>, so that <some reason>.
Acceptance Criteria:
Every User Story should include at least one Acceptance criteria.
Example:
Title:
Self-service capability for New Vendor-Provided Step Codes
Description:
As an Operations Service Manager, I want to be able to self-service when new step codes are introduced by the vendor, so that I can take action independently of the development cycle.
Acceptance Criteria:
- Provide a solution for users to manage step codes
- Step codes should be able to be updated by user without IT involvement
Common Mistakes
Too much detail
If the User Story reads like a technical requirements document, the team is likely to see this and assum that all of the details are there, thus resulting in skipping the necessary discussion.
Skipping the conversation
Stories should have a level of vagueness prior to backlog grooming. If you skip refinement discussions with the entire team, there is a risk that you will move in the wrong direction, miss edge cases, or overlook the users’ needs.
