In a past post, we opened up our soul and confessed to badly missing a sprint commitment. That’s not easy to do for an organization that prides itself on development efficiency, but it happened. We also suggested some ways to improve your process process and recover when a bad sprint happens.

That post got a lot of feedback, so I wanted to expand on it a little bit. As VP of Customer Success, I work closely with our customers every day and will elaborate on that narrative with our first-hand experiences. I am going to illustrate how process mining can make it faster and easier to identify and correct bad sprints in the real world.

We recently wrote about some of the new metrics Bloomfilter uses to assess the health of the development process. In this instance, our Sprint Performance Score was showing a D-.

Looking at the score, we saw objective analysis showing we were off track, and potential areas that could be contributing to the problem. Before taking action, we gathered more evidence to be sure we had the full picture.  

The screen above highlights three potential factors to the sprint’s breakdown including: blocked tasks, increased scope and hazardous tasks.

Blocked Tasks: During this sprint, there were six tasks that we couldn’t complete due to other prerequisites not being met. These tasks remain unresolved, thus impeding progress in our pipeline.

‍Increased Scope: During the course of this sprint, additional tasks were added, resulting in an overall increase of effort by 8%.  

‍Hazardous Tasks: There were seven tasks that were not ready for work. This indicates these tasks either had no description, or no points were assigned to them.

Mining The Process

After examining these three breakdowns, we turned to process mining. And, process mining helped us uncover two key reasons behind the sprint failure: reduced capacity and resource constraints.

Reduced Capacity

This graph shows the comparison between completed work and committed work.  The green line at the bottom represents “Work Done.” The blue line represents the goal for the sprint, or our “Committed Work”. A successful sprint would show these two lines converging at the end, indicating that the team accomplished its goals. As you can see, the lines did not converge.

The disparity between these lines demonstrates that the work for the sprint halted early on, completely stopping on March 16.

Resource Constraints

The graph above illustrates the overall state of work throughout the sprint. In an ideal scenario, you would observe a steady progression of tasks from "Work in Progress'' to "In Review", "In Test", "Staging Ready" and finally "Work Complete."

Bulges on the graph usually point to  process inefficiencies. For instance, if you see a backlog in the "In Test" stage due to limited quality assurance (QA) capacity, it poses risks as there is less time available to address any issues uncovered.

We can see two things from this view. First, the “Blocked” section stands out because tasks that were initially blocked remained so throughout the entire sprint. The plan to unblock and move tasks into testing during the sprint did not materialize, as shown in the process flow.

We also see that when they are working on tasks that aren’t blocked, development tasks are flowing. The progression of story points can be seen from “Work in Progress” (orange), to “In Review” (Yellow), to "In Test” (pink).  However, even without the blocked and undefined work, the pace of the work wasn't enough to successfully close out the sprint.

Conclusion

Process mining identified three potential causes for the poor sprint: hazardous tasks, blocked tasks and increased scope. Our analysis indicated that the work was already falling behind prior to any new tasks being added, emphasizing that increased scope was not the primary factor of the disappointing sprint. Furthermore, we recognized hazardous and blocked tasks as significant issues. During the sprint review, we used this data to understand the root causes and impact of these issues.

With additional business context, we knew that some leaders and developers were busier than normal due to other priorities such as interviewing potential employees. They had less time to focus on the specific issues that derailed the sprint and less capacity to meet their development commitments. While these issues had emerged in previous sprints, the team had managed to deliver successfully. However, the combination of hazardous and blocked tasks with resource constraints ultimately led to our poor Sprint Performance Score.

‍Next Steps

This analysis resulted in two process updates. First, the team now assesses resource constraints prior to a sprint, making sure there is enough work for developers to maximize productivity and minimize hazardous and blocked work. Second, the team exercises caution when scheduling non-sprint related activities and we flag in our exec team meeting when business requests for engineering time reduces our capacity for execution.

Had we adopted a proactive approach rather than a reactive one, we might have identified the diminished capacity of the team prior to the sprint. The team might have recognized the presence of blocked tasks that would prohibit task completion. A proactive mindset would have allowed the team to  take appropriate measures early on to mitigate the impact.

Process mining empowers teams to take control of their processes and enhance efficiency. Prior to a sprint, it enables the ability to identify tasks with prerequisites, assess the impact of increased scope on team output and identify any unprepared tasks. Recognizing these hazards and blocks in advance helps to avoid failure.

If we had seen those hazards and blocks before we started our sprint, maybe we wouldn’t have failed. But we did, so now you can learn from our mistakes. Failure is a part of progress. And we’re so glad we failed so we can set you up for success.

‍

‍

‍