3 Retrospective Formats for Engineering Managers

The release went out on Friday.

There was a difficult merge, a flaky test that needed another rerun, and a deployment that kept two engineers online longer than expected. By Monday, the dashboard was green again.

Then someone opened the sprint retrospective.

“What went well?”

A few cards appeared. Good teamwork. Helpful code reviews. Successful release.

“What could improve?”

The answers felt familiar: clearer requirements, faster reviews, fewer last-minute changes.

Everyone agreed. Someone wrote “improve communication.” The meeting ended.

Two weeks later, the same cards came back.

For an engineering manager, this is frustrating. People are sharing feedback, but everyday work barely changes. For a Scrum Master, it raises a useful question: are we helping the team explore the problem deeply enough to do something about it?

A retrospective format cannot fix every team problem. But the right prompts can help people move beyond familiar answers.

These three retrospective formats are useful starting points for engineering teams. Each supports a different conversation, with examples of how to turn that conversation into a practical next step.

Which retrospective format should you choose?

Start with what your team needs to understand.

You can explore all three in letRetro’s collection of sprint retrospective templates.

There is no need to change formats every sprint. Keep one while it produces useful conversations, then try another when the team needs a different perspective.

1. Start, Stop, Continue: Turn familiar feedback into specific changes

Imagine a team that regularly finishes development but struggles to get changes reviewed before the sprint ends.

During the retrospective, someone writes:

“Code reviews are slow.”

Everyone recognises the problem. A few people suggest sending more reminders. Someone volunteers to check the review queue.

But why are reviews waiting?

Perhaps one engineer is the only person comfortable reviewing a service. Perhaps pull requests are too large. Perhaps reviewers spend their afternoons handling support requests.

The Start, Stop, Continue retrospective gives the team three practical prompts:

• Start: What should we begin doing?
• Stop: What is creating friction or unnecessary work?
• Continue: What is helping us and deserves to stay?

An example from an engineering sprint

The cards might look like this:

• Start: Flag pull requests that have been waiting since the previous working day.
• Stop: Include unrelated refactoring in already large feature pull requests.
• Continue: Pair on changes that touch authentication or payments.

These suggestions give the team something concrete to examine.

From an engineer’s perspective, the conversation connects to daily work. From a Scrum Master’s perspective, there is a clearer path towards a small experiment.

The engineering manager can help uncover constraints and make room for the agreed change.

How to facilitate it

Give everyone a few quiet minutes to write before opening the discussion. Ask for examples from the sprint, group related cards, and choose one or two changes to explore.

Turn “review faster” into an agreement such as:

For the next sprint, we will flag pull requests waiting longer than one working day during the daily check-in.

Assign someone to help the team follow through, and agree on when to review the experiment.

That person does not become responsible for every delayed review. Their role is to keep the agreement visible.

What to watch out for

“Communicate better” is difficult to practise or evaluate.

“Record changes to acceptance criteria on the ticket before development continues” gives people a shared behaviour to try.

Use the Start, Stop, Continue template when the team understands the problem reasonably well and needs help deciding what to do next.

2. The 4Ls: Understand the experience behind the delivery

Sometimes the sprint looks healthy from the outside.

The planned work shipped. There were no major incidents. Stakeholders were happy.

Yet the team sounds exhausted.

One engineer spent evenings learning an unfamiliar service. Another kept switching between feature work and production support. A new teammate stayed quiet because they did not know where to ask questions.

A conversation focused only on completed work can miss these details.

The 4Ls retrospective template creates space for four kinds of reflection:

• Liked: What worked well or made the sprint enjoyable?
• Learned: What did we discover?
• Lacked: What information, support, or resources were missing?
• Longed for: What would make future sprints better?

An example after a demanding release

An engineering team might add these cards:

• Liked: Pairing helped us understand the migration before making changes.
• Learned: Our staging environment behaves differently from production under load.
• Lacked: Clear ownership for incoming support requests.
• Longed for: A reliable local setup that new teammates can run without help.

Together, these cards tell a richer story than “the migration shipped.”

They reveal which practices helped, where knowledge grew, and what made the work unnecessarily difficult.

“Lacked” and “Longed for” may overlap, so explain the difference simply: what was missing during this sprint, and what would we like to make possible in the future?

How to facilitate it

Encourage specific situations and let participants choose how much personal detail to share.

As an engineering manager, resist the urge to explain every uncomfortable card immediately. An explanation offered too early can close a conversation before the team understands it.

Try asking:

“Can you walk us through a moment when this became difficult?”

Then listen for connections.

If several people mention interruptions, investigate how support work enters the sprint. If onboarding keeps appearing, explore whether the team needs documentation, pairing time, or a simpler development setup.

Turn reflection into a manageable change

Suppose scattered setup instructions are a recurring problem.

A useful action could be:

One engineer and the newest teammate will update the setup guide together, then test it from a clean environment.

That is small enough to attempt and specific enough to review.

Use 4Ls after a demanding release, a team change, or a sprint that involved significant learning. It helps make the effort behind delivery visible.

3. Sailboat: Explore blockers, dependencies, and upcoming risks

Now imagine a different sprint.

The team improved its reviews and clarified its tickets. Work still stalled.

An external API changed unexpectedly. Another team could not provide a test environment. A release approval arrived after the deployment window.

The frustration is real, but “we need to plan better” does not explain what should happen next.

The Sailboat retrospective helps the team map its situation through three prompts:

• Wind: What is helping us move forward?
• Anchors: What is slowing us down today?
• Rocks: What risks can we see ahead?

Before adding cards, agree on the destination: the outcome the team is trying to reach.

An example from a checkout team

The destination might be:

“Release the payment update with confidence.”

The board could then include:

• Wind: Useful monitoring and close collaboration with support.
• Anchors: Limited access to the payment provider’s test environment.
• Rocks: An upcoming API change with an unclear migration timeline.

This separates current friction from future risk and gives the conversation a shared direction.

How to facilitate it

Keep the destination specific enough that people can relate their cards to it.

Once the board is filled, discuss which issues the team can change directly and which require coordination.

This is where an engineering manager can help: clarify ownership, arrange a conversation with another team, or escalate a dependency with evidence.

The Scrum Master can help the group keep the discussion focused on useful next moves.

Leave with an action someone can take

For the test-environment blocker, the agreement might be:

Before sprint planning, the engineering manager will confirm test access with the provider and share the available options with the team.

The dependency may remain, but the team will have better information for its next decision.

Use the Sailboat template when external dependencies, technical constraints, or upcoming risks are shaping the sprint.

What makes these retrospective formats work?

The format opens the conversation. What happens around it determines whether the team sees a difference.

Give people time to think

Start with quiet writing. This gives everyone a chance to form their thoughts before the quickest or most senior voice shapes the discussion.

If you are the engineering manager, consider sharing your interpretation after others have contributed.

Explore the conditions behind the problem

When someone says testing happened too late, ask what led to that situation.

Were requirements changing? Was the environment unavailable? Did the work arrive in one large batch?

The answer should guide the action.

Make room for the improvement

An action needs time as well as an owner.

If the team agrees to repair a flaky test suite but plans no capacity for it, the retrospective has created another promise competing with delivery.

Discuss that trade-off before closing the meeting.

Revisit the previous agreement

Open the next retrospective by checking the last experiment.

Did the team try it? Did it help? Should it continue, change, or stop?

Even an experiment that did not help gives the team useful information. The important part is returning to it.

Bring your next retrospective into letRetro

The next time your team says “we should improve this,” pause before moving to the next card.

What will you try? Who will help it happen? When will you check whether it worked?

Choose Start, Stop, Continue for practical changes, 4Ls to understand the experience behind delivery, or Sailboat to explore blockers and risks.

If your team needs a different conversation, browse the full collection of retrospective templates for your next sprint.

Start with one useful conversation. Leave with one change your team has the time and support to try.