You want to reduce your lost sprints when it comes to building a release.
Lost sprints happen – customer bugs come in and they derail everything you’re doing. Or a seemingly well-estimated bug blows up in your face and ends up becoming a feature that still needs to be done this sprint, but everything else will be pushed out.
The sprint becomes lost when more and more of your team starts to work on these unplanned activities and continually pulls in more of your team.
How do you stop losing sprints?
- Whoever is setting the sprints, knows the landscape of what can pop up and derail the sprint and plans for that eventuality.
- It’s always easier to pull in tasks, and less debilitating to push them out.
- Don’t wait till the end, monitor early in your sprint if you need to adjust.
The biggest contributor to lost sprints occurring is that the team doesn’t take into account into the landscape that they are a part of. That context of knowledge is what stops your sprints from going offline and once applied to the creation and initial execution of your sprint, your ability to have lost sprints will drop dramatically.
