How do I run a Retrospective?

The Retrospective is one of five events in Scrum. It’s purpose is to inspect the whole Scrum Team from the perspective of people, process and tools, and then adapt the way the whole team works. 


Like all Scrum’s events, the Retrospective is a mechanism of empiricism – inspecting the way the team works, collaborates and delivers its outcomes. The outcome of the Retrospective are actionable items that are added to the Sprint Backlog for the upcoming Sprint.

Who attends?

  • The Product Owner (they’re part of the Scrum Team).
  • The Agile Team (also known as the Development Team).
  • The Scrum Master.

Managers, stakeholders, and other parties don’t attend the Retrospective. Sometimes Retrospectives require a safe place to discuss failures or have difficult conversation about what’s not working within the team and why. 

What does the Retrospective involve?

The whole Scrum Team:

  • Examines data from the Sprint. This could include velocity trends, the quality of its work, cycle time, assessing whether estimations were accurate, team morale, customer satisfaction, or action plans for improvements from the previous Retrospective.
  • Discusses behaviours that impacted the Sprint – both positive and negative.
  • Generates insights into what happened during the Sprint, what the metrics really mean, and why.
  • Identifies tangible improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.

The Scrum Master:

  • Encourages openness, courage to have honest conversations, and to make improvements and opportunities for learnings transparent. 
  • Helps the Scrum Team to ensure that items from the Retrospective are actionable by the team themselves.
  • Helps guide the conversation to encompass the whole Scrum Team, including the Product Owner, not just what individuals might do to improve delivery of the Increment.

Actions from the Retrospective aren’t “let’s do a workshop next Sprint to make a decision or plan”. The Retrospective is that workshop.

Scrum Masters may also have to remind participants that removing Scrum events is not within their power to decide “not to do”. If an event isn’t proving of value to the Scrum Team, discussion should encompass “what can we all do to improve its value”, not “let’s just not do it anymore”.

Download the Retrospective Checklist

About the author

Related Posts

The Ultimate Guide to Agile Reporting

You have reports to deliver to executive. Delivery, risk, and cost is foremost on their mind. What kind of reports on your agile capability and delivery, based on objective agile project management metrics, are going to provide you with the best transparency of what’s really going on?


What Tools Does Your Agile Development Team Use?

The market is full of agile project management metrics tools that help with on-time and on-budget delivery, but where are the tools that help coaches and consultants understand how to scale agile capability development? Do existing tools do the job well enough?


Agile metrics and why team surveys fail

Agile project management metrics often rely on team surveys to find out how agile the organisation is. Team surveys fail for many reasons. Here’s our top tips on what to look out for and how to measure agile in a repeatable and scalable way.


5 agile metrics you won’t hate

Agile project management tends to focus on velocity as a measure of agility. The real things that help leaders measure their agile capability are far more interesting.

search previous next tag category expand menu location phone mail time cart zoom edit close