Want to Make Your Daily Scrum Useful? Try this
If you don’t do it right, it will cost your company a lot, both in terms of money and the opportunity lost.
A quick Google search will return hundreds of articles on why the Daily Scrum doesn’t work. You will find authors argue that they don’t get any value out of the Daily Scrum and that they would be better served if they stop doing the Daily Scrum.
Here are some of the arguments against the Daily Scrum; see if any resonate with you –
1. It becomes a status report to the Scrum Master or to the Product Owner.
2. Everyone is working on their own disparate PBI & the meeting doesn’t serve its purpose.
3. The “3 questions” format stinks.
4. It lasts too long.
5. It becomes a problem resolution meeting or a meeting to just update Stories. Nothing important is ever discussed in the Daily Scrum.
6. Team members are not prepared for the meeting.
7. Team members just go over each of their stories. The updates are not relevant to me.
8. Scrum Master or Product Owner assigns tasks to developers.
9. We talk a lot already, there is no need for the Daily Scrum.
10. We have the Daily Scrum only because management wants it.
11. I really hate to go to a meeting every day and tell people what I did.
12. It puts too much stress on the team.
Daily Scrum, the Right Way
Enough of why the Daily Scrum doesn’t work. Let’s look at how to do it right.
Let’s see how you can put back to use the 11 man-weeks a year per team that is currently being invested in the Daily Scrum (on an average 7 members x 15 minutes x 5 days x 50 weeks = 11 man-weeks per year).
For the sake of discussion, let’s say the Development Team size is 7. The Daily Scrum is supposed to be time-boxed to 15 minutes. Evenly shared, each member of the team gets about two minutes to share their progress towards the Sprint Goal. An average person can speak about 300 (English) words in that time window.
Where are we towards meeting our Spring Goal and what are we going to do today to make progress towards it — that must be the only agenda of the Daily Scrum.
The latest (November 2017) edition of the Scrum Guide states the following about the Daily Scrum –
Here is an example of what might be used:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
How do you expect the poor developer to answer three questions in 300 words, and do justice to them?
Note that the Scrum Guide says, “…what might be used”. Scrum doesn’t enforce this on developers.
However, the July 2016 edition of the Scrum Guide states –
During the meeting, the Development Team members explain:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?”
Note the change in language between the 2016 and 2017 versions. The older version uses a more definitive language, “During the meeting, the Development Team members explain…”, but that changed in the latest edition, where it is more of a suggestion rather than a mandate.
The authors of the Scrum Guide may have realized that answering the three questions in the Daily Scrum may or may not work for all teams, which may have led them to update the Guide.
The July 2011 edition states –
During the meeting, each Development Team member explains:
What has been accomplished since the last meeting?
What will be done before the next meeting?
What obstacles are in the way?
Did you notice how the expectations of the Daily Scrum have evolved from 2011 to 2017 with more emphasis on the Sprint Goal? Many teams have not moved on from the 2016 edition of the Scrum Guide. They try to enforce these questions in the Daily Scrum even though there may be a broader realization that there can be better ways to do the Daily Scrum depending on the circumstances.
Regardless of the challenges you currently face, this one strategy will bring immediate focus and provide value to the team. Ask the developers to just talk about the progress they have made towards the Sprint Goal. And remind them that they have to say it like a 300 word (or less) tweet since they have about two minutes on an average. The developers can talk about the progress towards the Sprint Goal, impediments that may impact the Sprint Goal, or anything relevant to the Sprint Goal that the team should be aware of — all of it in less than 300 words. Let me know how it works for you. I would love to hear back from you.
Remind the team that the Scrum Guide also states the following —
The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
Use these meetings as needed for detailed discussions that are often required while working on complex projects.
Focusing the Daily Scrum just on the Sprint Goal will help keep the conversation laser-focused on one topic and one topic only. This will also enable the team to complete the Daily Scrum in 15 minutes. If the team can stay focused on the Sprint Goal, and communicate with the team the current status of the Sprint Goal, the Daily Scrum will have met its goal.
“The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.” — Scrum Guide (2017)
Although the Guide mentions two activities to be covered in the Daily Scrum — inspect progress towards the sprint goal and progress towards completing the Sprint Backlog, I suggest the teams should focus just on the progress towards the Sprint Goal, at least to start with.
Staying focused on the Sprint goal should help the team consistently meet them, sprint after sprint. It will also improve collaboration on achieving the Sprint Goal. Assuming everything else is done right (e.g. current Sprint Goal represents the biggest value to the customer), the 11 man-week per year investment in Daily Scrum will pay off beautifully.
The phrase “Sprint Goal” appears 26 times in the latest edition of the Scrum Guide, but the Scrum training (at least the ones I have attended — CSM, PSM II) do not give it the attention it deserves. Unless the teams internalize the importance of protecting and meeting the Sprint Goal, they will always leave a lot of undelivered value on the table.
Teams should use empiricism (inspect and adapt) to understand their specific challenges with the Daily Scrum and experiment with various solutions.
Making the Daily Scrum Even More Effective
Here are some other suggestions that will help your team keep the Daily Scrum to 15 minutes and keep it meaningful.
1. Get self-organized rather quickly so that the team can independently do the Daily Scrum, and not need the Scrum Master to facilitate the meeting. The Daily Scrum is the meeting of the Development Team, for the Development Team, by the Development Team. If the Scrum Master facilitates the meeting, there is a tendency to “give a status update” to the Scrum Master. As a Scrum Master, if you see the team “reporting the status” to you, here’s your opportunity to gently guide the team on how to do the Daily Scrum. The Scrum Master may not (and should not be) deeply involved in the development work towards the Sprint Goal (unless he is also a member of the team). It may take up valuable time to explain the on-going discussion to the Scrum Master.
2. Don’t invite the Product Owner to your Daily Scrum. In general, if there is a need for clarifications from the Product Owner, it is going to take more than 15 minutes. Schedule a separate meeting with the Product Owner to discuss the specific topics where the team needs clarification or additional information.
3. Don’t be hung up on 15 minutes time box. If your team requires, say 20 minutes to discuss the progress towards the Sprint Goal, and the team feels they get the right value of it, so be it. As long as the agenda of the Daily Scrum remains to inspect the progress towards the Spring Goal, it may be ok to break this rule once in a while. Of course, attempts should be made to time box the Daily Scrum to 15 minutes. Yes, many Scrum Masters may disagree, but my philosophy is, “whatever works for the team, and delivers the most value to customers”.
4. Instead of focusing on the completion of individual tasks, focus on how it helps the team progress towards the Sprint Goal. Make the Sprint Goal the focal point of the Daily Scrum. You will see a couple of side benefits of this approach — developers will not feel that they are under pressure to give a “daily update” as the focus is now removed from the individuals. Over time, the team will experience how the Daily Scrum helps them achieve the Spring Goal. It will help them see the real value of the Daily Scrum, and not see the Daily Scrum as the “Daily Status” meeting.
5. If you have a team member not actively working directly towards the Sprint Goal, ensure that person understands the Goal and is in sync with the team. Only then he will feel connected with the team AND be ready to jump in if the team needs him. This situation does arise from time to time when there may be a member or two who are working on items that are not directly related to the Sprint Goal (e.g. an urgent customer bug fix).
Last Words
If done right, the 11 man-week per year investment doing the Daily Scrum will result in tremendous returns while ensuring that the team is engaged and focused on the most important activity — the Sprint Goal. Meeting the Sprint Goals consistently will also motivate the Development Team because of the sense of achievement it provides. If your team is challenged by the Daily Scrum, start with the Sprint Goal, at the same time, read the room to understand other challenges that the team faces. Once you succeed with time boxing the Daily Scrum, the team will see it as a positive and start responding to other suggestions to make the meeting even more meaningful. Do share how it goes; I would love to hear about your experience.
