After the sprint

The SCRUM guide will tell you that there is a sprint review and retro after the sprint. But there is so much more you should do at the end of each sprint.

You’ve probably encountered the SCRUM guide in your product management journey. This very helpful framework has influenced many companies and their processes, Agile or not. Its simplicity has made it easy to adopt, in part or in whole, but don’t let it fool you into thinking that’s all you should be doing.

The SCRUM guide will tell you, that after each sprint there is a sprint review and retro followed by planning for the next sprint. If you take it at it’s word, you’d be forgiven for thinking that’s all that happens after the sprint, but you’d also be missing out on crucial opportunities and overlooking some critical steps in the process.

There is a lot more you should be doing near the end of the sprint and once the sprint is finished. Here are a few of the less frequently talked about things you should be focusing on:

• Burn down charts

  What gets measured gets done. Burn down charts help highlight bottlenecks and show where work is getting stuck. If your team isn’t tracking progress, you’re flying blind.

• Product marketing

  Now it’s time to tell your customers what you spent all sprint building! Ideally, you’ve already got a go-to-market plan, but this is when you refine messaging with Marketing and get the word out.

• Communicate outcomes to stakeholders

  Your stakeholders need to know what was accomplished, what’s launching, and what’s next. Keep them informed and engaged.

• Celebrate the wins

  Too often, we just roll straight into the next sprint without taking a moment to recognize what we’ve achieved. Celebrate the wins, big or small. It helps morale and reinforces a culture of progress.

• Customer support and success

  Do these teams have everything they need to help your users be successful with what you’ve built? Have you changed things that they, and your customers will need to know about?

• Learnings and future improvements

  Did you or the team learn things during the sprint that are valuable inputs to future work or should be noted somewhere? There may be documentation about how something works, or a learning to apply to the next iteration of something you’re building.

• QA and bug triage

  Even though the sprint is over, there may still be some bugs, or unfinished work that should be dealt with. Do you have a process for managing, triaging and tracking this work?

• Release & deployment

  Not everything built in the sprint goes live immediately. Covering post-sprint release planning, feature flags, phased rollouts, or monitoring for issues all have added complexity.

A lot of these activities are time-boxed to the end of a sprint, but there are a few more that live long after the sprint is over. Some of these ongoing tasks are:

• Gathering user feedback

  What do your users think? How is the feature performing? This is where you validate assumptions, gather insights, and plan for improvements.

• Impact measurement and follow-up

  How is the feature performing? Is it having the impact expected? It’s important to continue monitoring performance, not just of this feature, but potentially how it impacts other user behaviours. What’s the follow-up to this feature?

• Paying down technical debt

  The more complexity added to your product, the more technical debt and overhead costs your team has. It’s important to be aware of this, and plan ways to address this through paying down technical debt, additional headcount and more specialized teams.

The sprint might be over, but the work doesn’t stop. How your team handles what happens after matters just as much as what’s happening during the sprint.

Need a refresher on sprint planning? Check out my posts on sprint planning and what happens during the sprint.