Happy December! It’s the perfect time of year to reflect on the recent past. And for agile teams, that means retrospectives: the meetings held after a sprint, iteration, or release where each team member considers questions like:
  • What went well?
  • What accomplishments did I make?
  • What do I want to improve on?
  • What did I miss that I want to do next year?

Retrospectives provide an opportunity for agile teams to learn, grow, and make product and development culture better. They also ensure the team is continually improving processes by highlighting successes and recurring problems.

Here’s an overview of a typical Atlassian scrum team retrospective from beginning to end. Check out the suggested exercises you can try, too.

Step 1: bring in a facilitator from outside the team

A successful retrospective enlists the help of a strong facilitator to guide discussion and keep the meeting on track. Many teams often choose the scrum master or someone else within the team to be the facilitator of the team’s retrospective. At Atlassian, we’ve found great value in having someone outside the team moderate the retrospective. That way, everyone can fully participate and no one is unduly burdened by running the retrospective. As a bonus, the moderator gets first hand insight into how another agile team works, and this helps facilitate knowledge sharing among agile teams at Atlassian.

Step 2: take your team’s pulse each sprint

To kick the retrospective off, the facilitator asks all participants to write a number from 1 (awful) to 10 (amazing) on a Post-it note. This number should reflect how they feel about the sprint in general—a gut level check on the sprint. (This part is designed to be unstructured. We’ll explore detailed metrics a little later on.) Make sure participants keep their number hidden from everyone else, and then have them pass their numbers to the moderator. Next, calculate the average by adding up all scores and dividing by the number of people. Tell everyone the result, and compare it with the value from the last retrospective.

Optional: Instead of a sprint score, give everyone 4 minutes to draw a picture on a Post-it note that “describes the sprint.” This can be useful to break the ice and get everyone’s brain working.

Step 3: use agile reports for deeper insights

The general sprint score is designed to take a qualitative look at the sprint, and take the pulse of the team’s morale. It’s also important to understand the quantitative data behind the sprint, and there are three key reports in Jira Agile that Atlassian uses to guide the team’s discussion during a retrospective and gather quantitative information. Each report provides deep insight into the team’s agile process, and we recommend looking at the following reports to help your team run a successful retrospective.

Sprint report and sprint burndown chart

The sprint report lists the work completed, work not completed, and any work added after the sprint started. The burndown chart shows the rate of work completed over time.

Questions to ask:

  • Did the team meet the sprint forecast?
  • Was the team’s burndown what everyone expected?
  • Was there work added or removed during the middle of the sprint?
  • Did any work not get completed within the sprint? If so, why?

Goal: Understand how the sprint forecast compared to the actual delivery. Use the burndown measure progress during the sprint.

Velocity Report

The velocity report tracks the amount of work forecasted to complete and actually completed for the last 7 sprints.

Questions to ask:

  • What was the team’s velocity during this sprint?
  • Is the trend increasing, decreasing, or holding steady?

Goal: Track the team’s output over time. The team is looking for the commitment and the completed values to be similar. Also, velocity should increase over time for newer agile teams.

Control chart

The control chart shows cycle time: the amount of time it takes to complete an issue.


  • Does the cycle time of an issue remain consistent?
  • Are issues with similar story point values taking equal amounts of time to complete?

Goal: Reduce cycle time. Validate that individual scores that share the same story point value have similar cycle times. See more in the control chart blog: 6 key ways to optimize development with a control chart

At Atlassian, we also use the retrospective to survey the team’s personal desires for the next sprint. We do this through an exercise called start / stop / continue. The sprint score (step 2) and the agile reports (step 3) help the team generate discussion topics. Make sure everyone in the room has adequate Post-it notes and a fine-tipped permanent marker. Draw three columns on a whiteboard and label them “Start,” “Stop,” and “Continue.” Set a timer for 5 minutes and ask everyone to write down what they want to put in each column.

Step 4: generate discussion topics with “start / stop / continue”

  • Start: What should the team start doing?
  • Stop: What should the team stop doing?
  • Continue: What should the team continue doing?

At the end of the 5 minutes, have everyone stand up one by one (this is important) and put their Post-it notes in each column, saying them out loud so everyone can see and hear.

Step 5: vote on what’s most important

Once everyone has put their feedback on the board, it’s time to consolidate areas of related feedback. Take a scan across the board and see if any one topic appears on more than one Post-it note. If so, cluster similar areas of feedback in one area of the board. It’s ok to mix Post-it notes from different columns as long as they reflect the same topic and pain point.

Next, give everyone 3 votes (or less depending on the team size) for the start and stop columns. Have everyone stand up and draw dots on the Post-it notes they’re voting for. After everyone has voted, take the top three items from each column and start a discussion. These topics will be the talking points.

Step 6: agree on action items

After the team votes, dig into a discussion. Facilitate the discussion towards a solution rather than letting the team rant. Take notes throughout. When the group comes to some consensus on a topic, repeat the action item back to them to confirm, and then ask for an owner. Write all of this on the retrospective page in Confluence, and @mention the action item’s owner. Spend most of the time in the retrospective discussing the selected topics. Aim for 30 minutes to 1 hour for retrospective discussing. A successful retrospective is one in which each discussion item above is strictly time-boxed to ensure each selected topic gets adequate coverage, and the facilitator drives the group towards good on-topic discussion to generate action items with assigned owners.

ProTip: Make feedback even more actionable by creating a Jira issue in the team’s backlog. That way, development culture improvements can be tracked alongside the rest of the work in the team’s backlog. Simply highlight the feedback in Confluence and choose the Jira tooltip icon to import into Jira.

Step 7: record and share the results

It’s important to share the retrospective with the full team. Use Confluence to share the results and notes from the retrospective. I usually have a page open with the Retrospective blueprint so I can type notes throughout the meeting. At the end of the meeting, all I have to do is hit save to publish with the team!

Hungry for more? Check out The Agile Coach – a site with articles, webinars, and ebooks on all things agile.

Learn more from The Agile Coach

Inside Atlassian: seven steps for better retrospectives