Sprints have a sacred place in Agile and are often used as a commitment tool to streamline engineering teams. These two-week 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.
4 Signs Why Your Sprint is Failing
Imagine a piece of code. It compiles fine, but when you run it for real, it crashes and burns. That's kind of what happens when you ignore the warning signs that your sprint isn't going smoothly. Pushing through problems can be like shipping buggy code – you might meet your deadline, but it'll just lead to headaches down the road. Here are a few signs to watch out for:
Mistake 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 on 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 the 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.
Mistake 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.
Mistake 3: A Dwindling Team Health
Developer satisfaction is invariably proportional to sprint effectiveness, yet most managers fail to link developer toil with sprint failures. Most engineering teams go by the ‘developers work best underperformance’ approach. It is a perfect recipe to underperformed and even failed sprints.
EMs know their devs better than anyone- their capabilities, shortcomings, and in what circumstances, they outshine. Assigning tasks to developers beyond their work capacity can topple the team’s ability to deliver.
Most developers are accommodating introverts, and it is actually hard for them to speak up every time they are overburdened. Overestimating the workload bandwidth can cause developers to burn out pretty soon, even leading them to quit or produce unproductive work.
Mistake 4: Skipping Sprint Retrospectives
The idea of conducting sprint retros is to document what worked, and what didn’t work this sprint, alongside challenges and blockers. A sprint retrospective meeting is an ideal place for teams to discuss feedback, and compile a list of actionable improvements, and yet most team members deliberately skip them.
Most developers hate retros. For them, retrospectives are monotonous, lack data to back sprint results, or even bring any real change to the next sprints. Sometimes, these retros are conducted half-heartedly, the other times, a lack of visibility into sprint performance prevents actionable retros. If retrospectives are consistently conducted without any clear outcomes, they may become a waste of time and lose effectiveness.
How to Fix a Failing Sprint?
Alright, how do we get this sprint back on track?
We've talked about the warning signs, and let's be honest, sometimes even the best-laid plans go awry. But that doesn't mean all hope is lost! There are ways to take some corrective measures and get your sprint moving smoothly again.
Here are a few ideas to consider:
1. Address Unplanned Work
The truth is, unplanned work is here to stay, and cannot be eliminated. But there are a few things we can do to limit surprises 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. 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, and 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.
