Sprints have a sacred place in agile, and are often used as a commitment tool to streamline engineering teams. These two-weeks timeboxed events convert your product wishlist into actionable tasks, shape brainstorming into concrete results, and even create a culture of reviews and retros.
Sprints do not just accelerate project deliveries, but even create a culture of accountability, especially in geographically distributed teams. While sprints have always been a sure-shot way to fast forward project management, they can create severe process imbalances if not done right.
Sprints never fail us, we fail sprints.
Running a new sprint is like officiating a project while creating room for improvements at the same time. Because sprints are short-duration events, teams often struggle to recognize when a sprint is veering off-track from its initially accepted goals. Fortunately, there are several key indicators that can signal when sprint planning is failing.
1. More Unplanned Work During Sprints
In a perfect world sprints should be all about- plan your work, and work your plan. But product development is a continuous process, involving multiple iterations, with too many external dependencies in place. Unplanned work is inevitable in a sprint, and most teams even reserve a chunk of their non-core time for unplanned work. However, if teams are spending more than 10% of their effective coding time with unplanned work; it is a perfect ingredient towards a failing sprint.
Unplanned work is anything that prevents devs from doing the actual work- right from keeping the lights on, to getting stuck because of a flaky build. Remember when you had to pause your code because a code patch didn’t refactor and failed? That’s what unplanned work does. It makes dev firefight constantly, even distracting them from actual sprint tasks.
High unplanned work is the first and foremost anti-pattern of your current sprint.
If the team is not properly estimating the level of effort required for planned work or is not accounting for potential issues that may arise, it can lead to an increase in unplanned work. Additionally, it can also risk developer productivity and team morale as additional work can come in the way of pre-decided sprint goals.
How to Address Unplanned Work?
The truth is, unplanned work is here to stay, and cannot be completely eliminated. But there are a few things we can do to limit surprises and off-tracking your sprint work, and overwhelming your sprint backlog.
Data is one answer to the unplanned work challenge for engineering teams.In your next sprint retro, spare a 15-minute discussion to discuss the share of unplanned work vs planned story points. This way, teams can squeeze in some vacuum hours for unplanned work in the upcoming sprint.
Good documentation resolves a lot of delivery challenges for engineering teams; and one of them is unplanned work. Support resources, any gatekeeping information, training support, or more context into a particular build failure goes a long way in reducing some unplanned work.
2. Bugs vs Stories vs Issues
Ensuring work alignment is as important as ensuring team alignment through sprint goals. A healthy mix of bugs, stories, and issues log for every developer per sprint can help achieve it.
Bug fatigue is real. It happens when a developer is spending too much of their time on debugging, rather than delivering on a story point. Bugs are inevitable, just like unplanned work. But, if a developer is spending too much time, even exceeding 20% of their total sprint time into resolving code issues- it is the next red flag teams should be wary of.
Devoting too much resource on bugs sometimes comes at the expense of missing out on value-laden features. Additionally, if a team overly prioritizes bugs, then they are on the verge of disrupted collaboration, and low sprint velocity. This usually happens when teams haven’t properly estimated the complexity of the work.
How to Minimize Bug Fatigue?
The quick fix is to create a separate story point for every bug that is not part of your actual sprint. However, creating new story points cannot solve the real-issue of disproportionate bugs in your sprint.
Now let's talk about the more sustainable way.
Use an engineering analytics tool to visualize your sprint issue breakdown. Create priority sections for all issue types- bugs, story points, even incidences. Try to document any and every issue that your engineering team may encounter. Filter these issues priority-wise during the planning meeting itself.
