HKSM

Committed User Stories are the refined, estimated Product Backlog items the Scrum Team agrees to deliver in the next Sprint during Approve, Estimate, and Commit User Stories. They set the Sprint scope and become the basis for creating tasks and the Sprint Backlog.

Key Points

• Output of Approve, Estimate, and Commit User Stories and input to Create Tasks and Create Sprint Backlog.
• Must be refined, estimated, and aligned with the Sprint Goal and team capacity.
• Each story should have clear acceptance criteria and meet the team’s Definition of Ready.
• Changes during the Sprint require negotiation with the Product Owner and team and must not endanger the Sprint Goal.
• Progress is tracked against these stories using Sprint Burndown and daily synchronization.
• Unfinished stories move back to the Product Backlog for re-prioritization and future planning.

Purpose

Provide a clear, achievable scope for the Sprint so the team can plan tasks, collaborate effectively, and build a usable Increment. They link strategic priorities from the Product Backlog to day-to-day delivery work.

They also create a transparent contract of intent among the Product Owner, Scrum Master, and team regarding what value will be delivered within the timebox.

Key Terms & Clauses

• Definition of Ready (DoR) - Entry quality bar for selecting a story into a Sprint.
• Definition of Done (DoD) - Exit quality bar for completing a story and the Increment.
• Acceptance Criteria - Testable conditions that confirm a story is acceptable.
• Capacity and Velocity - Team’s available effort and empirical pace guiding selection.
• Sprint Goal - The unifying objective that shapes which stories are chosen.
• Dependencies - Technical or organizational links that may affect commitment.
• Spillover - Unfinished work returned to the Product Backlog after the Sprint.

How to Develop/Evaluate

Developing the set:

• Start with a refined, prioritized Product Backlog presented by the Product Owner.
• Discuss each candidate story to confirm understanding, assumptions, and risks.
• Estimate collaboratively using a consistent method, then check capacity and velocity.
• Select stories that align to the Sprint Goal and split large items to fit the timebox.
• Confirm acceptance criteria, dependencies, and DoR readiness before committing.
• Record the committed set and link to the emerging Sprint Backlog.

Evaluating quality:

• Apply INVEST heuristics and ensure acceptance criteria are testable.
• Verify dependency clarity and risk visibility for each story.
• Confirm DoD applicability and any nonfunctional requirements.
• Check that total commitment matches realistic capacity.

How to Use

Use the committed set as input to Create Tasks and Estimate Tasks, forming the Sprint Backlog. During Daily Standups, track progress, update remaining work, and surface impediments against the committed scope.

At Demonstrate and Validate Sprint, show completed stories to the Product Owner for acceptance. Any unfinished stories return to the Product Backlog, and insights feed into Retrospect Sprint.

If a change is proposed mid-sprint, the team and Product Owner may negotiate scope only if it protects the Sprint Goal and capacity, otherwise defer it to a future Sprint.

Example Snippet

• US-134 - As a user, I can reset my password so I can regain access. Estimate: 5 points. Acceptance: reset link expires, audit entry recorded, email verified.
• US-128 - As a user, I can update my profile so my data stays current. Estimate: 3 points. Acceptance: validation rules applied, changes persisted, confirmation shown.
• Sprint Goal - Improve account access and data accuracy to reduce support tickets.
• Team Capacity - 28 points this Sprint; total committed: 24 points with small buffer.

Risks & Tips

• Risk - Overcommitting leads to spillover and low predictability. Tip: plan by capacity and past velocity, keep a modest buffer.
• Risk - Vague acceptance criteria cause rework. Tip: ensure testable criteria before commitment.
• Risk - Hidden dependencies block delivery. Tip: surface and resolve or re-scope stories before committing.
• Risk - Mid-sprint scope churn disrupts focus. Tip: negotiate changes only if they do not compromise the Sprint Goal.
• Risk - Large, horizontal stories slow flow. Tip: slice vertically to deliver end-to-end value.

PMP/SCRUM Example Question

After Approve, Estimate, and Commit User Stories, which artifact becomes a key input to the Create Tasks process?

1. Approved Change Requests
2. Committed User Stories
3. Sprint Burndown Chart
4. Potentially Shippable Product Increment

Correct Answer: B - Committed User Stories

Explanation: Create Tasks breaks down the committed stories into actionable work items. The other options are either outputs produced later or are not direct inputs to task creation.