The project wrap-up retrospective
Look back on a finished project: the goals you met, what slowed you down, what you learned, and who deserves credit for it.
Project Wrap-up is a retrospective for the end of a project. It asks what you achieved, what got in the way, what you know now, and who deserves thanks. That last column sets it apart: a long project leaves a lot of quiet effort behind it, and the wrap-up is the last good chance to name it.
It looks back over months, often right before the team moves on, so its lessons are for the next project rather than the next sprint.
The four columns
- Goals met: What did we accomplish? Measure against what you set out to do: "Moved every customer to the new billing system." Include goals you partly met, and say so.
- Friction points: What slowed us down or got in the way? Name the obstacle and its cost: "Waited three weeks for access to the staging database."
- Lessons learned: What do we know now that we didn't before? Write for someone starting a similar project: "Get the export from the old system in week one. It was the riskiest part."
- Shout-outs: Who went above and beyond? Name the person and the specific thing: "Priya wrote the test data generator that saved everyone hours." Specific thanks mean more than "great job, everyone."
When to use it
Use it at the end of a project, a major release, a contract or a phase of work, especially when the team is about to split up. Run it for cancelled projects too.
If you want to measure the result against a written plan, Plan vs. Actual asks why the two differ. If you want people to reflect on their own experience, try the 4 Ls. On launch day itself, use Quick Review, and hold the wrap-up later.
How to run it
- Set the stage (5 minutes). Recap the project's goals, dates and people. Invite people who left partway through; they remember the start best.
- Write alone (10 minutes). Everyone writes cards in all four columns, including at least one shout-out each.
- Group (5 to 10 minutes). Friction points usually group by theme, such as access, decisions or changes of scope. Group the lessons the same way.
- Vote (3 minutes). Spend votes on friction points and lessons. Goals and shout-outs don't need ranking.
- Discuss (20 minutes). Spend a few minutes on the goals met, then take the top friction points and lessons. For each friction point, ask what the next project should do from day one.
- Agree actions (5 to 10 minutes). These are often about passing lessons on: who writes them up, and who receives them. Give each an owner and a due date.
- Close (5 minutes). Read the shout-outs aloud. It ends a long piece of work on the right note.
Tips
- Write lessons for strangers. "Ask for database access in the first week" helps the next team. "Access was a pain" doesn't.
- Keep friction about the work. "Approvals took two weeks" leads somewhere. "Sam was slow to approve" doesn't.
- Look for the work that's easy to miss. Documentation, reviews, support questions, the person who kept the calendar straight. Prompt for these before people write.
Run it in Scrums
Choose New session → Retrospective on your team's page and pick Project Wrap-up from the formats. Everyone writes privately, and other people's cards stay face-down until the facilitator reveals them, so nobody's first card sets the tone. Then group similar cards (or let Auto-group cluster them), vote with hidden tallies, and discuss the topics in order, adding action items with an owner and a due date. Open action items come back in the next retro's Review step. Retros are anonymous by default, and Scrums is free.
Try a retro in your browser, or sign up free.
Questions
What's the difference between a project retrospective and a sprint retrospective?
A sprint retro looks at the last week or two and changes how the same team works next sprint. A project retrospective looks at months of work, often as the team moves on, so its lessons are for whoever runs the next project.
Should we hold a wrap-up for a cancelled project?
Yes. A cancelled project often teaches more than a finished one, and the people who worked on it deserve recognition. Focus on what the team would do differently next time, not on whether the project should have been cancelled.