Confession time…we at Bloomfilter, like most other development teams, once in a while have an off week and we don’t meet our sprint goals. Recently, we might even go as far as saying we had a “bad” sprint. I think most teams can identify the sprints where things don’t go completely right (and it usually comes out in the retrospectives, anyways).

The good news is that we didn't need to go far to confirm our suspicions that this sprint was, indeed, bad. Our own platform helped us out by indicating that our Sprint Performance earned a D- grade (not an F, but close!).

Failed sprints are usually caused by bad processes. In our case, poor sprint planning caused our downstream performance to go off the rails.

At this point, you may be asking yourself why we're so keen to share our missteps. The answer is simple: we believe in transparency. By acknowledging this D- sprint, we learn and improve. And to help others learn from our failures, we build these insights into the Bloomfilter platform.

Here are few ways we examined our performance during our retrospective and took some specific steps to address it:

1. We validated the data integrity. We looked at the underlying data in the platform to ensure that the "D-" grade reflected our perception of the sprint, and it did.
2. We examined the timing. Was this an isolated incident or a recurring problem? While most of our other sprints had been in the A or B range, we noticed that productivity had dropped significantly in the second half of the previous sprint. So while this wasn't a consistent issue, it also wasn't limited to two bad weeks.
3. We discussed capacity. Were team members unavailable unexpectedly? In this case, we lost a lot of team capacity due to interviews with developer candidates taking place midweek., We realized that this could potentially present a risk in future sprints when hiring is also a priority. We made a note to mitigate this risk as we screen future hires.
4. We assessed scope. Was it realistic at the outset? Did it change unexpectedly because of executive fiat or customer demands? Our scope was probably realistic for a typical week, but became unrealistic given the capacity loss. We also looked at the productivity of tasks vs points to see if this was an artifact of the team taking action on unpointed cards. In fact, productivity was down on both a task and a point basis.
5. We considered morale. Were team members frustrated or angry? We asked multiple team leaders and members to understand their feelings, but we couldn't find any morale issues that needed to be addressed.
6. We analyzed the process. Efficiency was probably the biggest takeaway. We lost a lot of capacity due to the CTO and CPO's involvement in hiring conversations, which left our backlog of engineering tasks less refined than usual. When the engineers started executing on the sprint, they had fewer cycles and a less streamlined queue of work. Our blocked tasks spiked, our task efficiency plummeted, and despite many hours worked, we accomplished less.

This analysis was important because our response would have been different if the causes of the bad sprint were different. For instance, if the team was burned out or exhausted, we would have taken different remedial steps.

If we were to give advice to teams coming off of a bad sprint, it would be this:

1. Don't overreact. Let the team know they are supported, but don't over-steer the ship in a way that makes things worse.
2. Watch for recovery. If it's a process and a bandwidth issue stacked together, we should see recovery quickly in the next sprint. (This is happening, with 15 points shipped in the first couple of days.)
3. Plan for the future. Ensure that the backlog is better prepared, so process issues don't arise again. Ensure that the team is aware of the capacity reduction that comes from serving other critical business needs, like hiring.

This experience taught us a lot about our customers' perceptions of bad sprints. We are evolving the platform to find the warning signs of these issues more quickly and proactively. We are also working on more capabilities to diagnose and remediate the issues that cause these challenges in the first place.

Have you recently had a bad sprint? Tell us about it hello@thebloomfilter.com.

‍