← Agile and Scrum: Flexible Project Management
Lesson
Lesson 5.2 — User stories, INVEST, and acceptance criteria
Write a user story in the standard format that satisfies INVEST and has clear acceptance criteria.
User Stories and INVEST
User Stories and INVEST
A user story is a lightweight way to express a product requirement from the perspective of the person who will benefit from it. The standard format is: 'As a <role>, I want <action>, so that <value>.' This three-part structure keeps the team focused on who needs something, what they need, and why it matters.
Example: 'As a registered customer, I want to reset my password via email, so that I can regain access to my account without contacting support.' The acceptance criteria for this story might be: (1) A 'Forgot password' link is visible on the login page. (2) The user receives a reset email within two minutes. (3) The reset link expires after 24 hours. (4) After a successful reset the user is redirected to the login page. These criteria make the story Testable — the team knows exactly when the story is finished.
Bill Wake's INVEST acronym describes six qualities of a good user story. Independent: the story can be developed and delivered separately from others. Negotiable: the details can be discussed and adjusted — a story is not a rigid contract. Valuable: it delivers real benefit to the end user or business. Estimable: the team can estimate its size well enough to plan. Small: it fits comfortably within one Sprint. Testable: there are clear criteria to verify whether the story is done.
Acceptance criteria are the primary tool for satisfying the Testable attribute. Without them, a story cannot be verified and should not be considered done. Writing good acceptance criteria before development starts also reduces misunderstandings between the Product Owner and the Developers.
Lesson notes
User Stories and INVEST
A user story is a lightweight way to express a product requirement from the perspective of the person who will benefit from it. The standard format is: 'As a <role>, I want <action>, so that <value>.' This three-part structure keeps the team focused on who needs something, what they need, and why it matters.
Example: 'As a registered customer, I want to reset my password via email, so that I can regain access to my account without contacting support.' The acceptance criteria for this story might be: (1) A 'Forgot password' link is visible on the login page. (2) The user receives a reset email within two minutes. (3) The reset link expires after 24 hours. (4) After a successful reset the user is redirected to the login page. These criteria make the story Testable — the team knows exactly when the story is finished.
Bill Wake's INVEST acronym describes six qualities of a good user story. Independent: the story can be developed and delivered separately from others. Negotiable: the details can be discussed and adjusted — a story is not a rigid contract. Valuable: it delivers real benefit to the end user or business. Estimable: the team can estimate its size well enough to plan. Small: it fits comfortably within one Sprint. Testable: there are clear criteria to verify whether the story is done.
Acceptance criteria are the primary tool for satisfying the Testable attribute. Without them, a story cannot be verified and should not be considered done. Writing good acceptance criteria before development starts also reduces misunderstandings between the Product Owner and the Developers.