When Daily Scrum Goes Bad

Are your Daily Scrum meetings taking more than 15 minutes?

Scrum Meeting

In Michael Mankins’ and Eric Garton’s book “Time, Talent, Energy: Overcome Organizational Drag and Unleash Your Team’s Productive Power”, they state that most people spend on average 11 hours per week in meetings. The point of meetings is to communicate. Communication is a common problem in large complex software projects and constant (daily) communication is key to successful project management. This is why the Daily Scrum is so important. Daily Scrum (when done correctly) optimizes team collaboration and performance. The goal is for everyone on the development team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours. According to the Scrum Guide daily scrum is a 15-minute time-boxed event that is held every day of the Sprint. If you are consistently going over the 15 minutes, your Daily Scrum might be going bad. If that is the case, then one of two things could be happening:

Inefficient Scrum

During the daily scrum, each team member should answer the following three questions:

  • What did you do yesterday?
  • What will you do today?
  • Are there any impediments in your way?

If more detailed discussions needs to happen, individual (or a group) team members should meet immediately after the Daily Scrum to discuss those issues in more depth. This will allow you to adapt or change the rest of the work in the sprint. One sign of an inefficient scrum is going into too many details during the Daily Scrum (ie- lack of discipline in following the 3 questions). Another issue is providing updates not related to the sprint. This can happen if people outside of the development team attend the Daily Scrum. Daily Scrum is designed to be an internal meeting specifically for the Development Team. If other people attend, it is the job of the Scrum Master to ensure that they do not disrupt the meeting. To keep things efficient and productive the goal is to answer the three questions. If developers are not able to answer the question, “What will I do today?” then it could be a problem with the sprint planning and what needs to be accomplished during the sprint.

Team is too big

If you are being efficient with your Daily Scrum, and still overrunning the time then there maybe too many people on your team. If too many people are providing updates (especially updates that are not relevant), people lose interest. Jeff Bezos famously has the two-pizza rule for both meetings and teams. The rule is that each should only have as many people as two pizzas can feed over lunch. The more people in a meeting, the less productive the meeting will likely be for all involved. The Scrum Guide suggests having between three and nine team members who are actually executing the spring backlog. One way to think about this is every person is a node and they link to other nodes. Those links are the relationships between the nodes. Each relationship requires energy (time) and communication. As the team grows in size, the relationships do not grow linearly, they grow exponentially. Which requires exponentially more communication and energy (time).

If the team has grown too large, splitting up the team seems like a relatively easy solution. But how do you split up the team? A good place to start might be a Dependency Structure Matrix(DSM; also referred to as a Design Structure Matrix).

A DSM analyzes the dependencies between modules and can help project managers in:

  • Deciding which modules should be kept under a single team
  • Deciding which modules can be executed in parallel without any dependency clash

If you do not have any modules that can be executed in parallel (ie- all your modules are tightly coupled to each other). You may need to perform some architectural refactoring to create a more loosely coupled architecture. The benefits to this include improved productivity and improved quality of the software.


No one likes meetings, but they are necessary on complex projects so that everyone knows what everyone else is doing and how their work is affecting other people. Understanding the dependencies between your different software modules can help you optimize your teams and keep the Daily Scrum from going bad. If you want to understand your current software dependencies in a DSM format check out Lattix Architect.