HKSM

A time-boxed session at the end of a sprint where the team and stakeholders inspect the working product and discuss what to do next. It provides real data to assess progress against goals and refine the schedule and backlog.

Key Points

• Held at the end of each sprint; typically 1–2 hours per week of sprint length.
• Centers on the actual product increment and outcomes, not slide decks.
• Requires active stakeholder participation for meaningful feedback.
• Uses empirical data (e.g., velocity, burn-up) to check schedule health and forecasts.
• Results in updates to the product backlog, release plan, and next-sprint focus.
• Decisions, acceptances, and follow-ups are captured and shared.
• Different from retrospective (process improvement) and daily stand-up (coordination).

Purpose of Analysis

Provide transparency into progress and pace, validate what was delivered, and compare results to planned goals and dates. Use the insights to adjust scope, sequence, and forecasts so the delivery plan stays realistic and value-focused.

It aligns the team and stakeholders on what to build next and how schedule expectations should change based on actual throughput and new feedback.

Method Steps

• Prepare: Set a clear agenda, confirm attendees, and ensure a working demo environment.
• Show the increment: Demonstrate completed items against acceptance criteria and Definition of Done.
• Collect feedback: Invite stakeholders to try the product and provide targeted comments.
• Review data: Present velocity, burn-up, and any relevant cycle time or flow indicators.
• Discuss impacts: Explore how feedback and observed pace affect scope, dependencies, and dates.
• Decide next steps: Reorder the backlog, identify new items, and note changes to release forecasts.
• Close and communicate: Confirm acceptances, capture actions, and publish decisions and updates.

Inputs Needed

• Sprint goal and completed backlog items meeting the Definition of Done.
• Working product increment ready for demonstration.
• Product backlog, including candidate items for upcoming sprints.
• Empirical data such as velocity, burn-up chart, and cumulative flow.
• Current release plan or roadmap with target dates and milestones.
• Known risks, issues, impediments, and capacity changes.
• Stakeholder availability and any acceptance criteria or success measures.

Outputs Produced

• Accepted or rejected backlog items with documented acceptance results.
• Updated product backlog ordering and newly added or refined items.
• Revised schedule forecasts, including updated release plan or target dates.
• Logged decisions, action items, and owners for follow-up.
• Risk and issue log updates based on discovered impacts or dependencies.
• Change requests, if formal baseline or external commitments must be adjusted.

Interpretation Tips

• Look for trends over several sprints; treat velocity as a range, not a single number.
• Use burn-up to distinguish added scope from delivery pace when dates shift.
• Normalize for capacity changes (holidays, new team members) before drawing conclusions.
• Focus on value delivered and working features, not hours spent or percent complete.
• Escalate persistent variance by revisiting WIP limits, dependencies, or Definition of Done.
• Translate feedback into clear backlog changes so schedule impacts are explicit and traceable.

Example

A team running two-week sprints shows a working reporting module. Stakeholders request drill-down filters, which adds scope. Velocity dipped from 28 to 24 due to vacations. The product owner reorders the backlog to include the filters, and the team updates the burn-up and release forecast, moving the target date by one sprint. Decisions and actions are shared the same day.

Pitfalls

• Treating the session as a one-way demo without real stakeholder interaction.
• Skipping discussion of schedule metrics and forecast impacts.
• Overreacting to a single sprint’s variance instead of watching trends.
• Committing to new scope on the spot without estimating or assessing capacity.
• Allowing unfinished work to be presented as done, eroding data quality.
• Letting the meeting drift into a status or problem-solving session with no clear outcomes.

PMP Example Question

During a sprint review, stakeholders ask for a high-priority feature that would likely extend the release by two weeks. What should the project leader do first to control the schedule?

1. Decline the request to protect the original release date.
2. Ask the team to work overtime to add the feature without moving the date.
3. Capture the request, assess impact with the team, update the backlog and forecast, then seek stakeholder agreement.
4. Add the feature to the current sprint to keep stakeholders satisfied.

Correct Answer: C — Capture the request, assess impact with the team, update the backlog and forecast, then seek stakeholder agreement.

Explanation: Sprint reviews enable transparent scope and schedule decisions using real data. Analyze impacts and adjust forecasts before committing. Options A, B, and D bypass impact assessment and risk unrealistic plans.