How to Predict and Fix a Failing Sprint?

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. 

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 under performance’ 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 burnout pretty soon, even leading them to quit or produce unproductive work. 

How to Ensure Developer Productivity? 

Here, the onus should be on engineering managers to create a healthy mix of issues for each developer. If a developer is too much paged by incident alert in initial days of sprint, managers can cut off some of their lights on time, and shift devs towards feature release. 

Sometimes, even allocating slack time for developers can also help them rejuvenate and build back better in the upcoming sprint. 

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 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 Conduct Effective Sprint Retros? 

Think of scrum retrospective as an opportunity for engineering teams to reflect on their performance. Work analytics can boost visibility into sprint trends so teams have factual understanding of everything that worked/didn’t work this sprint. 

With data-driven insights, teams can easily workaround sprint challenges, and even identify the root-causes of blockers. This data encourages productive discussions towards finding long-term solutions. For example, if teams realize they released less features due to high cycle time, they can dig deeper into what caused the spike, and resolve it before the next sprint planning session.  

Conclusion

Andy Hiles made a lot of sense when she called each sprint an experiment to see ‘if we answer the problem we intended to solve?’ Getting sprints right is the first step towards successful project deliveries and exceptional product development. 

Enroll your entire team into the process, right from planning to mid-sprint jamming, and retros. Set measurable and achievable goals, allocate adequate buffer time, and focus on drilling into data for insights that could change the way teams conduct sprints. 

A healthy sprint is a win-win for everyone across the business cycle: right from customers, to CTO, CEOs, engineering managers and individual contributors. 

Ensure sprint effectiveness with Hatica! Subscribe to the Hatica blog today to read more about unblocking developers, and boosting productivity with engineering analytics.