HKSM

A decision technique used by the Product Owner to accept or reject completed user stories based on their acceptance criteria and the Definition of Done during demonstration and validation. It confirms which deliverables provide expected value and which require rework or reprioritization in the product backlog.

Key Points

• Performed by the Product Owner, typically in the Sprint Review or when a story is demonstrated and validated.
• Decisions are based on acceptance criteria, Definition of Done, test results, and stakeholder feedback.
• The decision is binary per story; partial completion leads to splitting the story and replanning.
• Accepted stories become accepted deliverables and may be released according to the release plan.
• Rejected stories return to the product backlog with updated details, priority, and rework notes.
• The Scrum Master facilitates the session to ensure transparency, timeboxing, and adherence to process.

Purpose of Analysis

This technique verifies that delivered user stories meet agreed business needs and quality standards. It creates a clear, transparent outcome for each story so the team and stakeholders know what is ready for release and what needs rework.

It also protects scope and quality by preventing acceptance based on opinion or schedule pressure, keeping decisions grounded in explicit criteria.

Method Steps

1. Confirm readiness: ensure the story has clear acceptance criteria and aligns with the Definition of Done.
2. Demonstrate functionality: the Developers show the working increment, including non-functional aspects if relevant.
3. Validate: compare observed behavior against acceptance criteria, DoD, and applicable standards or compliance needs.
4. Decide: the Product Owner accepts or rejects the story. If only part is done, split into a new story for remaining work.
5. Record: capture acceptance notes, defects, and any follow-up actions or learning.
6. Update the product backlog: move accepted items forward and re-add rejected items with revised priority and estimates.

Inputs Needed

• User story with clear acceptance criteria and any supporting examples or test cases.
• Definition of Done for the team or product.
• Demonstration environment, build, and test evidence including automated test results.
• Stakeholder feedback relevant to the story’s value and usability.
• Standards, regulatory, or performance requirements applicable to the increment.
• Release goals or product vision to provide context for value and timing.

Outputs Produced

• Accepted Deliverables: user stories confirmed as done and potentially shippable.
• Rejected Deliverables: user stories not meeting criteria, returned to the product backlog for rework.
• Updated Product Backlog with rework items, defects, splits, and adjusted priorities.
• Acceptance notes and feedback for continuous improvement and future refinement.
• Updated progress metrics such as burn-up or release forecasts, if used.

Interpretation Tips

• Base acceptance on outcomes and criteria, not on effort spent or demo polish.
• Treat non-functional requirements as first-class; failure here warrants rejection or split.
• Acceptance does not automatically mean immediate release; follow the release plan.
• Do not negotiate criteria during the decision; update criteria only in backlog refinement for future work.
• Timebox the decision and keep it transparent to maintain cadence and trust.

Example

The team demonstrates a user story: As a user, I can reset my password via email. Acceptance criteria include rate limiting, token expiry, and audit logging. The demo shows correct email flow and token expiry, but audit logging is missing.

The Product Owner rejects the story, adds a split story for audit logging, and reprioritizes it for the next sprint. Notes capture test outcomes and the logging gap to guide rework.

Pitfalls

• Vague or missing acceptance criteria leading to subjective decisions.
• Accepting partial work without splitting, causing hidden debt and confusion.
• Extending the sprint to finish a failed criterion, breaking timeboxing.
• Conflating acceptance with contract sign-off or full UAT, delaying feedback loops.
• Ignoring non-functional or compliance criteria during the demo.
• Failing to update the product backlog and estimates after rejection or splitting.

PMP/SCRUM Example Question

During the Sprint Review, one acceptance criterion for a demonstrated user story fails. What should the Scrum Master encourage the Product Owner to do next?

1. Accept the story and log a defect to fix the failed criterion after release.
2. Reject the story and return it to the product backlog for rework and reprioritization.
3. Extend the sprint by two days to complete the missing work.
4. Mark the story done because most acceptance criteria passed.

Correct Answer: B — Reject the story and return it to the product backlog for rework and reprioritization.

Explanation: Acceptance requires meeting all acceptance criteria and the Definition of Done. A failing criterion means the story is not done, so it is rejected and planned as backlog work rather than extending the sprint.