What Is an Agile Project Retrospective?
An Agile project retrospective (also called a sprint retrospective) is a meeting in which a team assesses its work processes and brainstorms improvements. This meeting happens during the life of a project and often occurs every two weeks.
What is a retrospective? In a retrospective, team members discuss the practices they have employed regarding their recent work — what has gone well, what needs improving, and what lessons they can learn. The work they examine may span a certain time period, such as two weeks (the length of a sprint), or focus on a specific project phase or milestone, such as contract negotiations.
The retrospective happens at intervals while the work is still underway, so the team can make refinements during the next work period.
What Is the Purpose of a Retrospective?
The purpose of a retrospective is for a team to work together to identify which practices are successful and which need to change. The group discusses potential changes, then makes a plan to implement the top one or two ideas.
The targeted improvements can concern speed, quality, cost, job satisfaction, or any other dimension of the work.
Holding retrospectives is part of the Agile methodology. This approach allows teams to become more effective over time by continuously making small improvements to their practices. Learn more about Agile project management, best practices, and tools.
Retrospectives are effective partly because they help build a culture of open communication, which fosters trust and unifies a team around its goals. For these reasons, retrospectives often start by cultivating a mutual understanding such as the prime directive, which states that everyone must believe that all team members did the best job they could in the circumstances that were present.
Retrospectives also empower teams to have greater control over the way they work. This empowerment supports ownership, initiative, and higher quality.
Agile Project Management E-book
How can Agile PM help you do more with less?
Agile project management empowers teams to adapt to change with increased speed and flexibility. Learn how to implement Agile PM and get the most out of the methodology.
What a Retrospective Is Not
A retrospective is distinct from other meetings such as reviews, release retrospectives, and lessons learned sessions. Those meetings either occur when the team has completed all the work or focus on the product rather than the work methodology.
There are also so-called anti-patterns — i.e., attributes that, when present, turn a retrospective into just another meeting.
Let’s look at Agile sprint reviews vs. retrospectives, as well as other kinds of Agile reviews vs. retrospectives.
- Sprint Review: This process evaluates the work you’ve accomplished in a sprint, a defined time period in software development that is usually two weeks. (Learn more about successful sprint planning, including best practices, checklists, and templates.) The sprint review sets up another work cycle. Participants in the review look at the quality of the work they’ve completed, determine whether the work aligns with the relevant product or plan for the quarter/year, and consider whether to make any adjustments before the next sprint.
- Release Retrospective: This process also applies to software development. A software release is the product of many sprints and yields either a new program or an update to an existing application. The release retrospective seeks to evaluate the processes across all the sprints that contributed to the release. This meeting may draw upon multiple teams and/or teams from different areas of the organization.
- Project Review: This process can occur either when the project is underway or when it reaches completion. This review looks at the work output. The team considers whether the project work meets objectives, fits with the organization’s larger goals, and lays the foundation for a new project. Participants evaluate the work itself, not the team’s methods or processes.
- Lessons Learned: This is a process in which project participants provide input on what the team learned. The project manager then documents and analyzes this input, so the organization can apply these lessons the next time it undertakes a similar project. Learn how to capture and document lessons learned in our comprehensive guide.
Agile coaches stress that it’s important to do team retrospectives regularly, so you can learn, improve, and celebrate successes as the work unfolds rather than at the end. Waiting until an end-of-project review, especially if the project spans many months, can make it difficult to remember salient details.
You may wonder about the differences between a project retrospective and a lessons learned session. While project retrospectives and lessons learned meetings share similarities, in practice, lessons learned sessions can be vulnerable to the blame game, even though that’s not the intention.
Retrospectives with significant flaws, or anti-patterns, run counter to the intentions of a retrospective, which are to promote open, sincere, blame-free discussion and identify ways to improve. When these anti-patterns arise, the following occurs: Team members have a hard time believing in the potential benefits of change; the team sees retrospectives as dispensable and often skips them; the facilitator does not allocate adequate time; and the meeting becomes a complaint session in which members don’t work toward change. A meeting is no longer a retrospective when the facilitator dominates the discussion or lectures the team.
Why Is a Retrospective Important in Agile?
A retrospective is important in Agile because it fulfills a primary Agile principle: continuous improvement. Because the retrospective occurs while work is unfolding, the team has the opportunity to catch problems early and correct them.
Retrospectives espouse many concepts that are central to Agile principles. Such concepts include the following: welcoming change; supporting individuals and trusting them to accomplish the work; viewing face-to-face conversations as the most effective way to communicate; working toward sustainability; and encouraging self-organizing teams. (You can learn about all Agile principles and values in our comprehensive guide.)
Agile sprint retrospectives help you work toward the ideals above by allowing you to create the optimal conditions for a team to thrive. In order to reap the benefits of Agile sprint retrospectives, be sure to do the following:
- Make continuous improvement a reality.
- Promote stronger, honest communication.
- Offer a framework for creating change.
- Create a habit of expressing appreciation and acknowledging success.
- Provide opportunities for the team and individuals to learn and grow.
- Enable team members to share and pass on their experiences.
- Initiate changes that the team can implement right away.
- Build a culture free of blame.
- Add accountability to action plans.
Project Retrospective vs. Project Post-Mortem
Retrospectives and post-mortems both illustrate how work went. But they have different stakeholders, objectives, timing, and output. The post-mortem manager looks at a completed project or project phase, and their highest priority is to understand mistakes and failure points.
The term post-mortem derives from the Latin words for “after death” and traditionally refers to an autopsy that determines a patient’s cause of death. The objective of a post-mortem meeting is to prevent mistakes from recurring and to mitigate risks. The output of a project post-mortem is usually a report that includes data and evidence about the causes of the project result. You can learn more about post-mortems, including how to run a post-mortem, in this essential guide to post-mortems in business.
Retrospectives occur frequently throughout the project lifecycle or at each iteration, not just at the end. The objective of holding a retrospective is to help the team discover ways to improve incrementally. Conducting a retrospective usually results in one or two action items for implementation.
The nature of a retrospective as a blame-free exercise also contrasts with the goal of a post-mortem, which is to identify failure points. The latter often involves pinpointing the teams or people responsible for poor outcomes. The atmosphere in a post-mortem may be more politicized as a result.
Management drives the post-mortem, due to their need to understand success and failure factors from a high-level perspective, although project teams also participate. Other departments and stakeholders from across the organization may also take part. By contrast, retrospectives occur within the team and usually have an informal atmosphere.
Why You Should Conduct a Project Retrospective
You should conduct a project retrospective because it offers a structured way to improve your team functions by incorporating lessons from successes and stumbles.
What is a project retrospective? In a project retrospective, project team members identify strengths and inefficiencies and share ideas to promote better performance. The retrospective ends with concrete plans to put a few steps into action. These processes help the members of your team learn to communicate more effectively with one another.
A project retrospective yields the following direct and indirect benefits:
- It strengthens accountability for team success.
- It improves future work.
- It increases mutual trust and honesty.
- It boosts morale.
- It makes the work feel more meaningful.
- It helps team members recognize their interdependence.
- It helps team members learn from experience.
- It helps team members embrace change as positive.
- It helps team members understand one another better.
- It fosters team and individual growth.
Why Is Retrospective Methodology Effective?
In today’s business and technology landscape, change is pervasive. The retrospective method is effective because it helps a team adapt more easily and quickly to change.
Retrospective hallmarks, such as striving for honesty in a blame-free environment, bring important ideas into the open, making them actionable.
The retrospective practice of focusing on central questions — what is working well and what needs improvement — produces greater value and keeps the team’s attention on what matters most.
Done correctly, retrospectives are also effective because they occur frequently and allow the team to implement and test potential solutions. With each new retrospective, the group can look back and see how these solutions worked at the last retrospective. In such an environment, work patterns and processes do not become rigid or stale.
What Should You Include in a Retrospective?
A retrospective has a standard structure. The meeting proceeds through six steps or phases. The two most important of these are reviewing how the recent work has gone and brainstorming ways to improve the team’s processes.
Our step-by-step guide on running a results-oriented retrospective gives detailed instructions on how to prepare for and lead a retrospective meeting. This guide includes in-depth discussion of each phase.
Many retrospective facilitators like to structure the meeting around an activity such as Mad Sad Glad or Start Stop Continue. These exercises ask participants to categorize aspects of their project/sprint experience under one of three categories. Check out our rundown on Agile games, ideas, and activities for retrospectives for inspiration.
Here are the six phases of a retrospective:
- Introduction: Go through the ground rules, and perform a safety check or an icebreaker.
- Review: Gather information on what’s working well and what’s challenging. Use activities such as Mad Sad Glad to structure this process.
- Brainstorming: Solicit suggestions on how to address the most important points that came up in the review.
- Prioritizing: Narrow down the list to the most impactful two or three suggestions.
- Action Planning: Decide who will implement the actions and how.
- Closing: Summarize and get feedback on how the retrospective went.
What Data Should You Use in Your Retrospective?
During the review part of the meeting, you should use data wherever possible to validate team reports of successes and setbacks. Hard data is very helpful. But soft data can also provide a lot of crucial information, such as the team’s level of burnout or sense of job satisfaction.
Hard data is a good way to document trends in productivity and quality. You can measure and track the following numbers for each sprint period or project step:
- The percentage of work that the team has achieved by this point vs. the percentage of work that the team had originally set out to achieve by this point
- A burndown chart showing the amount of work that remains vs. the amount of time that remains in which to complete that work
- The number of software story points the team has coded or the number of project activities it has accomplished
- The number of software bugs the team has fixed or the error rate
- The cycle time
- The velocity or rate of progress
- The amount of time the team has spent in meetings
Do not share any data that is related to a specific person or that ranks individual performance. Make sure to confirm that data is accurate before presenting it in the retrospective.
Gather soft data by giving questionnaires to your team on a recurring basis. Have members rate the following on a numerical scale: mood, job satisfaction, sense of fatigue or burnout, etc. While the results of these surveys are not foolproof, they do a good job of making trends visible. These polls also provide a way for the team to air any negative feelings, rather than letting them fester.
What Do You Discuss in a Retrospective Meeting?
Retrospectives seek to answer a short list of questions: What should we start doing? What should we stop doing? What should we continue doing? What steps should we take to address these findings?
These questions focus on the team’s processes and practices, not the work product itself. Numerous Agile retrospective formats and discussion prompts are available for guiding this conversation if you want to vary the meeting slightly. But these four questions and proposed action steps are the essence of the retrospective.
Who Attends a Retrospective?
All team members who have participated in the project or sprint under review attend the retrospective. If you’re holding a project retrospective, the project manager attends and generally leads. If you’re holding a sprint retrospective, the sprint manager also attends.
Including the relevant remote team members in the retrospective is challenging, particularly if your team is spread around the globe. Remote collaboration tools can help. This guide helps you choose from more than 130 remote collaboration tools, so you can find the software that best suits your needs. You can also find tips for running remote retrospectives.
The facilitator of a sprint retrospective is usually the Scrum master but could be the product owner, depending on the latter’s level of involvement in the work. If the product owner has been a particularly active participant, they may even act as the facilitator.
Beyond the team members and the relevant managers, no one else should take part in the retrospective. Sometimes organizational leaders or managers from other departments want to join. You want to make sure that they don’t for a number of important reasons: they do not have firsthand knowledge of the work and, therefore, cannot address the retrospective’s central questions; the presence of outside observers tends to undermine the trust and candor of team members, who may fear repercussions if they are honest about mistakes and deficiencies; and when the retrospective no longer feels like a safe space, the meeting loses significant value.
How to Plan a Retrospective
Holding an effective retrospective takes preparation. If you are the facilitator, make a plan. Allot enough time for the meeting, so you aren’t rushed. And think about how you will create an environment where team members can share their learning.
Holding retrospectives that deliver value is a team-oriented process that requires frequent repetition, so consistency is important. Make sure to follow the same sequence of events at each meeting: introduction, review, brainstorming, prioritizing, action planning, and closing. Plan what you’re going to say and what you and your team are going to do. Put effort into building trust and fostering a feeling of psychological safety with mood checks and icebreakers.
Plan a successful retrospective by following these steps:
- Schedule Enough Time for the Meeting to Generate Valuable Insights: But don’t make the retrospective so long that the team dreads it. Allot about 30 minutes for each week of work you’re reviewing.
- Plan the Content and Activities for Each Section of the Retrospective: In advance of every meeting, make sure you have all the necessary materials (e.g., supplies, posters, snacks).
- Cultivate an Atmosphere of Trust and Candor: Incorporate safety and mood checks. Make it clear that the retrospective will be free of blame.
- Make Time to Celebrate Wins and Successes: The retrospective looks at how the team can work better together. But the process should also acknowledge what’s already working well. Make sure to give equal focus to the ways in which the team can improve and the areas in which the group shows strength. Taking the time to recognize and appreciate members of your team is crucial to motivating them.
- Remote Teams Need Extra TLC: Cultivating a bond among members of remote and distributed teams is challenging. Think about how to inspire trust, collaboration, and a sense of comfort among a group of people who aren’t in the same room together. Be sure to consider culture, language, and time-zone differences.
Check out this detailed guide on how to facilitate a project retrospective.
Agile Retrospective Template
Download Agile Retrospective Template
Microsoft Word I Adobe PDF I Smartsheet
Use this standard retrospective template to quickly get your meeting up and running. The template provides sections for answers to these key questions: What went well? What could have gone better? What will we try next? What questions do we have?
Common Mistakes During Project Retrospectives
The most common problems that can arise during a project retrospective include repetition, inconsistency, scapegoating, and more. Making such mistakes can render a retrospective wholly ineffective, leaving team members feeling demoralized.
To conduct a successful project retrospective (i.e., one that leads to meaningful improvements), avoid the most common mistakes:
- Accusatory: When your retrospective focuses on who is at fault, your meeting cannot be successful. A retrospective only works when no one feels personally attacked. Creating psychological safety and sharing a common understanding of the ground rules are both essential to a successful retrospective.
- Boring: When the retrospective is unengaging, team members tune out and try to avoid attending.
- Hasty: When you don’t allot the appropriate amount of time for the meeting, you set up the retrospective for failure. To calculate the amount of time you need for each meeting, use this rule of thumb: 30 minutes for each week of work you’re reviewing.
- Imbalanced: When your meeting produces too many action steps, your team feels overwhelmed. And when your meeting doesn’t produce enough steps, your team feels unproductive. Create a balance regarding action items in order to give your team realistic goals, as well as the potential for meaningful progress.
- Inconsistent: When you perform retrospectives only sporadically, you send a message to your team: These meetings are not a priority. The value of a retrospective lies in its potential to generate continuous improvement via regularly scheduled meetings.
- Inert: When the retrospectives aren’t generating results (possibly because of inadequate follow-through), there is little reason to hold the meetings.
- Meaningless: If you let the retrospective become merely an empty, box-checking exercise, your team members cease to invest in the process.
- Negative: If you focus only on the negative, you sap the team of motivation.
- Repetitive: If you’re revisiting the same issues at every retrospective, you need to improve your action planning so that your steps have impact.
- Too Late: If you conduct a retrospective after you’ve already completed your project, then it’s too late to apply what you’ve learned in order to improve the work.
- Untrusting: When participants do not feel they can be honest, they aren’t willing to share their best ideas and sincere reflections.
- Whiny: When you allow a retrospective to devolve into a complaint session, you waste time and, worse, permit the spread of negativity.
How Can I Improve My Retrospective Meetings?
If your retrospectives fall into one of the mistake patterns mentioned above, don’t despair. You can improve by diagnosing the problem and implementing solutions. Start by holding a retrospective about your retrospectives.
In this session, get input from the team on how the meetings could improve, as well as action steps to achieve those improvements. Another way to diagnose any issues is to join your team’s retrospective as an observer and assign someone else to facilitate. From this new perspective, see if any problems become evident to you.
If your meetings are dull, consider varying the activities, trying a new facilitator or location, and incorporating fun games and themes. You can also ask team members to vote on discussion topics and activities.
For teams that struggle with candor, explore ways to improve the sense of safety. Try activities that strengthen listening skills and encourage participation from people who tend to hold back. These strategies can be helpful.
You can make retrospectives more effective by holding them consistently, setting aside an appropriate amount of time, rightsizing your list of action items, and following through on those items.
Get detailed guidance on making your retrospectives better with these tips for improving your sprint retrospective and preventing boredom.
History of Retrospectives
The Agile practice of holding retrospectives flowed from the Agile Manifesto, developed in 2001 by a group of developers, practitioners, and leaders of different software frameworks.
The Agile Manifesto’s 12th principle provides the reasoning behind retrospectives: A team needs to reflect regularly on how to become more effective and then adjust its process accordingly.
According to the Agile Alliance, this idea of reflecting on an increment of work first appeared in 1997, in U.S. computer scientist Alistair Cockburn’s book Surviving Object-Oriented Projects. He summarized the process this way: “Work in increments. Focus after each.” Cockburn’s informal description of this practice would soon evolve into the term retrospective.
According to the Agile Alliance, project and iteration retrospectives started to become common around 2003. The publication of the seminal book Agile Retrospectives in 2006 codified retrospective practices.
The first edition of the Scrum Guide in 2010 described sprint retrospectives and made them a fixture among Scrum practitioners, thus widening the practice’s user base. (Scrum is one of the most popular Agile methodologies.) In subsequent editions, the guide has refined the roles and processes of retrospectives.
By the early 2010s, the success of Agile methods in software development motivated other industries — including media, auto manufacturing, marketing, and human resources — to adopt this approach. As these businesses embraced Agile, project teams in non-technical fields started making retrospectives a regular part of their practices.
Improve Your Agile Retrospectives for Projects and Sprints with Smartsheet
From simple task management and project planning to complex resource and portfolio management, Smartsheet helps you improve collaboration and increase work velocity -- empowering you to get more done. The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.