HKSM

A curated record of insights, root causes, and actionable improvements captured by the Scrum Team, especially during retrospectives. It is stored for reuse and becomes an input to upcoming sprints, planning, and organizational learning. In SBOK terms, it is an output of Retrospect Sprint/Project and an input to multiple planning and improvement processes.

Key Points

• Created primarily in Retrospect Sprint and Retrospect Project, then updated continuously.
• Captures what helped, what hindered, root causes, and agreed actions with owners and due dates.
• Acts as an output from retrospectives and an input to Release Planning, Sprint Planning, and Backlog Refinement.
• Stored in a shared repository such as a team space or Scrum Guidance Body knowledge base.
• Feeds updates to Definition of Done, Definition of Ready, and team Working Agreements.
• Prevents repeat issues, improves predictability, and spreads good practices across teams.

Purpose

The goal is to turn experience into repeatable improvements that raise product quality and flow efficiency. By documenting insights with clear actions, the team reduces waste, defects, and delays in future sprints.

As an input-output artifact, it links learning cycles to planning and execution. Lessons guide estimates, risk responses, process tweaks, and coaching focus for the next sprint and beyond.

Key Terms & Clauses

• Agreed Actionable Improvements: Specific changes the team commits to implement, each with an owner and target sprint.
• Root Cause: The underlying reason an issue occurred, identified using methods like 5 Whys or cause-and-effect diagrams.
• Working Agreements: Team rules (e.g., code review policy, DoD) updated when lessons indicate a gap.
• Definition of Done (DoD) / Definition of Ready (DoR): Quality and readiness checklists that lessons often refine.
• Impediment Log: Running record of blockers; patterns from the log often feed lessons and actions.
• Scrum Guidance Body Repository: Organizational store for standards and knowledge; lessons may be promoted here for cross-team reuse.

How to Develop/Evaluate

1. Prepare: Bring data to the retrospective (flow metrics, defects, escaped bugs, impediments, deployment incidents).
2. Gather insights: Capture what went well, what did not, and observed patterns using timeboxed facilitation.
3. Find root causes: Apply 5 Whys or similar tools to avoid superficial fixes.
4. Decide actions: Convert insights into small, testable improvements with owner, due date, and success criteria.
5. Record and categorize: Tag by theme (quality, tooling, backlog, collaboration) and link to related user stories or incidents.
6. Publish and track: Store in the team repository and review progress in Daily Standups and Sprint Planning.

• Evaluation checks: Is each lesson specific, evidence-based, and linked to a measurable outcome.
• Is a root cause identified and validated with data or examples.
• Is there a named owner, target sprint, and clear test of success.
• Has the team prioritized top actions to avoid overloading the next sprint.

How to Use

As an input, reference the latest lessons during Release Planning and Sprint Planning to adjust capacity, refine estimates, and choose improvement actions for the next sprint.

• Backlog Refinement: Update acceptance criteria, split user stories earlier, or adjust priorities based on quality or flow lessons.
• Sprint Planning: Include 1-2 top improvement tasks in the Sprint Backlog and align with DoD/DoR updates.
• Daily Standup: Track progress on improvement actions like any other sprint task.
• Scrum of Scrums: Share cross-team lessons; escalate systemic issues to program-level owners.
• Organizational Learning: Promote broadly valuable lessons to the Scrum Guidance Body repository.

Example Snippet

Example entry fields for a lessons learned log:

• Theme: Quality. Observation: 3 escaped defects tied to incomplete API contracts. Root Cause: No contract tests in CI.
• Action: Add contract tests to CI for all new endpoints. Owner: Dev Lead. Target Sprint: Sprint 9. Success: Zero API contract-related escaped defects in Sprint 9.
• Theme: Flow. Observation: Frequent churn in sprint due to vague stories. Root Cause: Missing DoR criteria.
• Action: Update DoR to require example-based acceptance criteria. Owner: Product Owner. Target Sprint: Sprint 9. Success: Story rework reduced by 50 percent.

Risks & Tips

• Risk: Blame culture stops honest insights. Tip: Focus on process and data, not individuals.
• Risk: Vague lessons without owners stall. Tip: Require owner, due date, and success metric.
• Risk: Lessons are stored but not used. Tip: Review top items in Sprint Planning and track on the Sprint Board.
• Risk: Too many actions overload the team. Tip: Limit work-in-progress; pick the most valuable 1-2 improvements per sprint.
• Risk: Local optimizations conflict across teams. Tip: Share in Scrum of Scrums and align through the Scrum Guidance Body.

PMP/SCRUM Example Question

During Sprint Planning, the team wants to avoid repeating a deployment failure seen last sprint. Which artifact should they consult as an input to select concrete improvement actions for this sprint.

1. Product Increment.
2. Scrum Team Lessons Learned.
3. Product Vision Statement.
4. Sprint Burndown Chart.

Correct Answer: B — Scrum Team Lessons Learned

Explanation: Lessons Learned captures root causes and agreed actions from retrospectives, making it the correct input for selecting improvement work. The other artifacts do not contain actionable retrospective outcomes.