Catalog
method#Delivery#Product#Governance

Retrospective

Short, structured session for team reflection and continuous improvement after sprints or iterations.

A retrospective is a structured team practice for regular reflection on ways of working, collaboration, and outcomes.
Established
Low

Classification

  • Low
  • Organizational
  • Organizational
  • Intermediate

Technical context

Jira for action and backlog trackingConfluence for notes and follow-up documentationSlack/Teams for asynchronous follow-up and discussion

Principles & goals

Respect the timebox to ensure focus and efficiency.Prioritize concrete, actionable items over general criticism.Create psychological safety to enable honest feedback.
Iterate
Team, Domain

Use cases & scenarios

Compromises

  • Blame culture instead of constructive analysis.
  • Too many actions lead to low implementation capacity.
  • Recurring issues persist if root causes are not addressed.
  • Strictly enforce the timebox to maintain focus.
  • Agree on at most three priority actions per session.
  • Document results and make ownership visible.

I/O & resources

  • Sprint or iteration results
  • Metrics and key figures
  • Observations and feedback from team members
  • Concrete actions with owners
  • Improved team agreements
  • Backlog items for follow-up

Description

A retrospective is a structured team practice for regular reflection on ways of working, collaboration, and outcomes. In a timeboxed session the team identifies successes, problems, and concrete improvement actions. The method fosters continuous learning through agreed experiments and a facilitator who ensures focus and tracks commitments.

  • Continuous improvement through regular reflection.
  • Quick detection and remediation of process issues.
  • Promotes team learning and transparency.

  • Ineffective without commitment and follow-up on actions.
  • Can remain superficial without proper facilitation.
  • Requires regular cadence or the learning effect is lost.

  • Action implementation rate

    Share of agreed actions implemented by the next cycle.

  • Recurring topics

    Number of topics recurring across multiple retrospectives.

  • Team satisfaction

    Qualitative rating of satisfaction with working practices and improvements.

Improving the deploy pipeline

Team identified long release times and agreed on two actions for automation and measurement.

Increasing test coverage

After recurring bugs, a test backlog was created and ownership defined.

Improved team communication

The team introduced daily syncs, reducing coordination overhead and blockers.

1

Define the framework: set goal, timebox, and participants.

2

Collect data: prepare facts, metrics, and observations.

3

Run: moderated session with clear activities (e.g., Start-Stop-Continue).

4

Prioritize actions and assign owners.

5

Follow-up: add actions to backlog and review in the next retrospective.

⚠️ Technical debt & bottlenecks

  • Untracked actions lead to lost trust.
  • Missing documentation hinders later analysis.
  • No clear owner for improvements increases execution risk.
TimePsychological safetyImplementation capacity
  • Using retrospective as a venting session instead of structured learning.
  • Agreeing actions but never integrating them into the workflow.
  • Only managers report; team feedback is ignored.
  • Agreeing on unclear or too many actions.
  • Not defining success metrics.
  • Repeating the same topics without addressing causes.
Facilitation and timeboxingActive listening and feedback cultureRoot-cause analysis skills (e.g., 5 Whys)
Continuous learning and improvementTransparency of processes and team dynamicsFast feedback cycles
  • Limited time per sprint
  • Lack of management support reduces impact
  • Missing facilitation skills in the team