Agile software teams made retrospective meetings popular, but they're great for all teams. Here's how to run basic retrospectives, and how to adapt them to suit your team. Don't miss the real-life example retrospective notes below step 4!
AND I NEED THIS... WHY?
Ever have one of those dreams where you're running and running, but don't seem to be moving forward? It's all too easy for teams to have the same experience: making the same mistakes, doing things the way they've always done them, and working hard... but not really getting anywhere.
Executing on projects and providing services have a cyclical nature. And the teams who really excel are the teams who step outside that loop once in a while to reflect on what they've done lately and how it worked out. Armed with a lesson-learned or two, they can iterate on their processes and improve.
Retrospectives are a chance for the whole team to reflect on a project or period of work. The spirit should be of continuous improvement: a blame-free look back to capture actionable items that help everyone improve their work, their team, and working environment.
WHO SHOULD BE INVOLVED?
Include the core project or service team, and perhaps a facilitator. Stakeholders and other peripheral folks should sit these out.
4 - 8
Running the play
Project teams can run this at the end of each sprint, or go a little wider. Check in with the full-time owner to see if there are any specific items they'd like you to cover. Service teams can check in with a supervisor or director.
- Sticky notes
- Rubber chicken
Book a meeting room for at least an hour: 15 minutes to set up, 30 minutes for the session, and 15 minutes to take photos and clean up.
Come 15 minutes ahead of the rest of the team, and bring all supplies listed above. Draw the headings "What did we do well?" and "What should have we done better?" up on the whiteboard. Use the Retrospective Meeting Notes blueprint to create a new Confluence page in your project space, and use that to record the outputs of your session.
Set the stage (5 min)
Welcome everyone to the retrospective meeting and establish the rules of engagement:
- Embrace a positive spirit of continuous improvement and share whatever you think will help the team improve.
- Don't make it personal, don't take it personally.
- Listen with an open mind, and remember that everyone's experience is valid (even those you don't share).
- Set the boundary of your discussion – is it that last sprint? the last quarter? since the project started? Be clear how far back you're going to go.
Let someone other than the team lead facilitate. Sharing the facilitation around the team will keep your retrospectives fresh, encourage greater participation, and uncover more inconvenient truths.
What went well? (10 min)
Start the session on a positive note. Have each team member use green sticky notes to write down what they feel went well (one idea per sticky). As people post their stickies on the whiteboard, the facilitator should group similar or duplicate ideas together.
Discuss your ideas briefly as a team.
Discussions are dominated by one or two people.
This is a sign you may need a stronger facilitator. Find an opportunity to step in and ask what one of your quieter teammates has to say on the topic.
What needs improvement? (10 min)
Same structure as above, but using pink or red stickies. Remind your team that this is about actions and outcomes – not about specific people.
Next steps (5 min)
Having identified what didn't go so well, what concrete actions can the team take to improve those things? Have your team use blue sticky notes to place ideas on the board. Group them and then discuss as a team, agree to which actions you will take, assign owners and a due date to get them DONE.
Thank everyone for their involvement and their honesty. Quickly run through the list of follow-up items, their owners and due dates.
TOO VANILLA FOR YOUR TASTES?
The steps above are for a brief 30-minute retrospective meeting. Depending on the scope and complexity of your work, team size, and/or length of time since the last retrospective, you may need to expand this up to an hour, or possibly even two hours. Scale each section of the basic workshop as you see fit.
Alternatively, here are some variations and extra elements to try.
MAP OUT THE PAST TWO MONTHS (10 MIN)
On the whiteboard, draw a timeline spanning the past two months. Then have team members call out significant events: iteration/sprint starts, releases, victories, discoveries, or anything else that had an impact on your work.
Do this activity at the start of the meeting. Not only is this a great way to foster a shared sense of achievement and solidarity, it helps refresh everyone's memory and sets the stage for the rest of the retrospective.
THE 4 Ls MODEL (20 MIN)
Replace the "what worked well" and "what didn't work well" activities with a four-part format:
What did you like?
What was lacking?
What did you learn?
What do you long for going forward?
This variation works best in longer (45 - 60 min) retrospectives where you can devote five minutes or more to each question.
TESTIFY (10 MIN)
If time allows (and team members are willing), have each participant speak about the stickies they put up during the "What worked well", "What didn't work well", and "Next steps" activities. This helps to ensure all team members contribute evenly (even the quieter team members) and promotes an even deeper discussion.
ACKNOWLEDGEMENTS (5 MIN)
Take a few minutes to let team members acknowledge each other's accomplishments since the last retrospective and/or express thanks for having received help from a teammate. Keep it brief, and keep it genuine. At some there might be a flood of acknowledgements, while at others there might be very few. Just roll with the ebb and flow – don't force it.
This should be a strictly peer-to-peer exercise, with only team members at the individual contributor level allowed to participate. Managers, scrum masters, etc. are asked to keep quiet.
DOT VOTING (5 MIN)
If loads of ideas emerge during the "Next steps" activity, vote on which action items you'll prioritize in the immediate term. Everyone grabs a marker and places dots on the three ideas they'd like to see at the top of the list (no more than one dot per idea, please!). Tally up the dots, discuss the results with your team, and select owners for the top-voted items.
Note that you can also do this immediately after the "What didn't work well" activity to identify the team's top three areas for improvement. This helps guide the "Next steps" activity and keep it focused on those three areas.
Use the "past two months" variation to help new members of the team get up to speed and put the current retrospective in context.
Here's a retro that used the 4 Ls model.
Be sure to run a full Health Monitor session or checkpoint with your team to see if you're improving.Find your Health Monitor
Be sure to run a retrospective after major initiatives have been rolled out. Schedule a full hour, and use that time to focus not on the particulars of how the initiative went, but on how you worked together as a team and how that can inform how you work together in the future.
Whist project teams likely structure their work as 2-week sprints, you likely have more of a Kanban-esque, continuous flow style of working. Do your retrospectives monthly or quarterly, as suits your team.
Make sure all notes and photos are captured on the page you created for the session, making sure to list the owner's name next to each action item. If any of the action items have corresponding JIRA issues, include a link to them on the page so it's easy to see their status. Save the page and share it with your team.
Always be challenging the value of your retrospectives (y'know: in a healthy, positive way). Are follow-up tasks being completed, or forgotten? Are you getting to the root cause of problems? Would a different set of activities help you dig deeper? There are a zillion ways to approach this play – change it up and make it your own!
Want even more Playbook?
Drop your email below to be notified when we add new Health Monitors and plays.
Drop a question or comment on the Atlassian Community site.