This article includes an excerpt from our new book. For the full guide to building a collaborative software team, pick up your free copy!
You’ve done it. The milestone ended. Code was tested and shipped. One of your programmers grew a beard. No one expected mutton chops from Martha, but your team is being very supportive of her choices.
All in all, it was a successful sprint.
Now it’s time to take stock, analyze your work, and fine-tune your process so that your next sprint is even more successful.
From thousands of hours of customer coaching, we've curated a list of easy-to-implement tips to show you what needs to be done after a sprint and guide your sprint retrospective meetings.
But first, let’s discuss two other Scrum events you need to organize before holding the sprint retrospective meeting:
If your team is centralized in GitHub and ZenHub – and therefore already highly collaborative – they’re probably familiar with what’s been accomplished during a sprint. Regardless, demos can be a helpful practice to stay connected with your end user.
Try doing a bi-weekly or monthly demo from the user’s perspective. Similar to how we emphasize a user story format in an Issue’s title, you should place an emphasis on how you’re continually solving new problems for your customers.
This is the perfect time to bring in other people, like designers, executives, marketers, salespeople, and the customers themselves. Not only does it feel awesome to show off what you’ve been working on, but it's also helpful to put your complex day-to-day work into terms that everyone can understand.
After your sprint, it's important to discuss how things went together with both the team and the project stakeholders. The Scrum team has the role of presenting the product sprint over no longer than four hours. This means you’ll have a look at what work has been done while the developers should communicate struggles and impediments they had.
This is also the perfect time for the team to share their sprint-related inquiries and discuss what tasks will go into the next sprint.
Here are a few recommendations on key questions to be sure to discuss, especially as you first get started with estimation and sprints:
- Did we accomplish everything or did we take on too much? This is important to understand if work wasn't picked up because you took on too much (perhaps take on 1 less Issue next time!) or if there was an unforeseen technical Issue, meaning the original estimate wasn't the right one.
- Were the original estimates we assigned accurate? What was more complex, and why? What was easier than we thought, and why? After all, the core purpose of a sprint review is to assess whether all goals were met or not. Be sure to document these learnings in a centralized location to leverage for the next sprint's estimation session.
- Anything we want to change for the next sprint? This is known as Kaizen. It's the process of nominating an internal improvement to help the team work better together. Perhaps you want to polish your definition of done, review your code-review process, or establish a 1-Issue in progress limit for the next sprint.
What is a sprint retrospective meeting?
The sprint retrospective meeting is organized by a Scrum Master to get the team to discuss the past sprint and see what needs to change in the future. Compared to the sprint review, a retrospective meeting analyzes the actual work process and ways to improve productivity.
What is the goal of the sprint retrospective meeting?
The main purpose of a sprint retrospective is to help every individual develop their workflow by using objective team feedback as a tool. These meetings generally last between one to three hours and cover topics like team communication, the code review process, team alignment, and digital tools or frameworks used to conduct work.
The three general questions that you need to answer by the end of the retrospective meeting are:
- What went well during the sprint?
- What went wrong?
- What you need to learn and improve during the next sprint?
The most important aspect of a sprint retrospective meeting
The core of any successful retrospective is honesty.
Unless you’re transparent about where problems originate, you’ll only be treating their symptoms.
If your team is anything like ours, nobody wants to point fingers. To address this problem of politeness, encourage a non-judgemental environment focused on improvement and information-gathering. Shaming or punishment have no place here. Set the tone by establishing a safe space; for example, open the meeting by giving out +1s for recent wins.
The intersection of caring personally and being willing to challenge directly is what Kim Scott calls radical candor.
Scott argues that radical candor – the practice of giving, receiving, and encouraging frank guidance – is actually your moral obligation as a teammate. She says:
Radical candor is humble, it’s helpful, it’s immediate, it’s in-person — in private (if it’s criticism) and in public (if it’s praise) — and it doesn’t personalize.
In contrast to radical candor, most of us fall into a dangerous space Scott calls ruinous empathy – which is to say that we’re so intent on being “nice” that we end up ignoring problems and sabotaging our team in the process.
While feedback should be immediate and impromptu, regular retrospectives are an invaluable tool to building a healthy and radically candid team.
Here are a few ways you can improve your retrospective:
Sprint retrospective techniques to remove the fluff from your meetings
Start the meeting by reviewing closed issues
Your team may not close every Issue. So ask yourself: Are they open because your team didn’t have enough time or because they’re no longer relevant?
Whatever the answer, don’t just leave your leftover work in your sprint backlog. You’d be surprised how often those Issues just don’t matter anymore because circumstances have changed.
Take 10 minutes and review what was finished or closed during the Sprint.
Whether it was shipped or closed because it was no longer relevant, a conversation gives the team an understanding of what exactly was worked on versus what you committed to, what was missed and gives a dedicated time slot to discuss any roadblocks the team encountered during the Sprint.
When reviewing Issues, prompt your team to share lessons learned.
- Did you effectively estimate the Issue? This helps benchmark if you were accurate during Sprint planning
- Is there anything that came up in the code base, as you developed the feature, that’s worthwhile to share?
It's important to not just say what was closed or missed but to focus on anything unusual that occurred. For example, you estimated work as a 3 and it was completed, but it was actually quite complex; You should share what risks came up mid-flight, and discuss as a team how to surface these going forward for new Issues that might have similar risks.
Use Github labels for your research, moonshot project, or experimental issues
If you're working on a piece of code that's for an experimental project, something that might be 'thrown away', or is going through research (also known as Spikes) to find the best way to move an Issue forward, be sure to label these Issues in the Sprint. Labels are a great way to understand how much time is spent towards this particular type of work in a Sprint.
In fact, we recommend using labels for groupings within Sprints so your team can use the velocity chart to understand throughput against different Issue types.
Review open issues and discuss why completed work is still open
This helps build habits and reminders that people should update work as the update is available (and will help with keeping the burndown chart updated in real-time!).
If you constantly find yourself with a lot of open Issues in a Sprint retrospective meeting, be sure to ask:
- Did something creep up that made this Issue too complex to get completed within the Sprint?
- Is this still a priority against the other Backlog items?
- Is the estimate on this Issue still accurate? Did we identify something mid-Sprint that changed this estimate, which is why it didn't get completed?
Start, stop, or continue
During the meeting, ask each team member to name things they should start, stop, and continue doing. “Continue” items are the things that are helpful but aren’t yet habits. Mark these in your GitHub issue.
To stay accountable, open each retrospective with a 5-minute review of the previous sprint’s Issue. Ask the team: did you stop, start, and continue the things you said you would?
In any planning or retrospective meeting, discuss out-of-offices for the upcoming sprint
Reviewing resourcing for the Sprint can help determine if there's going to be a significant change in your throughput. This will help drastically improve the odds you’ll finish the work allocated to your Sprint, as you know to take on less.
Estimate issues, not pull requests
When reviewing your Sprint and planning your upcoming one, code changes should remain un-estimated.
Instead, always pair PRs with an Issue, connecting the two via Issue <> PR automation. Issues should always have an estimation before being accepted into the Sprint, while the PR should reflect the actual changes to the code to meet the Issue's criteria.
Issues should flow throughout your workflow and be discussed before being worked on. Meanwhile, the PR represents the tactical work to make that Issue happen. Using Issues in Sprints instead of PRs keeps conversations focused on the user story/task, not changes that happen after the Issue has already been in progress (code changes).
Keep sprint retrospectives focused and actionable
It’s always better to have a couple of high-value actionables than a bunch of vague ones.
Identify a few things your team will do differently in the next sprint, mark them in GitHub, and remember to follow up next time to evaluate how it went.
We close our retrospectives by verbally repeating what our actionables are, and state who the keeper is. A lot can come up during a retrospective, so this final step helps cut through the clutter and ensures everyone understands who is responsible for what.
Look for the causes to particular situations or problems
Of course, the value in reflection isn’t just about identifying what you did well, it’s openly discussing problems and areas of improvement.
Root cause analysis is a fancy term that means “tracing a problem to its source.” It can help you figure out what happened, why it happened, and what steps you can take to prevent it from happening again.
The first step of root cause analysis is to identify the problem: what areas of concern arose during the sprint? How and why did you recognize it as a problem?
Next, you’ll want to collect data: How long has the problem existed? What was its impact?
After that, try to identify the causal factors: What events led to the problem? What other problems sprung up because of it?
By figuring out the causal factors, you can move toward nailing down the root causes of the problem. We need to go as deep as possible to uncover these root problems. Try asking “why” a few times.
- Why did X happen? (Because of Y.) Why did Y happen?
- Why is X a problem?
- Why did we not see X happening until now?
- Why did no one report on X?
It feels weird, but you’d be surprised how repeatedly asking “why” digs up root causes that nobody would have thought of.
Finally, figure out the actionables you’ll take to prevent the problem from happening again.
Pat yourself on the back
You did it!
Not only did you properly prepare for your sprint, you successfully saw it through to the end, and you took the time to reflect and make sure future sprints go even further.
Now get ready to do it all again.
For teams getting started with story point estimating we’ve created a helpful guide on how to estimate in agile project management. If you have any questions, you can reach out to our Customer Success team who are happy to walk you through how to start using estimates.