How to Write Good User Stories in Scrum

Approximately 70% of technology projects fail. For decades, it has been widely believed that projects fail because they do not follow best practices or because the team lacks all the right skills. However, the adoption of best practices, skills, and competencies has improved over the decades—so why do projects still fail?

Considering that 70% of software projects fail due to poor requirements. The estimated rework associated with these failures exceeds $45 billion annually.

Do 70% of Your Projects Fail? (Part 1) — Pie

The question is—why does this happen? The answer is twofold. First, business requirements often lose focus on the customer; second, requirements lack an overall reference framework that enables requirements analysts to drive and trace requirements from customer needs and strategy all the way to the solution being implemented.

To write good requirements or user stories, follow these steps:

  1. Define as many personas as possible to represent the users of the system. This will help you stay focused on the customer and drive and trace requirements based on customer needs. Introduced by Alan Cooper, personas define archetypal users of the system—examples of the kind of people who interact with it. Users do not have to be or represent individuals. A user can also represent an organization.
  2. Ensure your user stories follow the “3Cs”:

Minimum Viable Product Development - Define User Stories - PART 1 - Blog Systango

  • Card — Should be written on an index card or sticky note
  • Conversation — Obtain detailed information from the Product Owner
  • Confirmation — Ensure it is implemented correctly. It must meet the user acceptance criteria.
  1. Split user stories so they are appropriately sized to fit within a Sprint. Some ways to split stories include:
  • Split by workflow steps
  • Split by input/output channels
  • Split by user options
  • Split by persona/role
  • Split by data range
  1. Make every user story follow the INVEST mnemonic:

User stories: a comprehensive guide - Justinmind

The agile INVEST mnemonic, created by Bill Wake, serves as a guideline to ensure high-quality Product Backlog Items (PBIs), typically written in user story format.

  • Independent: Stories should be as independent as possible.
  • Negotiable: A story is not a contract. A story is an invitation to a conversation. The story captures the essence of what is desired.
  • Valuable: If a story has no obvious value, it should not be done.
  • Estimable: A story must be estimable or sized so it can be properly prioritized.
  • Small: For a two-week iteration, user stories should average 3–4 days of work—total! This includes all work required to bring the story to a “Done” state. The smaller the user story, the higher the estimation accuracy!
  • Testable: Every story needs to be testable to be considered “Done.”