3 Reasons Why Daily Scrum Often Takes Too Much Time?

Have you ever been to a Daily Scrum meeting which took more than 15 minutes? I am not speaking here about 20-30 minutes meetings but much longer ones. Mostly those daily meetings are detested by Developers. They are long and unproductive (I have seen “stand-ups” which took more than one hour). Assuming that people’s daily productivity cycle lasts about 5 hours, Daily Scrum takes 20% of that time which is really frustrating. Especially when deadlines are close.

In this article below we will focus on the most crucial and common mistakes that make Daily Scrum ineffective.

Lack of Sprint Goal on daily SCRUM meetings

Does every Sprint has a clear Sprint Goal? If there’s no goal there’s no point in Sprint. The same with Daily Scrum. There are three standard questions suggested by a Scrum Guide that are put on a Daily Scrum:

  • What did I do yesterday to help the Development Team to meet the Sprint Goal?
  • What I will do today to help the Development Team to meet the Sprint Goal?
  • Are there any impediments preventing me or my Development Team from meeting the Sprint Goal?

As you can see all three questions are put to define a Sprint Goal. If the entire team works for a defined clear goal there is no need in extra discussions.

If you face a problem with defining a clear goal for your team there are few mandatory questions to be asked:

  • Is the product management strategy effective?
  • Is the number of people in your team not too large?

Lack of Backlog Refinement before new Sprint

During the Sprint Scrum Team spends 10% of its time on refining the Product Backlog and preparing requirements for the next Sprint. The absence of clarified requirements leads to numerous questions during the next Sprint regarding work that has to be done on a daily basis. That’s why one of common reasons of a prolonged Daily Scrum is giving insufficient information to team members.

Insufficient informing can’t be eliminated completely even after a good Backlog Refinement. With this in mind, the main goal is to minimize the risk of the unknown while we still have time. If we are doing it a week before starting work on a particular requirement, there is still plenty of time to answer all the questions. There is also time to find the right person to address those questions to. An important thing to keep in mind is that work should be effective and result-driven, not chaotic.

People often make excuses for not doing Backlog Refinement and say that there is no time for that during the Sprint. The real reason is that they have never done it before and they do not have time to find out how to do it.

Insufficient Planning before new Sprint

Plans are nothing but planning is everything ~ Dwight David “Ike” Eisenhower.

Is your Sprint Planning efficient enough? Do you think you spend enough time planning? Can you answer the following questions?

  • What result do we want to receive at the end of the Sprint? What will be the visible change in our product at the end of the Sprint?
  • How do we want to achieve it?
  • Why do we do it? What is the business goal?

An efficient plan should be elaborated during Sprint Planning, otherwise, you will have to totally change the plan during the Sprint itself at every Daily Scrum meeting. Of course, planning could minimize the risk, but it will never eliminate it totally. Adjusting the plan during every Daily Scrum meeting is not the problem, but it might become one when you have to totally change it every day.

Daily Scrum meetings – Conclusion

Lack of Sprint Goal, Lack of Backlog Refinement, Insufficient planning. From these three examples of common mistakes it is visible how a Daily Scrum can cease to retain its quality. I do not claim that those factors are the only possible ones. However resolving these three pivotal factors multiplies your chances to have a resolving and effective Daily Scrum.

A notion to remember when facing a Daily Scrum problem is not to attempt to “heal” it with express methods like setting the time countdown at every Daily Scrum, but to search for the root cause instead.

Experience shows that in most cases the legitimate reasons for all those issues are lack of process understanding and inefficient usage of the methods. I suggest that you answer the following question: Is every team member informed well enough about what the goal of a Daily Scrum meeting is and why does it look like that?

If you want to find out more about SCRUM at Pragmatic Coders, you can read our articles: