HKSM

User stories not accepted by the Product Owner at the end of a sprint because they fail one or more acceptance criteria or the Definition of Done. They are documented with reasons and returned to the product backlog for clarification, splitting, re-estimation, and future prioritization.

Key Points

• Created during Demonstrate and Validate Sprint when the Product Owner does not accept a story.
• Do not count toward the sprint's velocity or toward released value.
• Flow back into the product backlog for refinement, re-estimation, and reprioritization.
• Reasons for rejection are recorded and linked to acceptance criteria and tests.
• Provide inputs to Retrospect Sprint for process improvement and quality learning.
• May be split into smaller stories or turned into defects or change requests if appropriate.

Purpose

Rejected user stories create a clear, auditable record of work that did not meet expectations. This drives transparency, prevents partial credit, and protects product quality.

They ensure that undone work is properly routed back to the product backlog so the Product Owner can decide next steps based on value, risk, and effort.

Key Terms & Clauses

• Acceptance Criteria: Story-specific conditions that must be met for acceptance.
• Definition of Done (DoD): Team agreement on quality and completion standards applied to every story.
• All-or-Nothing Acceptance: A story is either accepted in full or rejected; no partial acceptance.
• Rework vs. Defect: Rework addresses unmet acceptance criteria; defects are verified faults discovered during or after validation.
• Spillover: Work not completed within the sprint and returned to the backlog.
• Traceability: Link rejection reasons to tests, criteria, and any related bugs or change requests.

How to Develop/Evaluate

The evaluation happens in Demonstrate and Validate Sprint. The Development Team shows working increments and evidence of tests, and the Product Owner checks each story against acceptance criteria and DoD.

1. Run acceptance tests and verify DoD items (code, tests, integration, documentation, etc.).
2. If any criterion is unmet, mark the story as rejected and note specific gaps.
3. Decide whether to split the story, refine acceptance criteria, or file linked defects.
4. Update the product backlog item with rejection notes, proposed changes, and attachments (screens, logs, test results).
5. Re-estimate collaboratively if scope or approach will change.
6. Record decisions and next steps in Sprint Review notes for transparency.

How to Use

Use rejected stories as inputs to backlog refinement and prioritization. The Product Owner decides if the story remains as-is, is split, or is superseded by new items.

• Move the item back to the product backlog; remove any "Done" status and zero it out for velocity.
• Refine acceptance criteria for clarity and testability; align with stakeholders.
• Re-estimate story points or effort when scope or complexity changes.
• Link related defects, technical tasks, or change requests for full context.
• Schedule the refined item in a future sprint only when it meets Definition of Ready.
• Discuss patterns of rejection in Retrospect Sprint to improve slicing, readiness, and testing practices.

Example Snippet

Backlog entry after rejection:

• Story: As a user, I can reset my password so I can regain access.
• Reason for Rejection: Email link expires after 2 hours instead of 15 minutes; audit log not recorded.
• Actions: Split into two stories (expiry logic, audit logging); add acceptance tests; re-estimate to 5 and 3 points; link defect ID-2471.
• Next Step: Reprioritize in Prioritize Product Backlog; target a later sprint when ready.

Risks & Tips

• Risk: Ambiguous acceptance criteria cause late surprises. Tip: Use INVEST and write clear, measurable criteria.
• Risk: Hidden work to meet DoD emerges at the end. Tip: Make DoD explicit and visible; use checklists in development.
• Risk: Velocity distortion from partial completion. Tip: Do not count points for rejected stories; track separately as spillover.
• Risk: Rejection seen as blame. Tip: Facilitate objective reviews; focus on learning and improvement.
• Risk: Re-adding large stories increases cycle time. Tip: Slice thinner stories and validate earlier with interim demos.
• Risk: PO unavailable at review. Tip: Schedule interim acceptance checkpoints with the Product Owner mid-sprint.

PMP/SCRUM Example Question

During Demonstrate and Validate Sprint, the Product Owner rejects two user stories because one acceptance criterion on each is unmet. What should the Scrum Team do next?

1. Extend the sprint by a day to finish the two stories and keep velocity stable.
2. Count partial story points for work done and move only the missing criteria to the next sprint.
3. Return the stories to the product backlog with rejection notes, refine or split them, and re-estimate before future prioritization.
4. Ask the Scrum Master to override the decision so the release plan is not impacted.

Correct Answer: C — Return the stories to the product backlog with rejection notes, refine or split them, and re-estimate before future prioritization.

Explanation: Rejected user stories do not count toward velocity and are routed back to the product backlog for refinement, re-estimation, and reprioritization. The sprint is never extended, and acceptance decisions rest with the Product Owner.