Sprints are helpful for organizing our workload into manageable pieces. By structuring the process of planning, building, testing, and reviewing, we gain consistency and establish clear expectations. The chosen timeframe (often two weeks) ensures that features are ready to ship relatively swiftly while allowing for future iteration. Yet, so much time is spent on what needs to be done that we have to carve out time on how it can be done.
Enter the sprint retrospective.
SPRINT RETRO 101
Sprint retros, as they’re often called, are a routine part of the agile process. Teams meet for an hour or two to discuss the recent sprint and raise questions, frustrations, and ideas. A whiteboard and a healthy number of Post-it notes are usually involved.
A typical sprint retro agenda will cover the following topics:
- What went well?
- How much of our sprint plan did we complete?
- What didn’t go well?
- Where did we run into bottlenecks or obstacles?
- How can we improve our process?
- What can we do better next time?
Here’s the issue: after weeks of swift productivity and some accrued sleep debt, people often struggle to remember exact issues. The sprint had flaws, but how exactly can they be remedied?
A BETTER SPRINT RETRO, EXPLAINED
Look beyond the color-coded sticky notes and deepen your discussion with these approaches to sprint retrospectives.
- Gather feedback throughout the sprint. Many engineering teams wait until the sprint retro to gather feedback. This puts team members on the spot to recall specific moments of friction that occurred ten days (and several late nights) ago. Think of it this way: you can remember what you had for breakfast this morning, but can you describe the menu from last Tuesday? Teams can collect much more acute feedback in real time. Prompt devs for a thumbs up or down on specific Jira tickets, call out red flags during messy moments, and provide a comment space for questions and ideas. These in-the-moment reactions tell much more than holistic metrics. It’s possible that you met all your sprint goals, but the entire team is on the verge of burnout. Successful delivery is not the same thing as team satisfaction.
- Where to look in Uplevel: Sprint Retro Insights has a reaction tool that provides space for positive and negative feedback. Devs can comment on PRs as they work through them or right after they’re complete. Plus, we added emojis, so you can mark items that were party popper (or sad face) worthy. 🎉
- Review items that were added mid-sprint. Ideally, your sprint plan is locked on day one. Realistically, some items will be added after the sprint begins. Were they cross-dependent issues that could only be added once others were complete, or were they breaking news sent from leadership? Any additional work—no matter how “simple”—can derail a sprint. Tracking that change in plans gives valuable insight to your process and gives a peek beyond the rose-colored glasses next time you plan a “perfect” sprint.
- Where to look in Uplevel: Check the Sprint Progress bar, which categorizes your planned sprint items into To Do, In Progress, or Done. You’ll also see a breakdown of ticket changes, including Added Mid-Sprint, Removed Mid-Sprint, Not Completed, and Carry-over from Previous Sprints.
- Understand your setbacks as symptoms, not problems. Everything needs context. Your team may see concerning numbers and feel that the sprint was a failure. We can always work with the assumption that people want to meet or exceed expectations. When we see flaws, we can consider them as symptoms of larger issues, rather than isolated problems themselves. For example, a high number of bugs could be seen as a flawed product—or a very engaged group of reviewers. Zoom out to consider the long term view.
- Where to look in Uplevel: Look at trend data that shows change over time. If one week is an outlier, it might have a case-specific explanation. If the general pattern is concerning, that’s a great signal to revise the process.
- Review your project health… This is the center of most retrospectives. How did your cycle time look during this sprint? Did you have the right reviewers on PRs? Did things get stuck? Were some PRs merged before being approved? Are people remembering to include story points and descriptions on Jira tickets? How many issues were closed?
- Where to look in Uplevel: Sprint Retro Insights shows a wealth of Project Health information regarding Jira and Git activity. Understand stuck PRs, cycle time, use of story points, and so much more.
- …and your people health. A sprint isn’t just about the product. For future success, there must be a focus on the people making the product. Did the team complete the sprint at the expense of high burnout? Did people work long hours and on weekends? Were they context-switching at unsustainable rates? This critical perspective on the cost of productivity plays an important role in effective sprint retros.
- Where to look in Uplevel: You’ll find People Health metrics on Sprint Retro Insights, too. View recent data showing Always On scores (indicating overtime), Context Switching, and the prevalence of Slack interruptions during Deep Work.
Share these tips with your team using our infographic of this post
Your next great sprint starts with today’s effective sprint retrospective. To take it further, incorporate these 5 key actions for a successful engineering sprint.