HKSM

A timeboxed working session at the start of each Sprint where the Product Owner, Scrum Master, and Scrum Team agree on a Sprint Goal and select the highest-priority user stories they believe they can complete. The team decomposes selected items into tasks, clarifies acceptance criteria, and forms the Sprint Backlog.

Key Points

• Timeboxed to up to 8 hours for a 1-month Sprint, proportionally less for shorter Sprints.
• Includes Product Owner, Scrum Master, and the development team collaborating as one Scrum Team.
• Produces a Sprint Goal and a Sprint Backlog with selected user stories and tasks.
• Relies on team capacity, historical velocity, and updated backlog priorities.
• Clarifies acceptance criteria and Definition of Done to protect quality.
• Creates initial risk visibility and a plan for testing, integration, and delivery.

Purpose of Analysis

The session analyzes the highest-value backlog items against real capacity, dependencies, and risks to decide what is feasible within the Sprint. It aligns the team on a clear Sprint Goal and a coherent set of user stories that deliver a meaningful increment.

It also reviews quality standards and acceptance criteria to minimize ambiguity, supporting predictable flow and transparent progress tracking during the Sprint.

Method Steps

1. Set the context: confirm Sprint length, team availability, Definition of Done, and any working agreements.
2. Product Owner presents the prioritized user stories and desired outcomes, clarifying business value and acceptance criteria.
3. Discuss and refine: the team asks questions, identifies dependencies, and validates or updates estimates.
4. Formulate the Sprint Goal collaboratively to guide selection and focus.
5. Select user stories that align with the Sprint Goal and fit capacity using velocity and availability data.
6. Decompose selected stories into tasks, size them (often in hours or ideal effort), and check for test and integration needs.
7. Address risks and impediments, define mitigations, and confirm quality practices aligned to the Definition of Done.
8. Finalize the Sprint Backlog and initial plan for the first days, establishing how progress will be tracked (e.g., burndown).

Inputs Needed

• Prioritized Product Backlog with refined user stories and acceptance criteria.
• Team capacity for the Sprint, including holidays and other commitments.
• Historical velocity and any recent changes in team composition.
• Definition of Done and quality standards or compliance constraints.
• Known dependencies, architecture guidelines, and integration constraints.
• Feedback and insights from the last Sprint Review and Retrospective.
• Open risks, impediments, and stakeholder expectations.

Outputs Produced

• Sprint Goal statement that expresses the outcome the increment should achieve.
• Sprint Backlog with selected user stories and a task-level plan.
• Updated estimates and a capacity-aware forecast for the Sprint.
• Clarified acceptance criteria and test approach for selected items.
• Identified risks and impediments with owners and mitigation steps.
• Confirmed or adjusted Definition of Done and working agreements if needed.
• Initial baseline for progress tracking (e.g., Sprint Burndown).

Interpretation Tips

• Let the Sprint Goal drive selection; avoid a random set of unrelated stories.
• Use recent velocity and current availability, not wishful thinking, to forecast work.
• Prefer thin vertical slices that produce a testable increment each Sprint.
• Stop refining when the team has enough shared understanding to start; leave details for just-in-time discovery.
• Keep it collaborative: the Product Owner prioritizes value, the team forecasts scope, and the Scrum Master facilitates.
• Timebox firmly; decisions that exceed the timebox signal the backlog needs more refinement before planning.

Example

A team with a two-week Sprint and a typical velocity of 30 points reviews availability and confirms capacity is closer to 26 points due to a holiday. The Product Owner presents five high-priority stories totaling 32 points tied to a Sprint Goal of enabling self-service onboarding.

The team selects four stories totaling 26 points, breaks them into tasks, clarifies acceptance criteria, notes a dependency on an API mock, and records a risk about test data readiness with a mitigation plan. The Sprint Backlog and Sprint Goal are agreed, and the team is ready to start.

Pitfalls

• Overcommitting by ignoring holidays, support work, or historical velocity.
• Weak or missing Sprint Goal, leading to scattered effort and low coherence.
• Poorly refined stories without acceptance criteria, causing churn mid-Sprint.
• Decomposing only into technical tasks without ensuring a valuable increment.
• Skipping risk and dependency checks, causing delays later in the Sprint.
• Allowing one person to dominate decisions instead of collaborative planning.

PMP/SCRUM Example Question

During Sprint Planning, the Product Owner, Scrum Master, and team discuss the highest-priority items and align on a Sprint Goal. What is the best outcome of this meeting?

1. A detailed Gantt chart for all Sprints in the release.
2. An approved change request to expand the project scope.
3. A Sprint Goal and a Sprint Backlog with selected user stories and tasks.
4. Functional manager assignments for each team member.

Correct Answer: C — A Sprint Goal and a Sprint Backlog with selected user stories and tasks.

Explanation: Sprint Planning produces a clear Sprint Goal and a feasible plan (Sprint Backlog). Gantt charts, formal change requests, and functional assignments are not outputs of this Scrum event.