Alright, Scrum Masters, it’s that time again.
The end of the sprint is near, and you’re about to shepherd your team into the sacred space of the retrospective.
No pressure, right? You just need to find a way to get your team to open up, reflect on what went well (and what went spectacularly wrong), and come up with actionable improvements — all while keeping the energy high and the post-it notes flowing.
It’s not a dinner party, but it sure feels like a recipe for success.
But before we throw ourselves into the retro recipe, let’s talk a bit about why most devs hate retro’s.
Why Do Most People Hate Retrospectives? (Or why retros might feel like a bad therapy session)
Have you ever heard at least one of these questions:
– Can we skip the retro this sprint?
– Can we postpone our retro?
– Can we do retros less often?
– Got a lot on my plate today. Can I skip the retro?
– Why do we even have retros?
If you’ve worked with Scrum teams before, I can bet you came across most of these at least once.
Or maybe you’ve been living in a bubble and your team is perfect — in which case, does your company hire? (Asking for a friend.)
Out there in the wild wild west of the corporate world, these questions often come from developers.
Why — you may ask yourself?
Just imagine this: You’ve been a PM for a while and you have a certain flow that you’ve developed over the years.
You re-use your templates, because let’s be honest, you’ve developed them to perfection. And you’ve got a clear-cut agenda, always using the same dynamics.
Take a wild guess at how your developers feel about it…the same old retro, nothing changes.
1. Same old Retro
Now, I’m not saying don’t use templates or processes based on your past experience, but maybe, just maybe, try to switch it up from time to time.
Maybe start with the same questions, but add a surprising element.
Gotta keep those developers on their toes, right?
Having the same mechanical retro each time is what’s draining your team of energy and no one wants to work with robots.
Here’s a thought — ever considered having someone else facilitate? Taking turns within the team to facilitate lets people walk a mile in your shoes and discover just how painful it might be to try to keep a meeting on track.
And let’s be honest, sharing is caring 😈
2. Outside factors
So, you had a good retro and identified some pain points. What do you do if those pain points are not within your realm of control?
Let me walk you through a recent experience I had.
For several retros in a row, the team brought up the same pain point about one of the other squads blocking us from shipping our features.
The other squad was the owner of the main backend service and as you can imagine, having a dependency on another squad when you’re trying to ship features fast is not ideal.
Now, this being a separate team means it’s outside our realm of control. Sure, we could try to influence, but it doesn’t guarantee the change we need.
So, what I did instead, was steer the focus into defining actions that were within the team’s realm of control.
In this specific scenario, we needed to identify any dependency early on in the process so that we could create visibility over those dependencies.
Was this the end all be all? No, it sparked into several workshops with other squads and several process improvement initiatives and it shifted the team’s focus on what they could control.
3. Lack of follow-through
A good retro is usually the kind of retro leaving you with solid actions that the team agreed upon. Obviously, right?
As easy as it may sound, let’s not forget we don’t all live in the land of unicorns and in real life, things can get missed along the way.
More often than not, you’ve got the defined actions that get ignored during the sprint because the team never got around to them.
Whether the actions were defined poorly or just forgotten about, most teams simply fail in taking the first step to act in any of them.
Actions are the lifeblood of retrospectives — without them, you’re just hosting a recurring vent session.
Craft actions that actually matter, carve out time during the Sprint to tackle them, and steer the chaos in each retro like a seasoned pirate.
If you don’t bother checking whether those actions made a dent, your team will keep treating retros like a pointless group therapy session… but with fewer snacks.
Developers don’t despise retrospectives — they despise bad retrospectives. No one wants to endure an endless loop of pointless meetings that feel like purgatory with Post-its.
If your team starts ghosting retros or suddenly develops a mysterious “Wi-Fi issue,” that’s your cue: something’s broken, and it’s not just their spirits.
Now, let’s talk about the actual recipe for a good retrospective.
Ingredients for the Perfect Retrospective
Before we get to the method, let’s talk ingredients. You need a few basic things to set the stage:
- Time: Depending on the sprint length, you’ll need anywhere from 30 to 90 minutes. It’s like cooking a steak — too short and it’s undercooked; too long, and no one’s sticking around.
- Team members: You can’t have a retrospective with just you and the Product Owner. Involve the team, everyone has their own flavor to add.
- A good facilitator: That’s you, by the way. You’re the one setting the vibe, keeping things on track, and maybe even throwing in a few surprises (without being the surprise).
- Some tools: Whiteboard, Miro, Jira, or just a good old-fashioned set of sticky notes and markers. Whatever you have lying around, just make sure it’s functional.
- A healthy dose of honesty: Be prepared for some uncomfortable moments, because you’re about to dig into what didn’t work. It’s fine, though — this is where the magic happens.
The Retro Method: A Simple, Yet Effective Recipe
You’re the chef. Here’s your step-by-step guide to making a Scrum retrospective meal that will leave your team hungry for more (feedback, that is).
Step 1: Set the Mood — No One Likes Cold Soup
First, start by establishing the why of the retrospective. It’s not just a routine meeting to tick off your checklist.
It’s an opportunity to grow as a team and improve the process. Let everyone know they’re in a safe space to share honestly. No judgment. Only improvement.
Then, get the ball rolling with a warm-up. Something light-hearted, like a quick check-in question. Example: “If you were a superhero, what would your power be?” Sounds cheesy? It is. But it also works.
It gets everyone comfortable and feeling a little more open. You could also try a mood-check with an emoji or gif to get people in the zone.
It’s like the appetizer before the main course.
Step 2: Gather the Ingredients — What Worked, What Didn’t
This is where the magic happens. Give everyone some time to think and jot down their thoughts. You’re looking for three things:
- What went well: These are the ingredients that made your sprint shine. What did your team nail? What worked smoothly? Write it down on a sticky note (or digital equivalent).
- What didn’t go well: This is your time to vent (constructively). What needs fixing? Where did the process break down? It’s okay to be honest, but also keep it respectful. We’re all about improvement, not finger-pointing.
- What can we improve: This is the secret sauce. Here, you focus on actionable improvements for the next sprint. What small change can make a big difference?
Step 3: Cook the Recipe Together — Discuss and Prioritize
Once everyone has their notes, it’s time to cook up some solutions together. In this phase, don’t just stand there reading what everyone wrote.
Encourage discussion. Ask probing questions like, “Why did this go well?” or “What can we do differently to make sure this doesn’t happen again?”
As you discuss, prioritize the actions.
You’ll never solve everything in one sprint, but you can pick 1–2 key improvements to focus on.
Anything more is just overwhelm with a side of burnout.
Step 4: Season to Taste — Add Action Items
Now that you’ve discussed and prioritized, it’s time to season the recipe with actionable items.
What are your team going to do differently next sprint?
Assign owners to tasks and set clear deadlines.
It’s like adding the finishing touches to your dish — make sure everything’s well-seasoned with clear goals.
Step 5: Wrap It Up — No One Likes Cold Leftovers
You don’t want to linger too long on the retrospective.
The action items are set, the discussion’s been had, and the team feels heard. Finish up by summarizing key takeaways and thanking everyone for their honesty and time.
Leave your team feeling energized and ready to dive into the next sprint with a fresh mindset.
Why This Retrospective Recipe Works
This approach is effective and here’s why: It balances the importance of reflection and actionable improvements while keeping the mood light.
No one’s getting stuck in process bureaucracy or debating semantics. Plus, the feedback loop is open, and your team is engaged.
When you run retrospectives like this, you turn them from an obligatory meeting into something that your team genuinely looks forward to.
So, next time you find yourself cooking up a Scrum retrospective, remember: a pinch of honesty, a dash of humor, and a whole lot of collaboration will serve you (and your team) up a plate of success every time. Enjoy!
🔥If you liked this article, check out the next one where we walk through 10 essential Agile metrics every team should track.
Written by
Simina F.
| howtobecomeapm.com – Author
|