Sprint Retrospective is far and away the most important event in Scrum, if not for all Agile practitioners. Although empirical process control is omnipresent in Scrum, nowhere is it better represented than at the Retrospective. Put another way, I still envision a team being highly successful even after they have jettisoned every other role, artifact, and event as long as they are still doing Retrospectives. This is because a team can experiment with changes to roles, artifacts, and events—not to mention plenty of other factors—using Retrospectives. If the team decides during a retrospective to reduce the time spent doing Backlog Refinement by 50% and they’re still genuinely happy with that choice two sprints later, who’s to say they shouldn’t make that change?

So how can we conduct our first retrospective? Personally, I’m a huge fan of the five-step retrospective popularized by Esther Derby and Diana Larsen, authors of the book “Agile Retrospectives: Making Good Teams Great.” Retrospectives can get stale really quickly, so teams find it helpful to change how they do retrospectives often. So long as your retrospective covers the following five steps, you’re in good hands!

Step 1 is “Set the stage.” This is a good chance to break the ice and with your team and remind ourselves why this is so important. I have a few activities I like for this step and I’d recommend choosing two of them. First, I’d suggest reading Norm Kerth’s Retrospective Prime Directive as a team, which is: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” This helps to create a collaborative environment for learning and continuous improvement instead of blaming individuals. Second, I like to ask each team member to share just one word about how the retrospective went for them. This will give everyone a good sense of the mood in the room. Third, I like to invite team members to share a genuine word of specific appreciation for another member of the team.

Step 2 is to “gather data.” What happened in the sprint? I like to use a “positives / deltas / insights” collection device. Ask each team member to come up with as many positives, deltas or things they’d like to change, and insights as possible. Have them write each positive, delta, and insight individually on sticky notes or their digital equivalent. When the team has run out of thoughts or the timebox has elapsed, place the sticky notes on the wall and group like items together.

Step 3 is to “Generate insights.” I like to add a brief intermediary step, which is to choose the top positives, deltas, and/or insights that we’d like to focus on, about 1-3 total. Once you have the top 1-3 items, dig in more on each one. The book “Agile Retrospectives” has a good activity called “Prioritize with Dots” that can make this go faster. If a positive reads “The team is doing a good job of collaborating with one another” and a delta reads “Our staging server keeps going down,” try to understand the root cause of these conditions. Some teams find it helpful to ask “why” five times (give or take) until you get to your root cause. Agile Retrospectives suggests other exercises as well. As a hint: if you’re rarely surprised by your root causes, you may not be digging deep enough.

Step 4 is all about “Actions.” I like to expand this into Decisions and Actions. For each item, discuss as a team suggestions about how you can persist and deepen the positive, change or minimize the delta, and capitalize on the insight. You’ll find that your suggestions fall naturally into two buckets: decisions, which are changes to the Working Agreement, and actions, which are simply new backlog items. Suppose that the team is tired of events starting late due to tardiness. The team could vote to add a rule to their working agreement that imposes a penalty for being late. Or suppose the team discovers that their staging server needs several hours of maintenance. The team could decide to add a user story to the backlog that reads, “As a developer, I have a more reliable staging server so that I can develop software more effectively.” Try to stay focused here: it’s better to have one or two improvement items for the next iteration than to have too much to change at once.

Step 5 is “Wrap up.” If you haven’t done a round of appreciations yet, this is a nice time. Spend a few minutes retrospecting on the retrospective. How did it go for the team? What would they like to try next time?

Your team should run a retrospective at the end of every sprint. If your team is doing Kanban or one-week sprints, it’s perfectly reasonable to do a retrospective every two weeks. It can also be useful to hold a retrospective at the end of any significant event, such as a multi-team release planning, a large release, or following an incident. If you’re retrospecting an outage or incident, don’t call this event a “post-mortem.” This makes the event a little too negative in conception, subtly implying the team killed someone or something. Instead just use Retrospective or the military term “After-action review.”

So that’s a reasonable retrospective that you can use for your first several sprints. Talk to your team’s Agile Coach for more ideas on how to keep your retrospective fresh and interesting.