Why does my team miss sprint deadlines? 3 most common reasons explained.

09/22/2019 by Stanley Ang

Have you ever felt that you have more tasks than you have time? Or that your customers are always at your back chasing for something to be delivered? How about needing to work extra hours and even on the weekends just to meet deadlines? When things like these happen, it affects the employees, the customers, and the organization.

1) Unrealistic Managers:

With the companies that I have worked with, I observed that a lot of managers were too idealistic and optimistic with the targets. There was an instance when the team gave an estimate of 5 days to complete a story, but the manager thought that it was an easy task, so he said: “You just need to call their API to integrate with them, and probably some testing. 2 days should be enough, isn’t it?” One of the team members said: “Yes sir. We can finish that in 2 days.” And this happened to other stories as well. The team members were intimidated with the manager and felt pressured to just accept the trimmed down estimates and commit the stories as part of the sprint. In the end, the team over committed to what they can only handle based on the actual capacity. They did their best to complete the commitments. Even though they worked way past their daily 8 hours shift, at the end of the sprint, the commitments were still not delivered.

This is one of the common problems I encountered with companies who were used to the command and control system. I have seen companies that would cut down the estimates to deliver a system in order to win a project bid. Some would estimate the whole work on behalf of the actual developers, without even consulting them. While others just hand down the work and give a hard deadline. That is the root cause why teams keep on missing the sprint deadlines. Project after project, the same things happens. 

2) Not Empowering the Team

In one of my seminars, I invited members of a team, their Product Owner, Scrum Master, and the higher management who was making the overall decisions. One of the team members was a specialist in repairing cars, and one of the activities I had them do was to estimate the work needed to clean and detail the whole cars’ exterior. The members of the higher management opted to be in the same team.

After an hour of estimation, they presented their work to the audience. The management team gave the following estimates.

  • Washing of the car’s exterior – 1 hour
  • Remove the minor scratches on the body and roof of the car – 5 hours
  • Remove the dirt and dried water spots on the edges (door handles, lights, bumpers, side mirrors) – 3 hours
  • Remove acid rain for all the windows – 3 hours
  • Clean the wheels and apply tire black – 2 hours

  Total: 14 hours

While for the team with the car repair specialist, their total estimate was 5.5 hours.

One of the managers said that the estimate was too low. Then the car repair specialist, explained why they only needed 5.5 hours.

  • Washing of the car’s exterior – .5 hour
  • Remove the minor scratches on the body and roof of the car – 1.5 hours
  • Remove the dirt and dried water spots on the edges (door handles, lights, bumpers, side mirrors) – 2 hours
  • Remove acid rain for all the windows – 1 hour
  • Clean the wheels and apply tire black – .5 hour

After that exercise, I explained to them the dilemma of having someone else estimate for a work that is going to be worked on by another person.

Now the question, is there a way to solve this problem, and how can we solve it? The answer is by empowering the people and computing the correct capacity of the team. By empowering the team, we are allowing them to use their expertise to assess the requirements and give the proper estimates needed to complete a story or an epic. We also need to promote the speak-up culture, and not be afraid to speak-up when you see something is not right. Why would someone who is not the one going to do the work estimate it? Wouldn’t it be better to ask the actual implementors give more realistic figures? With the correct estimates, they will be able to commit what stories can be completed in each sprint. The team will be confident about their commitment since it came from them.

By allowing the teams to provide the estimates and commit what stories can be delivered in the sprint, does this ensure that sprint deadlines are delivered? From my experience, I still encountered teams that didn’t meet the deadline and had to spill over some of the stories to the next sprints. This is where capacity planning comes in.

3) Improper / Disorganized Capacity Planning

Capacity planning is where the team will compute how much time they really have for the sprint. By knowing their capacity, they will be able to know how much stories they can take in. In computing for the capacity, you need to take into consideration the known factors, such as planned leaves, training, holidays, etc. Aside from those, you also need to deduct some time for the scrum ceremonies and unexpected medical or emergency leaves. Most companies deducted 20% to cover for these unexpected leaves. One more thing to consider is if your team does Business As Usual (BAU) tasks, such as support and maintenance. Below is a sample computation for a team of six with the following points.

  • The team of 6 consist of 5 full time capacity members and 1 member with only 50% capacity, due to having 50% as Scrum Master role
  • The sprint duration is 2 weeks, equivalent to 10 working days
  • 1 member is on leave for 2 days
  • There is 1 holiday
  • 20% of the teams’ time for the sprint will be dedicated for BAU

10 working days

x 5.5 (5 full time members + 0.5 capacity for the Scrum Master)

= 55 man-days

- 2 days leave for 1 member

- 5.5 days for the holiday of 5.5 people

= 47.5 man-days

- 9.5 days for the 20% allotted to BAU work

- 9.5 days for the 20% time for scrum ceremonies and unexpected

28.5 mandays total capacity

Now that you know the teams’ capacity is 28.5 mandays for the 2 weeks sprint, you will be more confident in pulling in the stories that will fit. You will only pull what can be done based from the estimates you have for your stories.

To know that stories you need to put into the sprint, you just need to know which stories have the highest priority. The Product Owners will know which among the stories has the highest priority based on their value. To know more about prioritizing of stories, you may refer to this article: https://bit.ly/2lSa9nc

Final thoughts:

The last thing you need to take note of before committing the stories to your sprint are the dependencies, possible risks and blockers ahead. The level of impact of a dependency would vary on its complexity. When there are dependencies on a story, you need to assess whether it can be resolved quickly or not. For dependencies that are easy to resolve, some teams may opt to still commit the story for the sprint. It means that most likely than not, they already know how to resolve it or who to talk to, to eliminate the dependency. For dependencies that still too vague, you may need to further assess it. If the risk if too high or if it may turn into a blocker, you team might opt not to pull it to the sprint and wait for further clarity. 

For the different classification of risks, you may see this in future articles.

If teams are given the chance to practice the aspects mentioned in this article, you will be to confidently commit your deliveries to customers and avoid missing sprint deadlines. The employees will feel empowered and comfortable on what the situation. On the customer’s side, the stories to be delivered will be more predictable and they can have better plans on launches and stakeholder communications. For the company, they will regain or maintain the trust and confidence of their customers.

It’s going to be a win-win situation for everyone. Everyone likes to deliver on commitments as much as they can. Don't you?


Stanley has more than 15 years working in the IT industry, with expertise and focus on Agile coaching and transformation, at the same time managing programs and project teams. During these years of experience, he has proven himself in guiding people and processes to deliver quality solutions. He focuses on the team dynamic and delivery to motivate the organization.
Connect with Stanley Ang on LinkedIn

- Share with your friends or followers.