One of Scrum’s most important regular rituals is the retrospective. A “sprint retro” happens at the end of each sprint and its format is typically a three-question round-robin:

• What went well this sprint?
• What didn’t go well this sprint?
• What do we want to change or start/stop doing in the future?

That works well if it happens often and the focus is on short-term process improvement in the next sprint. But at the end of a project, the focus is much wider. Repeating the same format skews the conversation toward things that happened late in the project. Further, since the format is “everyone goes around listing an observation,” the conversation stays fairly high-level instead of diving into deeper investigations.

My other problem with that retro format, generally, is that it ends on a bad note — often the “what should we change/do differently” flows from the “what didn’t go well.” My last client pointed that out when I facilitated a retro at the end of their kickoff workshop.

Four Kitchens has transitioned to using EOS® for their operations. One component of that system is a regular departmental status/planning meeting called the “Level 10™.” I propose an end-of-project retro format that adapts three things from the Level 10:

• Segue/Personal Bests — Usually used to open a Level 10, a quick shout-out of personal celebrations, in or outside of work, to shift focus out of regular operations and start the meeting with a positive tone.
• The IDS™ — “Identify, Discuss, Solve” to investigate issues, both good and bad.
• Cascading Messages — What, in EOS parlance, is a message to another level or department of the business. Usually, this is a message between teams up or down the reporting chain. (Usually, it’s an informational update, not a meaty issue, but I still like the parallel.)

In all, here’s how I’d do it in 1 hour:

1. (5-10 minutes) What went well during this project?

This is still a great way to start this conversation, but I’d timebox it without being too strict.

2a. (5 minutes) Build or review the issues list for the IDS.

What would you like to spend time talking about?

This is my replacement for “what didn’t go well,” but it can definitely include wins and positive things. Without discussing them, ask the team to list issues to talk about. It’s great if this list can be primed ahead of time and for the facilitator or a manager to come with a few issues that the business wants to be discussed.

Some broad examples, but encourage specifics:

• Over budget on X
• Issues navigating the relationship
• Poorly managed client expectations about X
• Estimation or resourcing inaccuracies
• Unexpected changes, deviations from RFP or SOW
• Tried a new method — e.g., development framework, user research method, discovery format
• Our X work was great — e.g., visual design, content strategy, a particular feature
• Project was fun to work on — to study how to repeat that success.

Build this collaboratively so that voting is easy. If the meeting is happening in person, do a post-up and dot vote. There are ways to do this in Google Docs/Sheets, Trello, or Notion.

Remember, if anyone’s remote, everyone’s remote!

2b. (5 minutes) Vote on the issues list for topics to discuss.

Allow 3-8 votes per person, depending on the size of the meeting and the list. Participants can vote more than once on a single issue.

“Put an X by stuff you want to talk about. You each get [three to eight] votes. You can spread ’em out or vote multiple times for something that is most important to you!”

Business leadership should also be allowed to appoint issues to be discussed, but ensure some team topics are represented.

3. (30 minutes) “IDS” — Identify, Discuss, Solve the selected issues.

This is my “what should we change or do differently” because the focus should be on identifying the issue (building a shared understanding) and learning from it. With the goal of solving it by arriving at “what to do next time,” it should be easier to focus on outcomes instead of assigning blame. When discussing a win/positive, focus on “what should we keep doing.” Either way, aim to distill a lesson learned from the conversation to send to the rest of the business — a “Cascading Message.”

I use the concept of a cascading message here because these insights should absolutely be heard by business leaders, managers, and other teams. This project is over and the team may be disbanding. Observations that stay within the context of this engagement may be lost.

This is the meat of the conversation. Shoot for 8-10 minutes per issue, which should allow time for about 3-4. If something is especially important or needs more time, consider spinning up a subsequent conversation about that issue specifically. If your retro is longer than an hour, use that time here, but consider the emotional labor of this exercise — it can’t go on too long.

4. (5-10 minutes) Personal Bests / Segue out.

Addressing the “don’t end on a negative” problem, pick one of these options, asking each team member to share:

• A personal best, win, or learning moment from the project
• Their favorite moment from the project
• A kudos to someone else on the team about their contribution to the project (if you pick this route, make sure it’s balanced).

5. (Optional) Wrap-up.

Consider offering up the high-level bullet points of lessons learned and who will receive them so that the team feels they were heard.

Through this format, my goal is to push the retro into being a tougher, more in-depth conversation. The reward for all involved is the promise that we won’t lose sight of what was learned during the project. That way, the business can incorporate the feedback by repeating on the wins and improving on “what to change” for next time because the next project is right around the corner.

EOS®, Level 10 Meeting™, and IDS™ are trademarks of EOS Worldwide. Please note, I have adapted them as techniques here; they are used out of context of the EOS system.