HKSM

The current, agreed set of user stories selected for the sprint after refinement during Sprint Planning and tasking. They capture clarifications, acceptance criteria, splits or merges, and any approved in-sprint adjustments, and serve as the authoritative scope for the sprint.

Key Points

• Represents the latest, agreed version of user stories committed for the sprint after refinement and task breakdown.
• Output of Commit User Stories and tasking activities; input to Create/Update Sprint Backlog, Estimate Tasks, and Demonstrate and Validate Sprint.
• Includes clarified acceptance criteria, links to tasks and tests, and status against the Definition of Done.
• Story points normally remain unchanged mid-sprint; approved scope adjustments require Product Owner agreement.
• Drives daily coordination, Sprint Burndown tracking, and Sprint Review outcomes.
• Provides traceability from user story to tasks, test cases, and acceptance decisions.

Purpose

Updated Committed User Stories provide a clear, controlled scope boundary for the sprint, reflecting the team’s latest understanding and the Product Owner’s expectations. They ensure everyone aligns on what will be built, how it will be validated, and how progress will be tracked.

This artifact supports transparency, enables predictable execution, and anchors acceptance during the Sprint Review.

Key Terms & Clauses

• Committed: Stories the team has selected for the sprint to meet the Sprint Goal.
• Updated: Refinements such as clarified acceptance criteria, story splits, and links to tasks and tests.
• Acceptance Criteria: Testable conditions that determine whether a story is accepted by the Product Owner.
• Definition of Done (DoD): Shared checklist that must be satisfied for a story to be considered complete.
• Approved Change: An in-sprint adjustment agreed by the Product Owner that does not jeopardize the Sprint Goal.
• Traceability: Mappings from story to tasks, test cases, and acceptance status for auditability and control.

How to Develop/Evaluate

• Confirm commitment during Sprint Planning; record story IDs, titles, story points, and initial acceptance criteria.
• During tasking, refine acceptance criteria, identify dependencies, and split overly large stories as needed.
• Link each story to its sprint tasks, owners, and test cases; mark DoD items that apply.
• Do not re-estimate story points mid-sprint; adjust tasks and scope only with Product Owner agreement.
• Evaluate quality using INVEST, clarity of acceptance criteria, DoD coverage, and testability.
• Version and timestamp updates so the team and stakeholders can see what changed and why.

How to Use

• As input to Create/Update Sprint Backlog and Estimate Tasks, ensuring tasks fully cover each story’s acceptance criteria.
• To guide Daily Standup conversations, removing impediments tied to specific stories and tasks.
• To feed Sprint Burndown by aggregating task remaining effort per story.
• To demonstrate completed functionality in Demonstrate and Validate Sprint, referencing acceptance criteria and DoD.
• To support Accept or Reject Deliverables by the Product Owner based on the updated criteria and evidence.
• To inform carryover decisions and Product Backlog updates at the end of the sprint if a story is not Done.

Example Snippet

• ID: US-104 — Title: Filter items by category — Points: 5.
• Acceptance Criteria: User can select one or more categories; results update within 1 second; selection persists on refresh.
• Linked Tasks: T-431 Implement API filter; T-432 UI dropdown; T-433 Unit tests; T-434 Integration tests.
• DoD Coverage: Code reviewed, unit test coverage > 80%, integrated, security checks passed, documented.
• Status: In progress — 10h remaining; Risks: dependency on endpoint availability.

Risks & Tips

• Risk: Mid-sprint scope creep without Product Owner agreement undermines the Sprint Goal; Tip: route changes through the Scrum Master and Product Owner.
• Risk: Re-estimating story points mid-sprint distorts velocity; Tip: adjust tasks and backlog scope, not story points.
• Risk: Vague acceptance criteria lead to rework; Tip: co-create clear, testable criteria before starting development.
• Risk: Lost traceability between stories and tasks; Tip: maintain consistent IDs and links in the sprint tooling.
• Risk: Over-splitting creates overhead; Tip: split only to achieve clarity and flow while preserving value slices.

PMP/SCRUM Example Question

During tasking, the team finds a committed user story lacks specific acceptance criteria and has a hidden dependency. What should the Scrum Master facilitate next?

1. Re-estimate the story points and update the team’s velocity immediately.
2. Update the Committed User Stories with refined acceptance criteria agreed with the Product Owner and link related tasks.
3. Escalate to the PMO to freeze scope until the dependency is removed.
4. Swap the story with a new one of equal points without involving the Product Owner.

Correct Answer: B — Update the Committed User Stories with refined acceptance criteria agreed with the Product Owner and link related tasks.

Explanation: The appropriate action is to clarify and update the committed story with the Product Owner and maintain traceability to tasks. Re-estimating points mid-sprint or changing scope without Product Owner involvement is not appropriate.