Summary
- Retrospectives are a fundamental practice in all agile frameworks.
- Retrospectives enable Agile delivery teams to continuously improve their performance in terms of delivery cycle-time, throughput and predictability.
- Keeping the retrospective process as simple and as data-driven as possible are key to success.
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 2020 as: “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”
Retrospectives play a crucial role in continuous improvement by providing teams with a structured, recurring opportunity to reflect on their recent work, identify areas for improvement, and implement small, incremental changes. Retrospectives support Lean’s core principle of Kaizen—continuous, incremental improvement. By regularly evaluating their processes and outcomes, teams can enhance performance, adaptability, and overall effectiveness in delivering customer value.
When operated effectively, retrospectives can have a measurable impact on delivery performance. Seeing demonstrable improvements in performance helps shift attitudes, which over time can translate into real culture change.
Conducting a retrospective means stepping back from regular development activities in order to gain insight into 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. Successes must also be identified. Did the actions taken from the last retrospective have a positive impact? If so, let’s recognize these and build upon them. 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. 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:
- Creation of a predictable, dependable delivery process.
- Productivity
- Delivery Speed or Cycle Time
- 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:
- Throughput Stability: A stable velocity means the team is able to plan and make commitments. A first priority for any delivery team 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.
- Throughput (Velocity – how much work can be done in each sprint or specific timebox).
- Cycle Time – How long does it take to get backlog items to Done.
- Quality: Both in-sprint bugs, and post-release defects.
- Customer Satisfaction: Net Promoter Scores
- Team Engagement/Happiness: Surveys, ‘Pulse Checks’.
It’s fairly easy to define these metrics and teams should have a basic system in place to collect 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. (What things are helping us make progress, and what things are holding us back).
- Create a plan for implementing improvements.
Simple – what went well, what needs improving, and what actions are we going to take to enact improvements. Data from the last sprint should provide insight into what the team needs to look at further and potentially identify improvements. (See a more recent article on Data-Driven Improvement). For example, the team might have a goal of completing 85% of sprint backlog items (achieving a 85% predictability rate) – that’s a basic measure of how well the team can plan and execute a sprint.
| Flow Metric: Throughput.
Throughput is the number of items completed by a process per unit of time. Units can be anything meaningful for your operation: per hour, per day, per week, or per sprint, and so on. On a CFD Chart throughput is the slope of the cumulative done line. The throughput metric can help answer the question: how many backlog items can be completed in the next sprint, or next release. However, rather than take the simple average throughput (or velocity: story point-weighted number of stories), we can perform a more sophisticated calculation using Monte Carlo Simulation. This analysis will give 2 numbers:
For example: we predict that 85% of the planned stories can be completed in the next sprint. (More to come in a future article). Proponents of this approach argue that using “velocity” for planning is in fact tantamount to deterministic thinking, and that using a probabilistic approach better aligns with the empirical realities of software development. |
A team might significantly miss their predictability 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.
- A dependency on work from another team that was not completed.
- Stories rejected by PO, 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.
Retrospectives, no matter the format, follow a fairly consistent sequence of steps:
Retrospective Inputs
The team will be assessing how well they performed in a number of areas:
- Agreed actions from last sprint – did they help or not?
- Were specific product goals defined for the last sprint or timebox achieved?
- Is the team making progress in its overall performance goals: Throughput, Cycle Time, Predictability?
Tools
Many organizations have teams that are geographically distributed, or are working remote from the office. There are many tools available to support retrospectives in this situation. The image below shows a dashboard with all retrospectives for a single team. The link to the actual retrospective board can be shared with the team ahead of the event.
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:
Improvement actions identified by the team during the retrospective should be recorded and tracked. A simple kanban board is effective:
Retrospectives must produce tangible results. Not only improvements in team delivery performance, but also in developing a team’s ability to learn and improve. Over time they enable development of a true agile organization – one where everyone contributes to improvement, and where relentless improvement becomes part of the culture.
A team’s basic performance metrics (Cycle Time, Throughput, Predictability) should be measured before and after action is taken. This is to collect empirical evidence that the actions taken are delivering actual improvement.
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 objectively that they have improved. Tooling can help. In the above examples we used the tool iRetro, available here: iRetro.
| 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) Otherwise, a team’s velocity is meaningless, and their plans have no basis in reality. Note: If a team can get into a mode of creating mostly small stories – can be taken to done in a couple of days – then use of story points might be abandoned, and velocity is simply the number of stories done per sprint. 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. |
Challenges with Retrospectives
There are a number of challenges to Agile retrospectives
- Lack of follow through. The team once decides on what to start, what to stop and what to continue; yet there is often be little or no follow through. Having a prioritized set of actions to be taken, and tracking these to completion is needed to make tangible progress.
- Many improvement ideas are outside of team control especially issues within the broader organization. The Deming 94-6 rule applies: 94% of problems in an organization are caused by the system, while only 6% are within the team. Agile practices like Scrum or Kanban help shine a light on the problems, but solutions are mostly beyond the team.
- Non-participating team members. Some team members can find it hard to participate in the retrospective process, especially if it involves difficult topics. Some people by nature will hesitate to talk about negative experiences.
- Teams not having a clear long term vision. In the absence of a set of overarching goals, the team may be only focused on short-term small improvements. A clear vision, both for the product they are developing or service they are providing, and for the performance standards they aspire to, are needed to provide a North Star reference they should be working towards. This can provide deeper meaning for the retrospective process, and gives a team a focus for small continuous improvements that build towards a long term vision.
For a more detailed discussion of these challenges, see here.
| Try iRetro
All of the images in this article are screenshots from iRetro (https://iretro.io) |