The 4 Essential Retrospective Questions That Can’t Be Skipped

When running agile retrospective meetings routinely, you might find yourself running out of prompts for helping your team to look back on a sprint or project with fresh eyes.

Which they should, to draw objective conclusions from the sprint’s results. But a question that elicits thoughtful feedback one week might bring crickets the next. How many times can you ask the same group what went well or not?

Thing is, the information you can generate from questions like this is what makes agile retrospectives worthwhile. Continual improvement demands continual reflection on your team’s processes and output. It might just be time to reflect from new angles.

Below are four retrospective questions I like to ask to get my team thinking more outside the box:

Think of these questions as cues that steer your course to improvement. Together they build a complete picture of team morale, key results and lessons learned, and any roadblocks from the last sprint that might be hindering progress.

Question #1: What’s keeping us awake at night?

Valuing individuals over processes is a key tenant of agile. Yet asking “what didn’t go well” positions company outcomes as the priority by which you measure your team’s success.

By asking what’s keeping them up instead, you place more emphasis on the mental health of the team and work backward from there.

It’s a well-worn question, but it gets at some of the most genuine aspects of team relationships and all the feels that retrospectives are designed to put on the operating table. I find it helps uncover the areas for improvement buried deep in team dynamics or distractions that sap people’s ability to think clearly or recharge away from the office. It’s one thing for employees to be alert to the needs of the company, but quite another if their concern starts to tip towards anxiety and that anxiety goes unaddressed.

Imagine a looming deadline is causing your team to toss and turn. That’s a real threat to productivity. Coffee is magical, but has its limits, and punting on the due date is not always an option. Still, you’ve identified the date as a sticking point and you know it’s not a great idea to keep the team on red alert until then.

Maybe what’s needed is to break down large tasks into smaller steps. Maybe folks can’t see the progress you’ve made already. Without asking what’s on their mind, team members won’t necessarily share concerns with those best positioned to support them.

As they do share concerns, you might end up with a list of practical issues alongside the personal. This is good. For every fear and anxiety you’ll collectively find a work-around. Just keep in mind that such solutions can be impossible to see from an individual perspective—which makes your retrospective meeting the perfect place to intercept budding worries before they grow out of control.

Question #2: What advice would you give your younger self?

If hindsight is 20/20, your team needs the chance to think about what could have been done differently. Ask folks to think back to the start of the project. What advice would they give themselves having learned what they learned from the project’s results?

This retrospective question not only unearths key insights, but it situates team members as their own champions rather than as worker bees apologizing their wings aren’t faster. Ideally, no one should feel that way in a retrospective, but rooting out inefficiencies is seldom a pleasant task. Asking the team to advise themselves retrospectively is a gentle but deliberate way to encourage folks to take ownership and prime their thoughts for root cause analysis—both critical elements of the retrospective process.

If, for example, one person points out a dead-end everyone agrees they shouldn’t have pursued, it’s a good time to assess why you went down the dead-end in the first place. What assumptions underpinned your rationale for choosing that path? Should those assumptions be revisited or proven?

The question works particularly well for tackling big-picture concerns during evaluations like postmortem analyses, but it can also be adapted for routine use. Try rephrasing it. “What did we wish we knew last week?” is a useful check-in to catch problems early. Better still, ground the question in the specifics of your team’s experience:

“Imagine we’re looking down on us sitting in this room last [sprint period]. We’ve just walked out of [manager]’s office and we’re itching to get started on [task]. There’s us just spit-balling ideas. If you could walk into that situation now, and share one kickass idea, what would it be?”

Don’t worry if the exercise begins with goofy or even off-topic responses. However you get there, just aim to uncover:

1. The obstacle
2. How it could have been avoided
3. How this intel could apply to handling similar situations in the future

Process improvement is the goal of retrospectives, and sometimes better approached from a “How did we get there?” standpoint than diving straight into “How do we get past it?” Preventing fires is easier than fighting them.

Question #3: How well did we hit our action items?

In an ideal world, retrospectives create opportunities for improvement. However complex, problems are distilled into clear action items.

But what if they aren’t followed through?

Little improves. And eventually, folks won’t see value in the meetings.

Many a great scrum master begins every retrospective with some version of this question to maintain a collective sense of accountability. Are we making useful sense of the knowledge we build in retrospectives? Is that knowledge being operationalized? How can we tell? Keeping these concerns present in everyone’s mind will head off any concerns about the utility of agile retrospectives.

And here’s a handy roadmap to take from there:

If your team is hitting on action items, again, figure out why. What relationships are working? Congratulate everyone on their communication and spend some time reflecting on why this complex task is running smoothly. Are there certain types of action items that get done with less friction? Are they best suited to certain owners and partners?

Keep an eye out for those opportunities for improvement. The professional world has its sunny days and its storms. The hard times are when it’s helpful to employ the wellsprings of collaboration your team has found success in previously.

If your team is not hitting on action items, asking why will help tease out any overlooked lack of resources, budgets, or timelines. Needless to say, there’s no better time for team members to exercise those values of ownership and accountability.

A lot of the time, though, retrospective action items fail at the source. Are the instructions too vague or generic? Have you simply set the bar too high? Is trying to do 10 things better making you worse at all of them?

To make sure your goals are manageable, make them SMART:

• Specific: they target a clear and coherent area.
• Measurable: their success or failure can be quantified.
• Achievable: they are realistic given constraints.
• Relevant: they are aligned with the bigger picture.
• Time-bound: they have reasonable deadlines.

Ensure each action item checks off every one of these qualities, and there’s no need to question whether the goal is manageable enough. If an action doesn’t meet these criteria, it’s time to return to the possibility that some workflow or someone needs support.

One final trick: visualizing these goals is another way to make them easier to manage. Use digital retrospective tools that automatically assign, track, and in some cases analyze your retro to-do lists. Apps can be wonderful tools for distributed teams that can’t share a physical whiteboard and for streamlining feedback and follow-up.

Question #4: What do we expect of each other? What is expected of the team?

Expectations are everything in agile. Usually in the context of the customer, sure, but also internally, where defining and meeting expectations or boundaries with your team is crucial to allocating energies efficiently.

In the immediate sense, folks should be aware of what they’re responsible for and what’s expected of their role.

But expectations operate at a deeper level in communities with a shared goal, right from the top down. Any misalignment—whether one person feels they can’t live up to certain standards or another expects too little or teams are siloed off from one another—promotes frustration and fear of failure. Not collaboration. Whereas clear and fair expectations alleviate some risk that goals aren’t met.

Note that expectations are fluid. There’s no avoiding it. We’re agile, but still human, and when life happens and personal commitments take priority it’s time to lower the bar. Consider onboarding as another example. New but experienced hires arrive with their own idea of how they might be expected to contribute, but those expectations evolve as:

• The teammate gets to know the team’s own processes and adjusts (or not) for the team’s expectations.
• The rest of the team adjusts its expectations of each other as the teammate fills knowledge gaps or takes off others’ plates.

When setting your expectations, allow wiggle room for changes. I hear what you’re thinking: surely lowering expectations lowers the quality of the output? Not if they’re lowered to an achievable level, going back to those SMART goals. Overstretching is what lowers quality.

But also don’t be afraid to flex those testing muscles agile teams are famous for. Use retrospective exercises like Mad, Sad, Glad as opportunities to rethink limits and figure out where exceeding them makes sense for personal or professional development.

Final thought: beware groupthink

These are questions any scrum master can ask to gather conclusive data, keep meetings fresh, and facilitate discussion when it fizzles out or veers off track.

One last tip for getting the most out of retrospective questions: Whether virtual or collocated, your team should record its answers in writing.

This is for a few reasons. For the obvious, to preserve ideas. But textualizing ideas and problems also help convey them in specific terms you can use to generate clear, relevant solutions. Written evidence also mitigates groupthink, a killer of good decision-making. If supported unanimously, ideas are more difficult for individuals to challenge even though resistance might be for the good.

So, when recorded and shared, your findings from this meeting will keep the team grounded in your rationale for the changes you implement next.