8 Tips For Running a Simple Sprint Retro

A few weeks ago, we kicked off a new Android project when the discussion came up regarding the ceremonies we wanted to hold, and how much time we wanted to spend on them. I was surprised that everyone on the team wasn’t as stoked as I was to hold a one-hour sprint retrospective (or ‘retro’).

The sprint retro is one of the most powerful Scrum tools in your kit, not just for your team, but for your organization.

Below are eight tips on how to run simple sprint retros with huge ROIs.

1. Internal team members only

In the professional services arena, we may have our client, the end users, our client’s client, and other vendors all working on the same project. It can get complex, so keep it simple. Only invite collocated internal team members. A majority of communication is nonverbal, so getting folks in a room helps generate honest feedback and a feeling of safety.

2. No, the boss cannot come

Despite it looking like a great opportunity to listen to feedback and see how things are going, bosses bring with them something that’s deadly to a retro: the invisible gun effect. Simply put, the threat of retribution for honest feedback stifles the room of game-changing feedback. Stuff like “If [boss-name] would just stop writing our AC, I could actually finish a story” will rarely come out with your boss sitting behind you.

3. There’s really only three questions

Time to ditch those 40 question, 5 subsection, post-mortem templates. Just get these three questions on the table and you’ll be mining the most gold in the room in regards to feedback.

  • What went well?
  • What didn’t go well?
  • What can we improve?

Every answer is important; document it all.

4. Pick one thing to improve

After discussing the final question, run the list and vote (as a team) for the item you want to commit to improve by the end of the next sprint. Like large user stories, if the item for improvement cannot be completed within the following sprint you’ll have to break it down into smaller pieces. The goal is to complete what you’ve committed to.  

5. Make a commitment (easy right?)

Commit as a team to improving that one thing. This means everyone in the room needs to provide a vocal ‘Yes’ when the ScrumMaster asks the question ‘Are we all committed to improving this [name the thing].’ If someone doesn’t say ‘Yes,’ politely check with them that they are onboard with the team’s decision to improve this one thing. Just like with story pointing, if someone doesn’t agree, discuss it until consensus is reached.

6. A Leader Emerges…hopefully

Ask for a volunteer to lead the charge on this commitment. It shouldn’t always fall to the ScrumMaster or Senior Developers. While the whole team is responsible for improving in this one area, the leader is held accountable to getting it done. This is a great opportunity for someone on the team to show their capacity for leveling up in the organization. If your boss is interested in identifying some rising stars, have them pay attention to this person and how they handle leadership that sprint.

7. Pitfalls; don’t do these things

  • With new scrum teams, don’t try and take on more than one item per sprint for improvement. Often, this amounts to the items being half done, which is the same as nothing being done. Just get one thing done the right way. As your team becomes more veteran you might experiment with two or more items. The minute something isn’t finished though, move back to one item a sprint.
  • Don’t allow folks who aren’t on the team. They just clutter up the space and could add a feeling of unsafety.
  • Don’t write who said what in your notes; you’re not taking minutes. This way your boss can read the notes while protecting the team.

8. Doing the math

Let’s say you have a 3-month roadmap, built on 1-week sprints, and run 12 sprints. If your organization has 4 project teams running concurrently during that period, you could see up to 48 improvements implemented.

If just 10% of these impact the organization as a whole, you could see 1-2 improvements a month, driven and owned by project staff. Improvements which could lead to new innovations, organizational efficiency gains, or just good discussions about what might need to change in your organization soon.

The other 90% will inevitably help project teams grow together, get better at their jobs, and produce higher quality products.
For more information on sprint retro’s check out scrumalliance.org

6