HKSM

A short, prioritized set of specific, owned, and time-bound process or practice changes the Scrum Team commits to implement after a Retrospect Sprint or Retrospect Project. They are treated as real work in upcoming sprints and tracked to completion. This output feeds the next Sprint Planning and related Scrum processes to sustain continuous improvement.

Key Points

• Created during Retrospect Sprint or Retrospect Project and committed by the team.
• Concrete, small, and testable improvements with a clear owner and target sprint.
• Captured as tasks or small backlog items and included in the Sprint Backlog.
• Progress is reviewed in Daily Standup and verified at the next Retrospective.
• Links to Definition of Done, Working Agreements, and Impediment Log updates.
• Limited in number per sprint to preserve delivery focus, typically one to three items.
• May inform the Scrum Guidance Body when practices are worth standardizing.

Purpose

The goal is to turn retrospective insights into visible, executable work that improves flow, quality, and team effectiveness. By committing to small, achievable changes, the team avoids vague lessons and builds a habit of inspection and adaptation.

Key Terms & Clauses

• Owner: Single person responsible for shepherding the change.
• Target Sprint: The sprint in which the change will be completed or piloted.
• Acceptance Measure: How success will be verified (e.g., a metric, checklist update, or demonstration).
• Working Agreement/DoD Link: Any adjustments to team agreements or Definition of Done.
• Escalation Path: If blocked, the Scrum Master facilitates, using the Impediment Log or organizational support.
• Standardization: If successful beyond one team, propose inclusion in the Scrum Guidance Body.

How to Develop/Evaluate

During the retrospective, gather data, identify root causes, and list candidate improvements. Prioritize by impact versus effort, then select a small set to commit.

• Write each item as a SMART action: clear, measurable, and feasible within a sprint.
• Assign an owner and define the acceptance measure (e.g., updated DoD, metric change, or artifact produced).
• Limit WIP: choose one to three items to ensure focus and completion.
• Check dependencies and secure support needed from stakeholders or tools.
• Record links to related impediments, defects, or quality metrics.

How to Use

Add the selected items to the Sprint Backlog with tasks and capacity set aside in Sprint Planning. Track them on the team board and discuss status in Daily Standup.

• If the change alters quality criteria, update the Definition of Done and communicate to stakeholders.
• If the change is organization-wide, propose an update to the Scrum Guidance Body after validation.
• Demonstrate outcomes where feasible in Sprint Review (e.g., improved build time) and verify completion in the next Retrospective.
• If blocked, log the impediment and have the Scrum Master facilitate removal or escalation.

Example Snippet

• Introduce code review checklist before merge — Owner: Priya — Target: Sprint 7 — Acceptance: Checklist added to DoD and used on 100% of PRs this sprint.
• Cut CI build time to under 10 minutes via caching — Owner: Marco — Target: Sprint 7 — Acceptance: Median CI time under 10 minutes for the sprint.
• Daily backlog refinement mini-session (15 minutes) — Owner: Sam — Target: Sprint 8 — Acceptance: Top 10 stories meet ready criteria by day 3.

Risks & Tips

• Risk: Too many items dilute focus. Tip: Select one to three high-impact actions per sprint.
• Risk: Vague statements like "communicate better." Tip: Rewrite as SMART actions with measures.
• Risk: No capacity reserved. Tip: Allocate time in Sprint Planning and track as tasks.
• Risk: No ownership or follow-through. Tip: Assign a single owner and review progress daily.
• Risk: Local fix to a systemic issue. Tip: Escalate via the Scrum Master and propose SGB updates when warranted.

PMP/SCRUM Example Question

During a Sprint Retrospective, the team selects two high-impact changes to reduce escaped defects. What should the Scrum Master advise the team to do next?

1. Archive the ideas and revisit them at the end of the project.
2. Ask the Product Owner to add them as low-priority product features.
3. Add them to the next Sprint Backlog with owners, acceptance measures, and capacity reserved.
4. Have the Scrum Master track them privately outside the board to avoid distracting the team.

Correct Answer: C — Add them to the next Sprint Backlog with owners, acceptance measures, and capacity reserved.

Explanation: Agreed Actionable Improvements are executable work items resulting from the retrospective. They should be planned, owned, and tracked in the next sprint, not archived or managed outside team visibility.