What to Do After a Sprint

You’ve done it. The sprint ended. Code that solved a specific problem 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.

“Teams that don’t have retrospectives never close the feedback loop,” says Wes Garrison, a Rails consultant and Ruby conference organizer. “They say they want to improve their processes, but they don’t have a system to actually put those changes into place.”

Let’s discuss what that system might look like for your team.

Show the thing off

If your team is centralized in GitHub and ZenHub – and therefore already highly collaborative – they are probably familiar with what’s been accomplished during the 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.

Tweaking your process with sprint retrospectives

After a sprint is completed, you need to make time to reflect on it – especially if you’re new to this workflow. Working constantly might feel good, but without reflection it’s akin to being too busy mopping to turn off the faucet.

We spoke with Henrik Kniberg, author of Scrum and XP from the Trenches and agile coach for Spotify and Lego. He says that before a sprint, the number-one priority should be having the team agree on what success looks like. Then when the sprint finishes, says Henrik, “the team should follow up on whether the sprint matched their definition of success, and discuss what they can do to make the next sprint even more successful.”

Often, topics will come up that warrant more attention. Mark them separately as comments in that issue, then schedule separate meetings with relevant people to follow up.

The most important aspect of a retrospective

The core of any successful retrospective is honesty.

Unless you are 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 estab- lishing 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. (We highly recommend watching entire keynote.)

Scott argues that radical candor – the practice of giving, receiving, and encouraging honest guidance – is actually your moral obligation as a team mate. 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.

Download our free eBook to learn our top tips for effective sprint retrospective meetings and more!