Sprint retrospective

What is a sprint retrospective?

The sprint retrospective is the meeting at the end of a sprint where the team looks at how it worked, not what it built, and decides what to change. It's one of Scrum's most useful events because it turns improvement into a scheduled habit instead of something that only happens after a project goes badly wrong.

Most retros run on three questions: what went well, what didn't, what should change. The team picks a few concrete improvements and carries them into the next sprint. A team that keeps tripping over slow code reviews might agree to a two-hour review SLA and check whether it held by the next retro. Small adjustments, made often, compound over a project in a way that an end-of-project postmortem never can.

The retrospective is the process counterpart to the sprint review, which looks at the product. None of it works without psychological safety. People have to name what's broken without fear of blame, because a retro where nobody says the uncomfortable thing is just a calendar event.

Retrospectives at Dallonses

We run retros that change how the next sprint actually goes, not ones that produce a tidy list nobody reads. Every retro ends with a small number of changes we own, and the next one opens by checking whether they stuck. If a fix didn't work, we say so and try something else.

We keep clients in the loop on what comes out of them, because process problems are often shared ones. A retro that surfaces a slow approval chain on the client side is worth more honestly raised than quietly absorbed. That candour is part of how a partnership stays a partnership instead of drifting into a vendor relationship.

Want a team that gets sharper every sprint instead of repeating the same mistakes? Let's build one.

Talk to us about how we work