Skip to content
Try Scrumling for Employers
Scrum in real teams

Our Retrospectives change nothing

Short answer: a Retrospective that produces discussion but no change is usually missing one of three things: an owner, a place in the next Sprint Backlog, or the authority to fix what was raised.

The Scrum Guide asks the team to identify the most helpful changes and to address them as soon as possible, including by adding them to the Sprint Backlog. Most struggling Retrospectives skip that last part, which is why the same items reappear month after month.

Stop leaving with five improvements

Five improvements is zero improvements. A team that leaves with one specific change, owned by a named person and sized to fit inside the next Sprint, will make more progress in a quarter than a team that generates twenty ideas and completes none.

Pick the change with the shortest distance between action and effect. 'Improve communication' has no distance you can measure. 'Move refinement to Wednesday so items are ready before planning' either happens or it does not.

  • One change per Retrospective, written as an action with a name attached
  • Put it in the Sprint Backlog, not in a separate document
  • Check it at the start of the next Retrospective before anything new is raised

Separate what the team can change from what it cannot

Teams lose energy when every Retrospective circles the same problem that sits outside their control, such as a shared dependency team or a hiring freeze. Splitting the board into 'ours to change' and 'ours to escalate' keeps the first list actionable and gives the Scrum Master a concrete list to take to the organisation.

Escalation is real work with a real owner and a date. If it never leaves the room, the team learns that raising things is pointless, and the Retrospective quietly turns into a complaint session or, worse, silence.

Watch for the safety problem underneath

Sometimes the Retrospective is not failing to produce change; it is failing to surface the real issue. If the difficult topic only comes up in private conversations afterwards, no format will fix it. Smaller groups, anonymous input beforehand or a manager stepping out for one session are blunt tools, and they often work.

This is also where an outside read helps. A structured, anonymous team assessment surfaces the gap between what people say in the room and what they actually experience, which is exactly the material a Retrospective cannot generate about itself.

Vary the question, not just the format

Rotating between sailboat, starfish and four-Ls changes the decoration, not the thinking. Changing the question changes the thinking. Ask what slowed us down most this Sprint, or what we would warn a new joiner about, or which handover cost us the most waiting time. Specific questions produce specific answers, which produce changes you can actually make.

Not sure which of these is actually happening in your team?

The team assessment asks everyone the same questions anonymously and shows you where people disagree about how the team really works. It takes about twelve minutes per person.

Run a team assessment

Frequently asked questions

How long should a Sprint Retrospective be?

The Scrum Guide caps it at three hours for a one-month Sprint, so roughly ninety minutes for a two-week Sprint. Many teams finish sooner, and a shorter Retrospective that produces one real change beats a long one that produces a list.

Should the manager attend the Retrospective?

It is a Scrum Team event. If a manager's presence stops people speaking freely, that is your answer. If the team genuinely wants them there for a specific topic, invite them for that part.

What do we do when the same issue comes up every time?

Check whether it is inside the team's control. If it is, the action was probably too vague or never entered the Sprint Backlog. If it is not, it needs an owner outside the team and a date, otherwise it will keep returning.

Can we skip a Retrospective when the Sprint went well?

Skipping it removes the one event that improves how the team works. A good Sprint is a cheap time to examine what made it good, which is far easier than diagnosing a bad one.

Learn Scrum by playing, not by reading slides.

Every role, every event, every artifact, practiced under pressure in the browser. Free forever, certificate on completion.

Start the free course