9.3 Commit User Stories
| 9.3 Commit User Stories | ||
|---|---|---|
| Inputs | Tools | Outputs |
Bold ITTOs are mandatory.
Commit User Stories is the Sprint Planning step where the Scrum Team agrees on a realistic set of ready, prioritized user stories they will deliver in the Sprint based on capacity and risk.
Purpose & When to Use
The purpose of Commit User Stories is to lock in a clear, achievable Sprint scope that aligns with the Sprint Goal and team capacity. It creates transparency for stakeholders and focus for the team, turning refined backlog items into a concrete Sprint Backlog.
Use this at the end of Sprint Planning, after refinement, estimation, and capacity checks are done. It happens once per Sprint and results in a baseline of user stories the team plans to deliver.
Mini Flow (How It’s Done)
- Confirm inputs: Sprint Goal, prioritized and refined Product Backlog, Definition of Ready (DoR), team capacity/velocity, known risks and dependencies.
- Pull the highest-value, ready user stories and restate acceptance criteria to ensure shared understanding.
- Break stories into tasks as needed and validate effort estimates; consider capacity, skills, holidays, dependencies, and risk buffers.
- Negotiate scope with the Product Owner until the set of stories fits within realistic capacity and still meets the Sprint Goal.
- Record the committed stories, acceptance criteria, and initial tasks in the Sprint Backlog; note dependencies and risks.
- Gain clear team agreement; the Product Owner confirms priority and that acceptance criteria reflect value; the Scrum Master ensures the process and DoR are respected.
- Communicate the committed Sprint scope and goal to stakeholders.
Quality & Acceptance Checklist
- Every committed user story meets the Definition of Ready (clear, testable, sized, value-focused, dependencies identified).
- Acceptance criteria are explicit, testable, and understood by the team and Product Owner.
- Selected workload fits capacity and historical velocity; a reasonable buffer exists for uncertainty.
- Non-functional requirements (performance, security, compliance) are captured where relevant.
- Dependencies, assumptions, and risks are logged with owners and mitigation notes.
- The Sprint Goal is achievable with the selected stories and is visible to everyone.
- Definition of Done (DoD) is reconfirmed for all stories; test strategy and environments are available.
- Team consensus reached; no individual assignments at commitment time are required for approval.
Common Mistakes & Exam Traps
- Overcommitting by ignoring capacity/velocity or not accounting for risks and dependencies.
- Committing to stories that are not ready (vague, missing acceptance criteria, unknown dependencies).
- Letting the Product Owner assign work or dictate the Sprint scope without team agreement; selection is a team decision.
- Confusing tasks with user stories; the commitment is to user stories that deliver value, not just to a list of tasks.
- Failing to protect Sprint scope after commitment; new ideas go to the Product Backlog unless the team and Product Owner explicitly renegotiate.
- Exam trap: Some guides say “forecast” instead of “commit.” For SBOK-style questions, the team commits to a realistic set of stories; for Scrum Guide–style questions, the team forecasts. Read the question’s context.
PMP/SCRUM Example Question
During Sprint Planning, the team has a capacity of 30 points and has refined the top backlog items. What best represents the Commit User Stories step?
- Ask the Scrum Master to choose stories that fit 30 points and assign them to team members.
- Have the Product Owner assign the top 30 points of work to the most skilled developers.
- The team selects the highest-priority, ready stories up to about 30 points, confirms acceptance criteria, and records them in the Sprint Backlog.
- Commit to 40 points to push performance, then drop lower-priority testing if time runs out.
Correct answer: C. The team, in collaboration with the Product Owner, selects ready, high-priority stories within capacity, confirms acceptance criteria, and commits them into the Sprint Backlog; neither the Scrum Master nor the Product Owner assigns the work.
HKSM