Success With Retrospectives

According to The Scrum Guide: “The Sprint Retrospective is an opportunity for a Scrum Team to inspect itself and create a plan for improvements to be enacted during the next sprint.”  That was the 2017 version, later expressed more succinctly in the 2020 version to: “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”

Retrospectives are at the core of how teams solve operational problems as they seek to accomplish goals. Conducting a retrospective means stepping back from  regular development activities in order to gain insight into how they are doing and how they might perform more effectively. When problems are identified, teams strive to ensure that they have sufficient facts and data to get to a root cause, and may employ tools like Fishbone Diagrams, and ‘Five Why’s’ to support their analyses. A frequent mistake in retrospectives is for teams to overlook their successes and to push ahead with no idea of what they did right or how success was achieved when things went well. Success must be recognized, understood and built upon, otherwise it may become a matter of luck and a team may be unable to reproduce it consistently. Sound retrospection permits an objective analysis of how well things are going or how ineffective they are, and provides a framework for continuous improvement, and the achievement of goals.

A team or an organization’s goals might include making improvements in areas like:

• Productivity
• Delivery Speed
• Quality – fewer released defects
• Improved customer satisfaction
• Improved employee engagement and satisfaction

Teams must be able to demonstrate progress in improvement efforts with simple and clear metrics. At the end of a sprint, a team might ask themselves whether they have helped or hindered overall progress towards their improvement objectives. Fundamental measurements include:

• Velocity Stability: A stable velocity means the team is able to plan and make commitments. A first priority should be to achieve a stable velocity, where stability is a reflection of how much of the team’s planned work was actually delivered to a definition of done.
• Team Productivity/Throughput (Velocity – see comments below).
• Quality: Both in-sprint bugs, and post-release defects.
• Customer Satisfaction: Net Promoter Scores
• Team Happiness: Surveys, ‘Pulse Checks’.

It’s fairly easy to define these metrics and to collect the necessary data, and teams should have a basic system in place to get this data. Many agile management tools, like Jira, provide comprehensive reporting for scrum teams. Burndown and Velocity charts give teams detailed insight into their agile processes, and are a good source of data for retrospectives.

Back to The Scrum Guide:

The purpose of the Sprint Retrospective is to:

• Inspect how the last sprint went in terms of people, relationships, process and tools
• Identify and order the major items that went well, and things that need improvement
• Create a plan for implementing improvements

Simple – what went well, what needs improving, and what actions are we going to take to enact improvements. Metrics from the last sprint should provide insight into what the team needs to look at further and potentially identify improvements. For example, the team might have a goal of completing 90% of sprint backlog items (achieving a 90% predictability rate) – that’s a basic measure of how well the team can plan and execute a sprint. A team might significantly miss that goal for any number of reasons:

• Large stories that were not completed within the sprint time-box and were carried over.
• Poor story quality requiring story re-work and delay.
• Dependencies on work from another team that was not completed.
• Stories rejected by PO as not meeting intent of the stories, perhaps due to vague acceptance criteria.

In a good retrospective, the team would attempt to identify root causes for missing a goal, and propose actions to reduce gaps in performance.

There are many retrospective formats in use, but I prefer to keep it as simple as possible, reflecting The Scrum Guide: What Went Well, What Needs Improving and Actions for Improvement. Like this:

Retrospectives, no matter the format, follow a fairly consistent sequence of steps:

Improvement actions identified by the team during the retrospective should be recorded and tracked. A simple kanban approach is ideal:

Why is this important? Retrospectives must produce tangible results. Not only improvements in team performance: (delivery speed, productivity, predictability, quality), but also in developing a team’s ability to learn and improve. So they have a cultural impact that contributes to building a true agile organization – one where everyone contributes to improvement, and where relentless improvement is a way of life.

At the end of a year, or a quarter, a team should be able to list all of the improvement actions they have taken and stack these against measurable improvements in performance. In this way they should be able to demonstrate to their organization that they have improved. Tooling can help. In the above examples we used the tool xRetro, available for free here: xRetro.

Sidebar discussion on velocity. There’s a lot of debate about the use (and mis-use) of velocity as a metric of team productivity. While it is true that velocity has been mis-used and even weaponized by some command-and-control cultures, used correctly, velocity is a solid indicator of team throughput – the volume of work (User Stories, weighted in points) that a team can produce in a single sprint. According to Scrum Inc.. founded by Dr. Jeff Sutherland, co-creator of Scrum: “Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.” They go on to emphasize: “Velocity is a key feedback mechanism for the Team. It helps them measure whether process changes they make are improving their productivity or hurting it”. And finally: “Without Velocity, Release Planning is impossible. By knowing Velocity, a Product Owner can figure out how many Sprints it will take the Team to achieve a desired level of functionality that can then be shipped”. Velocity provides an estimate of how much of a product backlog can be implemented to a definition of done per sprint. However, there are a couple of prerequisite considerations for using velocity in a meaningful way. 🔹 Sprint output is real User Stories (INVEST) 🔹 The team has a fully transparent definition of done 🔹 Points from partially-completed or incomplete stories should not be counted in calculating velocity. Otherwise, a team’s velocity is meaningless, and their plans have no basis in reality. Teams can improve their velocity over time – not by working harder, but by systematically identifying and removing sources of waste and delay from from their development processes: Re-work (development bugs, stories rejected by PO), delays, hand-offs, dependencies, unnecessary bureaucracy (meetings, documentation, procedures), excessive WIP, scattered teams (communication overhead), teams that are too large, and so on. Retrospectives, applied effectively, can help teams improve in a systematic and measurable way.