How to Use Data to Make Retrospectives More Effective


January 2023 Release Notes

Here’s what’s new in our January 2023 Release Notes:

* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align

Read More »

How can you use data to make retrospectives more effective?

Retrospectives are meetings held at the end of each sprint. They enable teams to evaluate what did or didn’t work and what can be improved upon. Ideally, they should take ~30 minutes. Some teams take longer, sometimes 1-2 hours. Retrospectives have a price tag, suffice that data (software development metrics, sprint burndowns, etc.) can be used to turn their cost into an increasingly wise investment.

But, in the effort to maximize development time, things like meetings (including retrospectives) can be placed on the chopping block. Not such a good idea to do with retrospectives, as they bring a variety of solid benefits to your team and are essential to the Agile methodology:

  • Helps team members see more of a “team view” to foster better teamwork.
  • Creates a safe environment for team members to share thoughts and feelings.
  • Helps managers track the health of their team and project.
  • Promotes transparency and builds trust across the team.
  • Identifies problems, conflicts, and their solutions.
  • Provides a methodical means to prioritize and track issues over time.
  • Essential to any continuous improvement effort.

We’ll prove that at the very least, a 30 minute retrospective per weekly sprint more than pays for itself.

The Five Steps of an Agile Retrospective

A retrospective is a friendlier version of a debriefing, as used by the military and government, and is itself a sort of synopsis of an After Action Report. Debriefings are what you’d normally get after returning (alive) from a mission, “Forget everything you saw, it never happened, you were never there.” Alas, After Action Reports usually get filed away with some sort of Top Secret or Ultra Classified erm… classification that no one ever gets to see. It’s a longer report of what never happened. Being facetious. Sort of.

With retrospectives, we want you to remember what you did, how it went, and walk away with insights so your team can make it better, next time…. Because there’s always the next time.

Step 1 – Set the stage

Prep your team for the discussion. Start with a few minutes to create a more informal tone to help everyone feel comfortable. Make it clear that the retrospective is about this most recent sprint, and it’s not a blame game. AgileStrides includes a Prime Directive of Retrospectives that is read aloud at the start of each meeting:

“Regardless of what we discover, we understand and truly believe everyone did the best job they could given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Setting the stage means defining which retrospective technique you will use – and the technique will guide some of the questions you should ask.

Step 2 – Gather data

As you present the retrospective technique, distribute cards or blank sticky notes (real or virtual) to your team members. Ask the team members to jot down their thoughts and observations – with a time limit.

Step 3 – Generate insights

You can gather up the cards and lay them out, or have your team members add them to the appropriate sections of the retro board. Then it’s time to review and discuss the points while examining if and how they relate to one another – are they the same or share in a pattern or sequence?

Step 4 – Decide what to do

Typically, a team will choose to focus on a single, or perhaps 3-4 issues at a time. Here you define which issues to address and the team gets a brainstorming session to decide upon a quick action plan to solve them.

Step 5 – Close the retrospective

Summarize and celebrate the results. The goal is to reinforce what your team achieved in the meeting and to set a positive outlook for the sprint ahead. Thank everyone for their participation – bonus points for addressing each team member by name and a quick note of their contribution in the retrospective, and/or their work on the last sprint.

Retrospective Formats

Meetings are always so exciting and full of action-packed entertainment, said no one ever. They do happen, but often no one remembers them. That goes to say that they can be spiced up to be more interesting and engaging. It only takes a little bit of gamification using different retrospective templates or formats.

The Quick Retrospective is the simplest and most straightforward focusing on what each member thought was good or what went well, and what didn’t. Everyone’s notes are posted for all to see, to brainstorm ideas and insights. Action plans are devised for the most important issues.

The Quick Retrospective Format

The Mad-Sad-Glad Format aims to get a feel for the emotional health of your team. Similar issues are grouped together, discussed, and voted upon to select the focal points for the upcoming sprint.

The Mad-Sad-Glad Retrospective Format

The Start-Stop-Continue Format focuses on processes. As a team evolves, old processes may become obsolete, need to be adapted or replaced. When processes are added or changed, they also need to be evaluated whether they worked well enough to continue with them – or adjust them further.

The Start-Stop-Continue Retrospective Format

A Bunch of Other Retrospective Formats

While the three templates above are suitable for most purposes, you may want to mix things up more. It doesn’t hurt to experiment, though different templates are designed to get somewhat different types of feedback. They are all tools that can be part of your tool chest for different occasions.

Using Data to Make Your Retrospectives More Effective

As a software engineering manager, you can (and probably should) have an enormous amount of data covering every angle of your software development team’s performance on nearly every imaginable metric. Even if you don’t, odds are you are probably using Agile or a similar method to plan and track your sprint, velocity, and cycle time. You can put the data and charts to work in your retrospectives to get extra insight into abnormalities.

Using Data to Make Your Retrospectives More Effective

In this Sprint Burndown, we can see that the team started off well-enough, hit a plateau, and rushed to complete the remaining tasks. Follow-up questions for the retrospective could be:

  • Did we underestimate the complexity of some tasks during our sprint planning?
  • Were there problems associated with any task dependencies?
  • Was something added to the scope of work on the task mid-sprint?
  • Can we identify what happened and how/why so we can avoid it in future tasks/sprints?

Maintain a History of Your Retrospectives

Software development teams change over time. The average software project lasting 7 years is likely to see most or all of its entire team change three times. Large and complex projects lasting 12-14 years may see 6-7 complete rotations. And besides all of that, it gets hard for everyone to keep track of everything from last month, say nothing about what was discussed six months ago.

This makes it a good idea to keep a record of your team’s retrospectives with a bullet-point summary of issues and solutions on an ongoing basis. If an issue from a previous retrospective resurfaces, you can reiterate the solution or evaluate it on a stop-start-continue basis with your team. Where solutions issues relate to coding standards, your definition of good enough code, work processes, update your guides and SOP accordingly.

Quantifying your Investment in Retrospectives

Harvard Business Review has a meeting cost calculator. Factoring for a team of 8 software developers with an average wage of $107k in the United States, the basic cost of a single retrospective is $300 or $15,600 per year with weekly sprints. Some might see retrospectives as a waste of 2 months of development time and a meeting that could be cut.

Smart managers see retrospectives in the proper light with an ROI of at least 52 ideas to improve future productivity, efficiency, quality, and teamwork. The ROI could be much higher – 150 to 200 ideas. Ideas are a dime a dozen, but putting them into practice can generate business value. As a manager, think of your team’s time with retrospectives as a venture capitalist – many startups will have a nominal impact, while others will go on to be unicorns.

The ideas voiced during a retrospective often apply to issues that one or more team members find frustrating. If left to fester, they may simply leave the team. Addressing them can keep your team together longer, reducing turnover, the costs of finding and hiring a replacement, plus loss of inefficiency while onboarding. Just by reducing the number of developers you have abducted by other software development companies by 1 person per year, you’re doing better than breaking even on your investment in retrospectives.

January 2023 Release Notes

Here’s what’s new in our January 2023 Release Notes:

* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align

Read More »

December 2022 Release Notes

Here’s what’s new in our December 2022 Release Notes:

* Developing Improvements for On-Prem Data Processing;
* Improving Jira Data Connection;
* Aligning Metrics throughout the Application.

Read More »

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.