How to fix your Scrum Daily Meeting

The most misunderstood and resisted of all Scrum ceremonies.

If you ask the people using Scrum what is what they like the least, many will say the daily meeting.

“It takes too much time”, “it is a waste of time”, “let me do real work”, “I have too many meetings”, etc.

These are the typical complaints about it, and definitely, they are not completely wrong. If there is smoke, then there is fire.

The daily meeting is probably the simplest of the events yet it is the one that is handled the poorest (I am included here, of course, there can be some times where my head is somewhere else, and I can miss the focus quickly).

Typically, Scrum Masters will try to provide short term solutions for these complaints (measure time per person, managing the meeting better, passing on a speak token, etc), but, in my experience, these are just consequences or symptoms of something bigger that needs to be attacked at its root. And the root cause many times lies in the structure of the team or how their working process was designed.

This article will describe some of the techniques I’ve done to improve the value of the daily meeting, which hopefully reduce most of the complaints for good.

Symptom: Nobody is listening

This is the most usual problem with daily meetings: the only persons really listening to what the team member is saying is the Scrum Master and/or the Product Owner. This is obviously wrong. The main goal of the daily meeting is to sync the whole team, and if nobody is listening there is no real sync.

Main Cause: There is no real team

A team is defined as “a group of persons working together towards one goal”. But is it really a team where each developer work in their own story or developers and testers work in cascade with days apart? The answer is an absolute NO.

The “self-organizing” motto many times will lead to Joe organizing himself, Mary organizing himself, and all working in silos just because it is the “most efficient way” (this is another article where I will discuss why we seek for effective teams, not efficient ones). Also add to the mix that many developers ENJOY working alone, so it all just culminates into a hollow team.

Therefore, the main cause why the daily meetings won’t work is that the group it is not a real team, and the main solution to this is (as always) a matter of incentive.

If you tell Joe (developer) that his goal is to complete the story 1 and Mike has story 2, will they sync? No, why? Because they simply DO NOT NEED TO.

But what if Joe and Mike both have story 1 assigned? Then both will divide the tasks and work together towards the same goal. That is the correct incentive.

Solution 1: The team should work in a single story

If you push the whole team to work in a single story, then they will work together and once in the daily meeting, they will all contribute to tell what happened yesterday, what blocked/blocks them and what they will do this day forward.

This works when teams are short (3–4 persons) and when stories are big enough to share. If the team is bigger, then probably mini teams will be formed. I don’t think there is much we can do to avoid it, yet having mini teams is better than no team right? :).

For example, if the story is: As a sales user, I want to see the list of customers then you can divide the tasks in the following manner:

• Task 1: Create database query with top 20
• Task 2: Show the grid with the first 20 records
• Task 3: Next page
• Task 4: Previous page
• Task 5: Update database query to offset/limit

As each task is picked up by one team member, then all participants will work towards the same goal: to deliver the story to production. For example, in this case a frontend developer, a backend developer and a tester could carry this story.

Solution 2: Developers and Testers work together

A variation of the “no team” problem is where developers and testers work in silos or in separate subteams inside the main team (developers on one side, and testers on the other). This I believe is not the team’s fault nor even the Scrum Master’s. This comes from historically ingrained modus-operandis (i.e. factory assembly lines) which we have learned are the most efficient way of working with other people and many (or most) jobs that act on the physical world follow the same principle.

How to enhance this situation so they do work together? Again, this is all about incentive.

If you tell the tester: “your goal is to get the most issues out of the development”, then that will be her goal. Note that this kind of instruction or goal would also push the undesired us/them relationship between developers and testers.

On the other hand, if you tell both the dev and tester: “your goal is to deliver this story X with the highest quality possible in this sprint”, then it will be the goal for the both of them, and they will work together towards it.

Cause: People talk to themselves instead of to others

Sometimes when people talk about what they are doing, it is very common they start talking about many concepts they know what they are about, but others do not. Or perhaps they tend to not share the details of what they are doing leaving the rest of the team just hanging or simply not caring (and not listening at all).

For example: “Yesterday I worked in the process of sorting, and today I will be paginating the grid”.

Solution: “Sacar con cuchara las cosas”

In spanish, we have this idiom or phrase “Sacar con cuchara las cosas” which kind of means to “Extract the words out of his mouth”. And this happens when someone reserves or keeps the details from something to himself, yet for others to understand it, we have to pull the words out of him or start making more questions to get to the detail (kind of like when you ask your kid “How was school? Fine”).

Based on the previous example, then the SM would have to ask more questions in order for the rest of the team to understand the context.

• “Well yesterday I worked in the process of sorting…”
• “Sorting of what?”
• “Customers”
• “And can you give a little more information about that?”
• “The sort can be done per name, and phone. Ascending and descending. And today I will be working on the pagination.”
• “And is there any edge case?”
• “Well, actually yes, since customer name can repeat, we always need to add the customer id as a second (and hidden) criteria to sort”.

Did you see the difference? In the latter there is an opportunity for other team members to ask or intervene so it enriches the discussion:

• “Wait! I also have a story with customers, and I think we need to reuse the same database query”.
• “I think your sorting per phone can cause a performance problem because of …”.

So basically, if the info is not there to listen, then how can someone listen?.

Symptom: low value meeting outcome

Other complaint about the daily meeting is that “they are a waste of time”. And indeed, they are a waste of time if the meeting does not provide any value (or very low value) to the attendees. We will see some possible causes for this.

Cause: Team does not know Scrum

This is one possible cause which happens on newly initiated Scrum teams. They used to work mostly isolated and only got together “when needed”. All team members see this is as normal, so pushing a daily meeting onto them, they feel it like an “imposition” or a waste of time.

Solution: Training and Explaining

Definitely the typical solution is to provide real-world examples, making some games about it, trying to make them understand the value of a daily meeting, and how very important is for them to sync every day.

However, they will only absorb the concept once they live it, so probably the next causes/solutions will be more effective.

Cause: SM misaligned with Team

A daily meeting is usually facilitated by the Scrum Master. But there are many types of Scrum Master: those that do not “interfere” at all, and let the team to self-organize, and those that lead the meeting so much that it ends up as a monologue or a question-answer format between the SM and each team member.

Solution: Grow the team and read its temperature

Extremes cause harm, and it also applies to SMs. What a team needs, depends on the team’s state or growth (see Tuckman model) and the current context they live in.

Initially, the team needs an SM that leads the meeting and moderates it. It gathers the team, teaches them what each member needs to share and how they share it, and drives the whole team thru the meetings every day.

But once the team picks up on how the meetings are held, understand the value of syncing, as the team grows and the natural leaders start to rise by themselves, the SM also has to start retreating a little from the front of the team, and go silently to the back of the team.

SM on the front

SM on the back

Additionally, one thing that the SM needs to keep in check is the team temperature and context. Sometimes, a mature team can become a group of rookies when something major changes in their inner workings or in the outside. The SM needs to be aware of this, and it is his responsibility to help the team to set back on track.

For example, one internal possible cause is a senior team member leaving the team. This definitely disrupts the work, and can cause the team to reduce its velocity a lot. The insertion of new technology also can cause this.

Cause: Narrowed Vision

When the team gathers and talks about what is the progress of the sprint or project, it is very benefitial to anchor the discussion towards a visible common focal point. This focal point is usually a Jira or Trello board.

However, the one main disadvantage of Jira or Trello or any other software tool, is the limited view space that they can provide. The space is obviously limited by the screen resolution of your computer or laptop monitor, and if you have a large team, with many stories at hand with many tasks executing, then simply you will never be able to see the whole picture.

So, what normally happens is that people will focus on what they are currently seeing instead of the whole sprint, which is actually what the whole team should discuss every day.

Solution 1: Board with Whole Sprint

If your team suffers from narrowed vision, then this could be solved in two ways. The first one is to widen their vision. How? Use a physical board, or a software board that can help you zoom easily in and out to see the whole sprint in a single view (I have not seen any tool that does this).

Personally, I love physical boards because they are very low maintenance and are very easy to adapt to new situations. And what I love the most about physical boards is the fact that I can see the whole sprint (even future sprints) in a single view and draw conclusions from it very fast.

True story. Back in 2017, I did a physical board with the team (me as SM) where the orange post-its were stories, green post-its were development tasks, pink were testing tasks and the board had three columns: TO DO, IN PROGRESS, DONE.

We were on a daily meeting and the status of the sprint was as shown in the image above.

So after all members gave their update, I asked: “what do you see?”. I let them think for some seconds, and they started to say: “we are behind on the testing side”. We were indeed close to the end of the sprint, and the testing for story 2 and 3 were behind, while development was on track.

This caused a great effect and a turning point in the team: they saw the value of having a big board on the wall (not on Jira), and appreciated the fact that seeing the sprint progress and state was just a matter of moving back two steps from the board to see the big picture.

This is summarized in one word: perspective. Use a tool that can provide perspective to the whole team very easily.

Solution 2: SM needs to enforce the focus on the big picture

It is also possible that the team is not seeing the big picture, because neither the SM or the PO are focusing on it. Remember the famous three questions: what did you do yesterday?, what blocked you?, what will you do today?. If you read them closely, you see that they are very focused on the tasks, but not on the sprint.

That is why a better set of questions is:

1. What did you do towards the sprint goal X?.
2. What will you do today to reach the sprint goal X?.
3. Will we reach the goal? If not, what can we do to solve this?.

With these questions, the team puts its mind on the sprint goal, and new solutions can come up. When the focus was on tasks, the team’s minds tend to narrow down its thoughts onto them alone.

Cause: Meeting is not insightful enough

Value that comes out of the meeting is probably proportional to:

1. Number of times the aha! moments occur (Merriem-webster defines it exactly: a moment of sudden realization, inspiration, insight, recognition, or comprehension).
2. Number of action items decided in the meeting: when actionable and immediate plans get decided/agreed to be done right after the meeting (and they are actually executed for real)

Which also is substracted whenever:

1. The meeting is boring enough that no one remembers what was said.
2. Problems were discussed but no actionable solutions or items were agreed.

Solution 1: Hard questions

One of the abilities the Scrum Master must have (and truly any senior level worker) is the awareness and willingness to ask hard questions. Hard questions open new insights about what is truly going on, and allows the team to reach the root cause of problems therefore taking one step forward towards finding a real solution.

Hard questions should always be made with ingenuity and honesty but at the same time with tact and emphasizing on the process (we should not rule out personal background or knowledge, yet these questions may be better done in private).

Hard questions can range from simple “What is X?” to more complex ones “Who do you think has the answer?” or “What happens if your code fails?” or “Is this X a high or low priority for the spring goal?” or even “What if Joe is wrong?”.

Solution 2: End the meeting with a summary

Our brains tend to have short spans of attention and memory, and if information is not structured in the right way, then it is hard for many of us to retain the details of what was told or described.

That is why a simple summary at the end of the meeting will help everyone to remember the main items of the meeting, and allow everyone to have a general feeling that many things were accomplished and also how far or close we are from the sprint goal.

Also a final summary helps gathering feedback whether the whole team understood correctly everything.

Solution 3: Structure of the daily meeting

A daily meeting typically is held in the following layout: a board, all members forming a semi-circle in front of the board, the SM next to the board, and people taking turns (probably from right to left) to discuss the three questions.

While this works and you can certainly get some value out of it, it is not as effective, especially if you are doing the one-story team solution. This is because the narrative of the meeting (or what people said from start to end and in the order it was told) will not make sense if you transcribe it on a paper or as a story.

If you want to push the members to work as a team, then also push them to tell the story as a team.

So a better structure is one where the meeting goes in order for each story, and all persons involved in the story talk and provide the status. This means that for story 1 Joe, Mike and Mary will talk about it, how it went and what is missing. Then for story 2 Jill and Mary will tell the status of that story.

See that Mary talks twice? Yes, it is a consequence. However, if you transcribe the meeting, then you will have a very clear beginning and end of each story and that has much more value than talking twice, not only for the SM but to the entire team, as the understanding of what is going on is more ordered and focused.

This structure also allows you to make better decisions as you progress the meeting from more priority to less, therefore providing more resources and time to the most important items in the backlog.

As the last part, I would like to tell you why the daily meeting is the most important event in Scrum.

Usually, the only timebox that Scrum mentions is the sprint (1–4 weeks), however, I believe there is one that is even more important: the day (or one day, or day, I’m not sure how to name it).

In one day, you start at 9am and finish by 5–6pm one cycle of work. By the end of the cycle (likewise as an sprint), you should obtain a valuable delivery not necessarily in terms of user value, but in terms of team value: something testable, compilable, visible or tangible towards your daily goal, which in turn goes towards your sprint goal.

One day is a cycle because once you go home to do any other activity, your attention goes to something else, and you start “forgetting” bit by bit what you did before. Therefore it is important that your cycle ends with no “unfinished” tasks, so on the next cycle (the next day), you can pick up from there and make real progress towards the sprint goal.

And, as any other timebox, typically you plan what you will do at the beginning and hopefully at the end you have the expected output. So, as a sprint that has a planning event and a review event, the day also has these events, however merged in one: the daily meeting.

The daily meeting serves as the review of what was done the day before, and the plan of what is going to be done that day. The plan, as adaptability is one of Scrum pillar, can change from day to day based on the circumstances and the context of each cycle (each day).

As a summary of this very long article, these are the main points

• Many people dislike the daily meeting, and sometimes, it is a matter of structure.
• If nobody is listening is because they are not interested.
• Give your team a single goal = the first story in the sprint backlog. Then they will be interested, and they will participate and listen.
• Extract the information if people don’t give it at first.
• Serve your team, and align to their needs and capabilities. This way the daily meeting will have maximum effectiveness.
• Use a board that can give you the sprint status very quickly.
• Widen the focus of the meeting to always be per sprint, not per task.
• Dare to make the hard questions.
• Restructure the meeting to be per story (and no longer per person).
• Though is missed, the daily meeting is the most important event in Scrum. It is the only moment where you can take timely decisions, and allows you to adapt to the changing context at the right moment and with the right people.

Hope you find this article useful, and let me know if there are any other strategies that may serve to fix the daily meeting.

I intentionally discarded the minor solutions to go for the solutions that attack the structure and basis. I am not saying they do not work, nor they aren’t valuable. They are. But sometimes we must jump out of the box in order to solve a problem for good.

Happy scrumming!