Components of a Great Sprint Retrospective

Greg Thomas
5 min readMay 1

--

There are lots of ways to do Sprint Retrospectives (I still like the old Post-Mortem name myself) — what did you learn, what did we do well, what should we do in the next sprint — or there is also the 3L what did we Love, what did we learn, what do we Lack?

Whichever model you subscribe to, they all follow the same pattern— look at what you did, decide whether you should change anything, and apply those changes.

Unfortunately, none of those structures make for a good sprint retro, let alone a great one. They structure the discussion but they don’t ensure that it generates any value to the team and that is the number one goal of any activity in your software delivery practice — do things that generate value.

A Great Sprint Retro is one that the team wants to have, is there to discuss, and the team doesn’t want to see it drop off their calendar.

Instead of focusing on the structure, what we need to focus on are the behaviours we want to see each and every time — Honesty, Trust, and Humility.

That’s it — if I could make it into a cool acronym, I would, but I can’t (HTH sounds like I’m spitting it out).

Think back to when you did your first Sprint Retro it was probably your longest one as the team “figured it all out” and got all that structure stuff sorted out to be more efficient. But this is wrong, the reason it was so long was that you had a bunch of stuff inside of you that was itching to get out and as you went around the room everyone realized they had the same itches and wanted to get them all out. This got the ball rolling and you kept going deeper and deeper.

Honesty

If something went wrong, you need to say it. If you were assigned a bug and had to spend 2 hours looking for the issue because someone was too lazy to assign the logs, you need to stay it. Saying — “we need to ensure all information related to a bug is associated with the bug” — is a get-out-of-jail card for the person who was lazy. Saying — “we need logs attached to bugs, otherwise they go back to the person who raised them” — raises an issue and action.

Taking honesty a step further, you can use people’s names in your Retros — “I had no idea what to do on that task because

--

--

Greg Thomas

Software Architect, Developer, Author and Leader helping organizations build scalable software delivery teams and implement cloud-based solutions

Recommended from Medium

Lists