How to Run a Sprint Retrospective in 2025

A common theme among developers–at least historically–is that they generally dislike Sprint Retrospectives. There are myriad reasons for this:

Lack of developer engagement due to feeling their opinions aren’t valued
Loudest voices in the room focus solely on their topics, issues, and solutions
Fatigue from overloaded schedules, too many meetings, or poor past experiences
Lack of confidence that this recurring ceremony can/will drive meaningful change
Inexperienced facilitators that don’t run the meeting efficiently and effectively

Grounding Sprint Retrospectives in data, providing your developers with this insight, inspecting it before the retro, and having it available while you conduct your retros can help you overcome every one of these concerns.

In 2025, the role of the Sprint Retrospective has evolved, with data playing a critical role in driving meaningful discussions and actionable outcomes. This blog will guide you through the process of running an effective Sprint Retrospective and how you can adopt data-driven habits that enhance developer productivity and developer experience.

What is a Sprint Retrospective?

The Sprint Retrospective, also known as a Scrum Retrospective, is the final ceremony in the Scrum methodology. It’s where the team discusses the last sprint, with the goal of improving future sprints.

Retrospectives can be incredibly valuable when done right. They help you avoid repeating mistakes, help the team work better together, and make future sprints more productive and less stressful.

What is the Purpose of a Sprint Retrospective?

Sprint Retrospectives are all about examining execution to ensure project delivery. With the right data, you can illustrate a team’s ability to execute or find useful insight into what’s blocking execution, including:

Scope creep
Too much planned work
Over investment in bugs or KTLO
Prioritizing added work over planning work
A habit of added work in general–a big anti-pattern

Goals of a Sprint Retrospective

At its core, the Sprint Retrospective aims to:

Celebrate wins: Identify what went well and replicate successes in future sprints.
Uncover challenges: Surface blockers that hinder progress and discuss strategies to overcome them.
Drive improvement: Develop actionable plans to enhance processes and outcomes.
Foster alignment: Ensure the team’s efforts align with organizational goals and objectives.

By prioritizing these goals, retrospectives become a vital tool for improving team performance and consistent delivery of high-quality work.

Preparing for a Data-Driven Sprint Retrospective

Preparation is key to a productive retrospective. Ensure there is quantitative data for project execution and developer experience data. Use this data–along with conversations, input, and insight from developers–to identify improvement opportunities for planning and execution as well as how life was for the developers on a project.

Predictability comes down to visibility into projects with a focus on risk indicators, WIP, and project execution KPIs. Start by gathering actionable data, such as:

Planning Accuracy: The ratio between planned issues or story points and what were in fact delivered from that list
Capacity Accuracy: Measures how well a team manages its workload and delivers work on time.

Graphic showing the relationship between planning accuracy and capacity accuracy scores.

WIP Metrics: Insights into work in progress and team capacity.
Cycle Time: How quickly work moves through the development pipeline.

PR Size: The average size of pull requests and its impact on review efficiency.
Sentiment Data: Qualitative feedback from team members.

Using a Sprint Retrospective Template, like the one provided in the 8 Habits of Productive Engineering Teams, ensures that discussions remain focused and valuable. Share this data with your team before the meeting to allow them to prepare insights and talking points.

Sprint Retrospective Templates for 2025

The 8 Habits of Productive Engineering Teams whitepaper includes a detailed Sprint Retrospective framework and template designed to make these ceremonies more effective and actionable. The framework is built around the 4 L’s (Liked, Learned, Lacked, Longed For), providing a structured approach to discussions that uncover meaningful insights.

Liked: Positive experiences, successes, and things they enjoyed. Examples include great planning accuracy or attainment of team goals.
Learned: New skills gained or insight gathered. Share developer coaching data with them to see how they advanced–though be careful about exposing private data. Dig into project execution data as well, like increased execution on stories or new features.
Lacked: Missing resources, tools, or support. Project Forecasting data, risk indicators such as lack of resources or overloaded developers, dev coaching data with a focus on knowledge areas, dev experience metrics like wait times, and automation visibility to see what’s being applied and what’s missing–all this will provide additional insight into how you can empower developers and help them achieve more predictability and consistency
Longed for: Wishlist items and things that would make work more enjoyable. Again dev coaching data, surveys, and project data–along with feedback from the team(s) you manage–will help you gain a complete picture and make positive changes for the future.

The example sprint retrospective below uses the “4 Ls” framework for organizing data, insight, and recommendations. Use this in your next retro, and encourage your team to surface wins, communicate gaps that need to be addressed, provide recommendations to improve, and offer feedback that can help you deliver software more predictably.

Liked	Learned
Planning Accuracy: 78% Capacity Accuracy: 89% Total Time Saved (via Automation): 2 days total Team Goals Achievement: PR Size: 95% of PRs <200 LOC Cycle Time: <28 hours Additional Dev Feedback:	10%⬇ in activity on XYZ Repo Typescript use and adoption rates (aligned to initiative): 35% ⬆ 25%⬆on story and new feature work Scope creep: 10%⬆ in added work as iteration went on. Project Forecasting: Project will likely be delayed 1-2 weeks based on current estimates and projections Additional Dev Feedback:
Lacked	Longed For
15%⬆ in WIP across team–likely need to scale back scoping for next iteration 25%⬇ in PA for Project ABC–need to move one FTE to project for next iteration to meet promised deadline 15%⬆in PR Pickup wait time on average for devs on Project XYZ–likely need another resource on this team for next two iterations Additional Dev Feedback:	20%⬆ on JS use over last period for 3 of 5 devs on Team ABC–More focus on front-end work vs application infrastructure and back-end tickets for this team 17%⬆ in Dependabot PRs (patches) created for this iteration. 15%⬆ in PR Pickup wait time as a result Adopt new PR automation frameworks (like auto-approve) to help with this increase in bot PRs Additional Dev Feedback: