HKSM

A concise record produced from the Sprint Retrospective capturing what went well, what needs improvement, and specific, time-bound action items with owners. It is an output of Conduct Retrospect Sprint and becomes an input to upcoming Sprints, release-level retrospectives, and organizational learning.

Key Points

• Output of Conduct Retrospect Sprint; input to future Sprint Planning and the project or release-level retrospective.
• Captures insights, root causes, and agreed actionable improvements with owners and due dates.
• Owned by the Scrum Team and facilitated by the Scrum Master for transparency and follow-through.
• Links to the Impediment Log, Definition of Done updates, team working agreements, and the Scrum Guidance Body.
• Reviewed at the start of the next retrospective and monitored during the Sprint for progress.
• Kept lightweight, prioritized, and limited in WIP to ensure actions are actually implemented.

Purpose

The log promotes continuous improvement by turning learning into specific actions that the team can execute and verify. It creates accountability for process, quality, and collaboration changes and preserves lessons for future Sprints and releases.

By providing traceability from observation to outcome, it helps the team and stakeholders see measurable improvement over time.

Key Terms & Clauses

• Actionable improvement: A concrete change the team can implement within 1-2 Sprints.
• Owner: A named team member responsible for driving the action to completion.
• Due-by Sprint: Target Sprint number or date by which the action should be completed.
• Status: Planned, In progress, Blocked, or Done with notes on evidence of completion.
• Reference: Links to data (burndown, defects, velocity, customer feedback) that informed the insight.
• Policy updates: Changes to Definition of Done, team working agreements, or standards proposed to the Scrum Guidance Body.

How to Develop/Evaluate

Develop the log during the Sprint Retrospective by:

• Preparing inputs: Sprint Goal, completed user stories, defects escaped, burndown charts, velocity, impediments.
• Generating insights: What went well, what did not, and why (root causes, not symptoms).
• Selecting actions: Limit to a few high-impact, team-controllable items; make them specific and time-bound.
• Recording details: Owner, due-by Sprint, success measure, and any dependencies or risks.

Evaluate quality by checking that each entry is clear, testable, small enough to complete soon, and has exactly one owner and a measurable outcome.

How to Use

• During Sprint Planning, reserve capacity to implement selected improvements and reflect them on the Scrumboard.
• In Daily Standups, briefly track progress on improvement actions and escalate blockers to the Impediment Log.
• Update Definition of Done or working agreements when actions change policies or standards.
• Feed major, cross-team learnings to Scrum of Scrums and propose updates to the Scrum Guidance Body.
• Provide input to the release or project retrospective to summarize trends across Sprints.
• Archive completed logs in a shared repository to support organizational learning and onboarding.

Example Snippet

• Insight: Test flakiness delayed 3 stories. Action: Stabilize CI tests for checkout module. Owner: Priya. Due: Sprint 12. Measure: 90% pass rate on first run.
• Insight: PBIs lacked acceptance criteria. Action: Add INVEST and AC checklist to refinement. Owner: Sam (PO). Due: Sprint 11. Measure: 0 stories fail due to unclear AC.
• Insight: Long handoffs with Ops. Action: Add deployment runbook and shared channel. Owner: Jin. Due: Sprint 11. Measure: Deployment time cut from 2h to 30m.

Risks & Tips

• Risk: Too many items dilute focus. Tip: Limit WIP to 1-3 actions per Sprint.
• Risk: Blame culture blocks candor. Tip: Keep retrospectives blameless and data-informed.
• Risk: No follow-through. Tip: Make actions visible on the Scrumboard and revisit weekly.
• Risk: Actions beyond team control. Tip: Escalate systemic issues via Scrum of Scrums or management.
• Risk: Vague outcomes. Tip: Define success measures and a clear done state for each action.

PMP/SCRUM Example Question

During a Sprint Retrospective, the team agrees on three improvements and records them in the Retrospect Sprint Log(s). What should the Scrum Master do next to ensure these improvements are implemented?

1. Ask the Product Owner to add them as new epics to the product backlog for future releases.
2. Schedule a separate improvement project after the current release is complete.
3. Work with the team to allocate capacity in the next Sprint and track the actions on the Scrumboard.
4. Send the log to stakeholders and close the items as communicated.

Correct Answer: C — Work with the team to allocate capacity in the next Sprint and track the actions on the Scrumboard.

Explanation: Retrospect Sprint Log(s) are intended to drive near-term, team-controlled improvements. The Scrum Master helps the team plan and track these actions in the next Sprint; they are not deferred to epics or closed by communication alone.