How to Improve After a Sprint – and What to Do If Things Went Wrong

You’ve done it – your development sprint has ended. Code that solved a specific problem was tested and shipped. Your designs are out in the wild, in the hands of your beloved users. 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.

But what if the feature was late? Or you over-committed? Most of us have experienced a situation in which things went off the rails. When this happens, it’s especially critical to find out why it happened the way it did.

Easier said than done, right?

At ZenHub, we spend an inordinate amount of time thinking (and writing) about what goes into a successful sprint. In this article, you’ll learn what every team should do after a sprint, release, or big launch – and how to the bottom of problems without making it weird.

Showing Off Your Work

If your team is centralized in a platform like GitHub (the world’s largest code collaboration platform) or using a collaborative project management tool (like ZenHub), 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. This can be a helpful way to remind your team how your product is solving new problems for users.

As a sidenote: In our team, everything we do is centralized in GitHub. The reason we encourage demos is the same reason why we encourage people to title GitHub issues with user stories.

If you’re unfamiliar, a “user story” is a statement that defines a feature as it relates to user benefit. So, rather than naming an issue “Update CTA button”, it becomes “As a user, I need to see a clear way to download your product so that I can begin using it.” It’s a bit of a mouthful, sure, but by framing your features in ways that put user benefit first, you’re reminding the team to build something that meets a tangible need.

Demos are the perfect time to bring in other people, like 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!

Looking Back First: Sprint Retrospectives

After a sprint is completed, you need to make time to reflect on it – especially if you’re new to this process. Working constantly might feel productive, but without taking the time to look back, you’re basically too busy mopping to turn off the faucet.

We check in for 30-45 minutes every two weeks. To keep the conversation focused, the team lead or project manager will prompt us to come prepared with any points of discussion, which are collaboratively added to a GitHub issue.

Having a successful retrospective meeting without everyone’s participation is difficult. But sometimes, it can be hard for people to speak up honestly.

To ensure even your shyest team member is heard, encourage the team to edit a GitHub issue anonymously. You can create a few standard areas, like the example below:

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.

Making Honesty a Priority

Unless you are transparent about where problems originate, you’ll only be treating their symptoms.

Yet if your team is anything like ours, nobody wants to point fingers. To address this problem of politeness, you should 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 ex-Googler Kim Scott calls radical candor.

Scott argues that radical candor – the practice of giving, receiving, and encouraging active feedback – is actually your moral obligation as a teammate.

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 our go-to strategies to get the most out of our retrospective meetings.

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?

Keep Next Steps in Mind

It’s always better to have a couple of valuable next steps than a bunch of vague ones.

Identify a few things your team will do differently in the next sprint, mark them in your work tracker, and remember to follow up next time to evaluate how it went.

We close our retrospectives by verbally repeating our next steps, and mention 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.

Retrospectives: Keep Asking “Why”

Of course, the value in reflection isn’t just about identifying what you did ‘well’, it’s openly discussing problems and areas you can improve.

“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 a 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.

This is an excerpt from our new book, ‘GitHub Project Management: Building better software and stronger teams.’ Packed with real-world workflow examples and expert advice, the book teaches GitHub users how to master team collaboration, maximize their productivity, and build products users love. Pick up your free copy here.