Scrum is a process of continuous improvement, and the Scrum retrospective is a time for teams to reflect on the opportunities to accomplish this. The sprint retrospective is a recurring meeting dedicated to discussing overall workflow enhancements while recovering at the end of a sprint and preparing to go forward with the next one, so you can make each sprint more streamlined and successful than the last.
What is a sprint retrospective?
The sprint retrospective is a recurring meeting held at the end of a sprint used to discuss what went well during the previous sprint cycle and what can be improved for the next sprint. The Agile sprint retrospective is an essential part of the Scrum framework for developing, delivering, and managing complex projects. Since the early 1990s, Scrum has been used to develop:
- Embedded software
- Networks of interacting function
- Autonomous vehicles
- And much more
Continuous, iterative improvement is a core goal in Scrum product management, and the Scrum retrospective meeting is an official opportunity to achieve this at defined, consistent intervals—when teams have wrapped up a sprint and have a space to reflect and improve how things are done. That said, continuous improvement requires continuous effort. So, it’s important for teams to consciously apply the lessons learned in each retrospective to upcoming sprints.
Whitepaper: How to Become an Agile Agency
Whitepaper: Agile Marketing for Creative Teams
What is the purpose of a sprint retrospective?
The Scrum sprint retrospective is a timeboxed meeting that takes place after the sprint review and before sprint planning. Its purpose is to:
- Examine how the just-completed sprint went as far as people, relationships, processes, and tools.
- Identify and order what went well.
- Do the same with things that didn’t go well.
- Identify potential improvements.
- Create a plan for implementing improvements to the way the Scrum team accomplishes its work.
Everything that affects how the Scrum team develops the product is open to discussion and improvement, including processes, tools, artifacts, environment, and so on. It allows development teams to adapt Scrum to their particular circumstances.
Scheduling a Scrum retrospective at the end of every sprint ensures that needed changes are understood and implemented before they are lost in the rush of new work. It helps each Scrum team member to identify how they can improve the specific things they contributed to the sprint, asking:
- What work has been done well in this sprint?
- What work hasn’t been done well?
- What should we start doing to improve?
During each Agile sprint retrospective, the development team focuses on increasing product quality by improving work processes or adapting the definition of “done.” This definition may vary from Scrum team to Scrum team. But the whole team must have the same understanding of “done” to assess when work has met expected standards.
As Scrum teams gain more experience, their definition of “done” will evolve, including more demanding criteria for higher-quality results.
Who runs a sprint retrospective meeting?
The sprint retrospective team usually includes all development team members, the Scrum Master, and the product owner. The development team is everyone who is designing, building, and testing the product. Collectively, its members have a wide range of valuable perspectives for identifying process improvements from different points of view.
The Scrum Master facilitates the meeting and encourages the development team to improve its workflow practices within the Scrum process framework, so improvements can be enacted during the next sprint. The Scrum master is also the process coach for the Scrum team, pointing out when it is not adhering to an agreed-upon method of proceeding and providing ideas and expertise as needed.
Stakeholders and managers who are not directly part of the team usually don’t come to a Scrum retrospective unless specifically invited. They participate in the Sprint review meeting instead, where the Scrum team shows what they accomplished during the sprint, often including product demos.
Datasheet: The Agile Marketing Cheat Sheet
How to run a sprint retrospective:
There are many ways to run a sprint retrospective. One of the most common is using a start-stop-continue approach. Each development team member is asked to identify the things the team should start doing, the ones they should stop doing, and the things they should continue doing.
The Scrum Master can facilitate this process by asking attendees to call out ideas during the Scrum, or they can go around the room and get feedback on what to start, stop, and continue in a more orderly fashion, person by person.
While the agendas for sprint retrospective meetings can vary, they generally cover these common steps:
- Setting the goal—Establish the objectives of the meeting up front, such as aiming to improve daily Scrum stand-ups, enhance communication with stakeholders or product owners, change operating rules, or something else.
- Gathering essential data—Draw on everyone’s experience and perspective to create a shared body of information.
- Developing insights—From the amassed data, identify useful patterns and see the big picture, always asking why things happened the way they did.
- Deciding on the next steps—Identify the issues and challenges the team will tackle, and put in place a concrete plan of how to achieve success for each one.
- Closing the retrospective—Clarify and summarize the meeting, thank participants, and consider how future retrospectives could be improved.
The length of the Scrum retrospective meeting can vary according to:
- How many team members there are
- Whether the team is distributed and needs to meet remotely
- How many new team members have to be brought up to speed
That said, as a rule of thumb, sprint retrospectives often run:
- 45 minutes for a one-week sprint
- 1.5 hours for a two-week sprint
- 2.25 hours for a three-week sprint
- 3 hours for a month-long sprint
Questions commonly asked in a sprint retrospective include:
- What went well in the sprint? Success in an iteration can be analyzed by looking at what was done differently to achieve it; who contributed to it and how; and what skills, training, or knowledge made a difference.
- What went wrong in the sprint? The point is not to penalize the team or individual members but look at things that didn’t go according to plan, with a view of improving performance in the future.
- What did we learn? What did the team learn in the sprint so that they can improve their way of working?
- How should the next sprint play out? This will determine corrective actions to take in the next sprint, preventing the same mistakes from occurring, and making successful actions a repeatable outcome.
Learn more: Workfront for Project Management
Blog: Agile vs Waterfall
Commonly asked questions
What’s the difference between a sprint retrospective and sprint review?
While the sprint review is an opportunity to inspect and adapt the product—giving everyone input into its development—the sprint retrospective involves inspecting and adapting the process. During the sprint retrospective, teams analyze how they work, identify ways to work better, and make plans to implement these improvements.
When is a sprint retrospective meeting held?
The sprint retrospective is held between sprints, after the sprint review and before sprint planning for the next sprint. While some teams might be tempted to hold a sprint review and sprint retrospective simultaneously, the meetings work better if kept separate, so only the relevant parties attend, and the purpose of the meeting is clearly understood by all involved.
Who should attend the sprint retrospective?
The meeting should be attended by the Scrum Master, who facilitates the meeting, the full Scrum team, and the product manager. The Scrum team includes everyone who is designing, building, and testing the product. While some feel the product owner shouldn’t attend—because they might inhibit honest discussion among team members—they are an essential part of the Scrum process, so their participation is generally a good idea.