Accepted User Stories
User stories that fully meet their acceptance criteria and the Definition of Done, and are formally accepted by the Product Owner, usually in Sprint Review. They represent tested, potentially shippable functionality and count toward velocity and release progress.
Key Points
- Formal Product Owner acceptance of completed user stories that meet the Definition of Done and stated acceptance criteria.
- Created as an output of Demonstrate and Validate Sprint and used as input to Retrospect Sprint and Ship Deliverables.
- Drive velocity, burn charts, and release forecasting once marked accepted.
- Evidence typically includes passing tests, updated documentation, and a recorded acceptance decision.
- Stories not accepted are returned to the Product Backlog for refinement, re-prioritization, and future sprints.
- May result in splitting a story if only a subset meets the acceptance criteria.
Purpose
Accepted user stories confirm what value is genuinely delivered and ready for potential release. They provide a reliable basis for governance, stakeholder reporting, compliance evidence, and future planning.
By distinguishing accepted from merely completed work, the team gains transparent metrics for velocity, quality, and predictability.
Key Terms & Clauses
- Acceptance Criteria: Clear, testable conditions that must be satisfied for the story to be accepted.
- Definition of Done (DoD): Team-wide quality checklist that includes coding standards, testing, documentation, and integration.
- Product Owner Acceptance: The authoritative decision to accept or reject based on criteria and DoD.
- Non-functional Requirements: Performance, security, usability, and other quality attributes verified before acceptance.
- Partial Acceptance and Splitting: If part of a story meets criteria, split it so the accepted portion can be closed and the remainder returned to the Product Backlog.
- Acceptance Record: Date, version/build, evidence of tests, and the Product Owner’s sign-off captured in the tracking tool.
How to Develop/Evaluate
- Refine user stories and define acceptance criteria before sprint commitment; confirm shared understanding with the team.
- Design tests (functional, non-functional) aligned to the acceptance criteria and the DoD.
- During the sprint, build and validate the story; ensure all tests pass and quality checks are complete.
- Demonstrate the story to the Product Owner in Sprint Review (or earlier by agreement) for acceptance.
- Record the acceptance decision, attach evidence, and update status in the tool; split and re-queue any unaccepted scope.
How to Use
- Update velocity, sprint and release burn charts using only accepted user stories.
- Feed accepted stories into Ship Deliverables for deployment or release planning, as appropriate.
- Use as input to Retrospect Sprint to analyze what helped or hindered acceptance.
- Inform Refine Prioritized Product Backlog by returning any rejected or split work for re-estimation and prioritization.
- Provide traceable evidence for audits, compliance, and stakeholder reporting.
Example Snippet
User Story: As a customer, I want to reset my password so that I can access my account if I forget it.
Acceptance Criteria:
- A reset link is emailed to the registered address within 1 minute.
- The link expires after 30 minutes and cannot be reused.
- Password policy enforced on reset (length, complexity, history).
- All events logged for security auditing.
Acceptance Record: Tests passed on build 1.5.3; security and audit checks complete; Product Owner accepted on 2025-04-10.
Risks & Tips
- Risk: Vague acceptance criteria lead to disputes. Tip: Make criteria specific and testable during refinement.
- Risk: Product Owner availability delays acceptance. Tip: Schedule demos early and confirm availability before Sprint Review.
- Risk: Non-functional needs overlooked. Tip: Embed NFRs in the DoD and acceptance criteria.
- Risk: Changing acceptance criteria mid-sprint. Tip: Manage changes via backlog updates rather than shifting the goal for in-flight stories.
- Risk: Counting completed but unaccepted work in velocity. Tip: Only accepted stories contribute to velocity and release forecasts.
PMP/SCRUM Example Question
During Sprint Review, the Product Owner accepts three user stories and rejects two due to unmet performance criteria. What should the Scrum Master guide the team to do next?
- Count all five stories toward velocity because development is complete.
- Move the rejected stories to Done and close the sprint to maintain schedule.
- Record acceptance for the three stories, update velocity and release plans, and return the two rejected stories to the Product Backlog for refinement and re-prioritization.
- Re-estimate the accepted stories to improve future forecasts.
Correct Answer: C — Record acceptance for the three stories, update velocity and release plans, and return the two rejected stories to the Product Backlog for refinement and re-prioritization.
Explanation: Only accepted user stories count toward velocity and release progress; unaccepted work is returned to the Product Backlog for future consideration.
