What is a Retrospective? It is a moment for the team to stop, breathe, and take a quick break from the day-to-day execution of the project and reflect for the sake of improvement.

Why? The goal is to discuss what has gone well up to that point in time and what has not gone well and then set a plan on how to improve.

When? A retrospective is typically run at the end of each sprint with your team and client stakeholders. Well-run and consistent retrospectives provide an incremental opportunity for small improvements. This can be something you do as a development team (without the client) but we recommend doing this with the client as part of the sprint wrap-up before moving on to the next sprint. NOTE: Agile retrospectives can and should be run as a wider project-level too when all sprints are wrapped up or the timeline of the project has come to an end. This allows you to gain over project learnings to carry forward to your next project.

The key to a well-run retrospective:

Assume a positive mindset and outlook. Regardless of what you discover, it's important to assume that everyone did the best job they could on the past sprint, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. Remind participants at the start of every retrospective this is not to blame and shame. It’s about understanding what happened in the course of the last iteration. The focus is on events and not the people.
Follow a clear/simple agenda
1. Draw the headings "What did we do well?" and "What should have we done better?" up on the whiteboard.
2. Overall, look at what happened in the last sprint (or at the project overall if you're doing a project retrospective). Did you deploy 100% of the scope, on time?
3. + Capture what would like to celebrate or point out as a positive. Each individual of the team can write down 1 or more items on post-it notes (1 point per post-it) and then a facilitator can post them on the board. Group duplicates together. You can make the writing portion anonymous if need be. After all the points are posted, discuss as a group.
4. - Capture what areas need improvement. Each individual of the team can write down 1 or more items on post-it notes (1 point per post-it) and then a facilitator can post them on the board. Group duplicates together. You can make the writing portion anonymous if need be. After all the points are posted, discuss as a group.
5. Lastly, discuss and write down what the team should do differently in the upcoming sprint or in future projects. Make sure to capture concrete actions can the team take to improve those things and assign owners to tasks if needed for accountability.
At the end of the sprint retrospective, document key takeaways to review at the next sprint retrospective.

Also at each retrospective, you likely will need to review the following:

Risk Analysis & Management - Review the project risk level identified in the risk analysis. Reevaluate each risk to see if it's still as risk or if any category has changed. Note if the project risk overall is decreased (i.e. your risk mitigation is working) if the risk is increasing. Either way, ensure you manage risk continuously and check in with it at least weekly.
Schedule check-in - Confirm how your progress is matching up against your plan. Are you staying on track with planned % complete?
Review scope priorities - Before you jump into your next sprint, confirm that the next user stories in your backlog are indeed the ones you want to work on. It's possible that other higher priority user stories have been created or existing ones have increased in feasibility and/or value. After you select the next user stories, decide if you are only working on the "Must Have" features or if you'll be including "Should Haves" or "Could Haves". Don't forget to revisit the features labeled as "Won't Haves" to ensure you're on the same page with your client.

For additional resources check out Atlassian's Team Playbook on Agile's Retrospectives