How long should a sprint retrospective be?

60–90 minutes for a two-week sprint; up to two hours for a four-week sprint. Shorter than 45 minutes rarely allows insight; longer than two hours loses team energy.

Who should facilitate the retrospective?

Ideally a rotating team member or the Scrum Master — not the line manager. Manager-led retros tend to slide into performance theatre, with the team telling the manager what they want to hear.

What if the team raises the same issue every sprint?

That is a signal, not noise. Either the action isn't being completed (commitment problem) or the issue is outside the team's control (escalation problem). Either way, the pattern requires intervention, not another retro.

How many improvement actions should we commit to?

One or two. Teams that commit to five or more rarely complete any. Doable beats ambitious; the discipline of finishing one improvement is more valuable than listing ten.

What format should we use?

Vary formats every few sprints. Start-Stop-Continue is a reliable starter; 4Ls (Liked, Learned, Lacked, Longed For) goes deeper; Sailboat and Mad-Sad-Glad add emotional and metaphorical lenses. The variety is the point.

How do you make a retro safe?

Ground rules at the start, anonymous data collection (sticky notes, digital tools), no managers reporting upward on individuals, and explicit confidentiality. Safety is built over months; a single broken confidence sets it back a year.

Should stakeholders attend?

No. The retrospective is the team's space. Stakeholder feedback belongs in sprint reviews and product-level retrospectives, not in the team's improvement ceremony.

What's the construction equivalent?

End-of-phase lessons-learned sessions, or in lean construction, the weekly look-ahead retrospective. The cadence is different but the discipline — inspect honestly, commit to one or two improvements, follow through — is identical.

Which calculators on PMMilestone.org apply to Sprint Retrospective?

For Sprint Retrospective, the most relevant tools on the flagship platform are the EVM, SPI and CPI calculators on PMMilestone.org. They reproduce the formulas referenced in this entry against your own project data.

What is a common misconception about Sprint Retrospective?

That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.

Which related encyclopedia entries should I read alongside Sprint Retrospective?

Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.

How does Dr. Hassan Eliwa's research treat Sprint Retrospective?

Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Sprint Retrospective is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.

How is Sprint Retrospective defined on PMMilestone Research & Insights?

A time-boxed agile ceremony at the end of each sprint where the team inspects how it worked together and commits to specific improvements for the next sprint. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

How long should a sprint retrospective be?

60–90 minutes for a two-week sprint; up to two hours for a four-week sprint. Shorter than 45 minutes rarely allows insight; longer than two hours loses team energy.

Who should facilitate the retrospective?

Ideally a rotating team member or the Scrum Master — not the line manager. Manager-led retros tend to slide into performance theatre, with the team telling the manager what they want to hear.

What if the team raises the same issue every sprint?

That is a signal, not noise. Either the action isn't being completed (commitment problem) or the issue is outside the team's control (escalation problem). Either way, the pattern requires intervention, not another retro.

How many improvement actions should we commit to?

One or two. Teams that commit to five or more rarely complete any. Doable beats ambitious; the discipline of finishing one improvement is more valuable than listing ten.

What format should we use?

Vary formats every few sprints. Start-Stop-Continue is a reliable starter; 4Ls (Liked, Learned, Lacked, Longed For) goes deeper; Sailboat and Mad-Sad-Glad add emotional and metaphorical lenses. The variety is the point.

How do you make a retro safe?

Ground rules at the start, anonymous data collection (sticky notes, digital tools), no managers reporting upward on individuals, and explicit confidentiality. Safety is built over months; a single broken confidence sets it back a year.

Should stakeholders attend?

No. The retrospective is the team's space. Stakeholder feedback belongs in sprint reviews and product-level retrospectives, not in the team's improvement ceremony.

What's the construction equivalent?

End-of-phase lessons-learned sessions, or in lean construction, the weekly look-ahead retrospective. The cadence is different but the discipline — inspect honestly, commit to one or two improvements, follow through — is identical.

Which calculators on PMMilestone.org apply to Sprint Retrospective?

For Sprint Retrospective, the most relevant tools on the flagship platform are the EVM, SPI and CPI calculators on PMMilestone.org. They reproduce the formulas referenced in this entry against your own project data.

What is a common misconception about Sprint Retrospective?

That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.

Which related encyclopedia entries should I read alongside Sprint Retrospective?

Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.

How does Dr. Hassan Eliwa's research treat Sprint Retrospective?

Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Sprint Retrospective is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.

How is Sprint Retrospective defined on PMMilestone Research & Insights?

A time-boxed agile ceremony at the end of each sprint where the team inspects how it worked together and commits to specific improvements for the next sprint. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

Agile · Letter S

Sprint Retrospective

A time-boxed agile ceremony at the end of each sprint where the team inspects how it worked together and commits to specific improvements for the next sprint.

By Dr. Hassan Eliwa, PhD · Founder of PMMilestone.org and PMMilestone.com · Updated 2026-06-22

Definition

The Sprint Retrospective is the agile team's dedicated time to inspect itself — its process, tools, relationships, and Definition of Done — and to commit to concrete improvements for the next sprint. It is not a venting session, a status read-out, or a postmortem; it is the team's primary continuous-improvement engine. A team without effective retrospectives stops improving even if it ships every sprint.

History

Retrospectives existed in software engineering before Scrum (Norm Kerth's Project Retrospectives, 2001), but Scrum made them a mandatory closing ceremony of every sprint. Esther Derby and Diana Larsen's Agile Retrospectives (2006) gave the practice its modern five-phase structure and the broad library of facilitation techniques teams use today.

Five Phases (Derby & Larsen)

Set the Stage: open the room, agree on focus and safety.
Gather Data: collect facts and feelings from the sprint.
Generate Insights: analyse causes and patterns.
Decide What to Do: select one or two concrete experiments.
Close the Retrospective: thank the team, confirm commitments.

Principles

Safety first: without psychological safety, retros become theatre.
Time-boxed: 60–90 minutes for a two-week sprint.
Action-oriented: the deliverable is improvements, not vents.
Variety of formats: the same format every sprint loses energy.
Follow-through: if last sprint's actions weren't done, that is the first topic.

Real-World IT / Agile Example

A platform team's retros had drifted into ritual — same format, no new actions, no follow-through. We changed three things: rotated facilitator, capped commitments at two actions per sprint, and started each retro with a five-minute review of last sprint's actions. Within four sprints, the team had retired three long-running pain points (flaky CI, ambiguous code-review SLA, on-call rota friction). The retros stopped being a tax and started being the most valued ceremony of the sprint.

Real-World Construction Example

The construction equivalent is the lessons-learned session at phase or milestone close. On a metro-station fit-out, the trades held a 90-minute retro at the end of each two-week construction sprint. Three repeat issues — late material approvals, sequencing conflicts at lift cores, and ambiguous interfaces between sub-contractors — were identified and resolved with process changes. Productivity in the second half of the project rose by 22% with the same labour mix.

Project Controls Perspective

Controls teams track action follow-through rate (actions completed / actions committed) and repeat themes (topics raised across multiple retros). A team with follow-through below 60% has a commitment problem; a team with the same theme raised five sprints in a row has a leadership problem. Retros are not a controls artefact, but the metrics they produce are.

Common Mistakes

Same format every sprint; energy dies.
No safety; the same handful of people speak.
Too many commitments; nothing gets done.
No follow-through; trust in the process erodes.
Manager-led retros; team turns to performance theatre.
Skipping the retro under sprint pressure — exactly when it matters most.

Expert Tips

Cap actions at two. Doable beats ambitious.
Rotate facilitators. Fresh eyes find fresh patterns.
Start with last sprint's actions. Accountability sets the tone.
Vary formats. Start-Stop-Continue, 4Ls, Sailboat, Mad-Sad-Glad — rotate.
End with a thank-you round. Closing on appreciation builds the team.

Key Takeaways

Retros are the team's continuous-improvement engine.
Safety, action focus, follow-through — the three load-bearing practices.
Two actions per sprint beats ten.
The construction equivalent — lessons-learned sessions — proves the value is universal.
Follow-through rate is the diagnostic that matters.

Related Concepts

Retrospectives connect to Agile, Lessons Learned, Daily Stand-up, Backlog Refinement, and Kanban. Facilitation templates at PMMilestone.org.

Frequently Asked Questions

How long should a sprint retrospective be?
60–90 minutes for a two-week sprint; up to two hours for a four-week sprint. Shorter than 45 minutes rarely allows insight; longer than two hours loses team energy.
Who should facilitate the retrospective?
Ideally a rotating team member or the Scrum Master — not the line manager. Manager-led retros tend to slide into performance theatre, with the team telling the manager what they want to hear.
What if the team raises the same issue every sprint?
That is a signal, not noise. Either the action isn't being completed (commitment problem) or the issue is outside the team's control (escalation problem). Either way, the pattern requires intervention, not another retro.
How many improvement actions should we commit to?
One or two. Teams that commit to five or more rarely complete any. Doable beats ambitious; the discipline of finishing one improvement is more valuable than listing ten.
What format should we use?
Vary formats every few sprints. Start-Stop-Continue is a reliable starter; 4Ls (Liked, Learned, Lacked, Longed For) goes deeper; Sailboat and Mad-Sad-Glad add emotional and metaphorical lenses. The variety is the point.
How do you make a retro safe?
Ground rules at the start, anonymous data collection (sticky notes, digital tools), no managers reporting upward on individuals, and explicit confidentiality. Safety is built over months; a single broken confidence sets it back a year.
Should stakeholders attend?
No. The retrospective is the team's space. Stakeholder feedback belongs in sprint reviews and product-level retrospectives, not in the team's improvement ceremony.
What's the construction equivalent?
End-of-phase lessons-learned sessions, or in lean construction, the weekly look-ahead retrospective. The cadence is different but the discipline — inspect honestly, commit to one or two improvements, follow through — is identical.
Which calculators on PMMilestone.org apply to Sprint Retrospective?
For Sprint Retrospective, the most relevant tools on the flagship platform are the EVM, SPI and CPI calculators on PMMilestone.org. They reproduce the formulas referenced in this entry against your own project data.
What is a common misconception about Sprint Retrospective?
That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.
Which related encyclopedia entries should I read alongside Sprint Retrospective?
Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.
How does Dr. Hassan Eliwa's research treat Sprint Retrospective?
Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Sprint Retrospective is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.
How is Sprint Retrospective defined on PMMilestone Research & Insights?
A time-boxed agile ceremony at the end of each sprint where the team inspects how it worked together and commits to specific improvements for the next sprint. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.

View the full FAQ page for Sprint Retrospective →