After a Daily Scrum, a team member complained, "Daily Scrums are such a waste of time. They interrupt the flow of work we are involved in. Since we all collaborate with each other, I don’t see any need for this meeting. How does answering the three questions daily help us? I think we are just wasting the time of eight people every day in this meeting. Can we skip it?"
Meetings going off the rails
The team was new to Scrum and Agile, and so was I. The team had completed only a few sprints. At times, I had observed the Daily Scrum not going as expected. I had observed two extremes in this meeting. In some instances, people answered only the three questions, and they didn’t really discuss their plans and progress. I also observed that some team members were not paying attention to other team members. In these cases, the meetings just became status updates, and knowing another team member’s progress may or may not have added any value for everyone else. They might as well have learned it as they were working together. At other times, discussions were so deep and technical that they extended beyond the meeting. Other team members who were not interested in those discussions didn’t find they were getting value. Both these extremes gave rise to the notion that the Daily Scrums were not adding value and were a waste of time.
Then and now
Being new to Scrum, I had a tendency to compare Scrum events with traditional project management practices, and I saw how Scrum events added value. In traditional software development, we planned for a three- and a six-month release. The plan was then reviewed regularly to review progress and determine whether there were any changes to be made to the plan or whether there were any risks or issues. Actions to mitigate the risk and resolve the issues were taken. If required, changes were made to the plan/strategy to deliver a successful release. If we saw issues because it was not possible to deliver the committed scope within the release time frame, some of the low-priority commitments were compromised to meet commitments for high-priority requirements, or other adjustments were made.
As we adopt Scrum for software development, teams become self-managed and self-organized. They are then required to perform these activities themselves to plan and manage their work. Most of the team members are engineers and are focused more on technical excellence. During the initial phases of Agile transformation, they need guidance on some of these aspects to plan and manage their work. Therefore, in the initial phases, managers and ScrumMasters can guide the teams in planning and identifying risks and resolving them to achieve their sprint goals. This helps teams become self-organized faster.
Scrum Teams can consider every sprint a small release of traditional product development. Every user story in a sprint is analogous to a feature for a release in the traditional software development model. The sprint planning meeting can be considered release planning, which happened once in three or six months in traditional software development. In these sprint planning meetings, the team plans for the whole sprint. They ensure that every user story meets the Definition of Ready, and they collaborate to create tasks for every user story.
Daily Scrum benefits
As we matured in using Scrum, we gradually realized the benefits of the Daily Scrum. What follows is a description of what we discovered through our own practice.
No more status meetings
Tasks on the Scrum board help the team visualize the progress toward sprint goals as the team moves the tasks. This is analogous to progress analyzed using a Gantt chart. For determining the progress in the sprint, the Scrum board also helps the team identify risks. By observing the Scrum board, the product owner and manager can also evaluate the updates-related progress, thereby eliminating the need for any additional status meetings.
Periodic project plan reviews
During the Daily Scrum, team members discuss their progress with the plan, make changes to the plan, identify risks and issues, and identify areas where they need clarification from the customer. These activities are similar to the periodic reviews of project plans in traditional software development. Since the sprint duration of two to four weeks is much shorter when compared to the project duration in traditional software development, reviews are done more frequently (daily).
For example, let’s say a team member is planning to work on a new user story, but during the Daily Scrum he observes another team member facing problems with a higher-priority activity. Here's an example of a brief conversation they might have during the Daily Scrum:
Yesterday I completed the bug verification and automation of the user story. Code has been checked in, and there were no errors reported by continuous integration tests. Documentation work for the user story is also complete. I will identify the test scenarios for the next user story.
I could complete half of the testing I had planned to complete yesterday. After the lab network outage yesterday, some of the machines in my test setup have become unreachable since the network was restored. I will work on bringing up my setup to start the testing. If someone can help me with it, we can finish this high-priority user story.
I can delay my start on the next user story and work with James to resolve his test setup issue. If this does not consume much time, I don’t see any risk in meeting our sprint commitments. Let's review it again tomorrow.
Teams that run effective Daily Scrums will identify risks earlier, collaborate better, and their managers will easily determine how much progress was made on sprint commitments without asking for the status.
The three questions
The Daily Scrum requires that team members answer only three questions:
- What did I do yesterday?
- What will I do today?
- What impediments am I facing?
The three questions ensure that the discussion sticks to these points and that it does not go into detail in that meeting. These questions should be answered in such a way that the team knows how much progress they've made toward sprint goals and how to plan the work for the day. Answers to the three questions help the team to self-organize. They draw out the obstacles the team is facing or expects to face in meeting their sprint goals.
Team members provide only the level of detail to help them plan for the day. Vague or high-level information would not give a clear indication about progress; at the same time, overly detailed information draws attention away from some of the team members. Detailed discussion can take place after the Daily Scrum with participants who are interested.
- What did I accomplish yesterday? This conversation is around the progress made toward achieving the sprint goal. Instead of answering what was done, the focus is more on what was accomplished. If the team member can be more specific (he or she can provide numbers, percentages, or fractions), other team members can understand the part of the user story that was completed and that progress toward sprint goals has been made. This gives a sense of accomplishment or identifies the obstacle that stems from the commitment made in the previous Daily Scrum that was not met.
- What am I planning to do today? This conversation reinforces the commitment the team member makes. It ensures that the team is focused on high-priority and high-impact user stories. It reminds the team of dependencies or requirements to meet the commitment. It also helps team members understand how the activity of one impacts another. Team members should be specific about what is accomplished by the end of the day so that they know how close they are to achieving the sprint goal.
- What impediments am I facing? The answer to this question identifies the blockers the team must overcome to meet the sprint goals. This question need not be answered separately — it can be included as part of the other two questions. Impediments for work that the team may take up in a day or two can also come out explicitly.
Environment and participants
The Daily Scrum should be run in an environment in which team members feel safe to discuss their plans and raise any issues. These issues can be discussed in detail after the meeting to arrive at a solution.
Although not everyone agrees with this approach, we have found that product owners and other people external to the Scrum Team, such as managers, can attend the meeting but should make sure that they don’t influence the team discussion. Otherwise people won’t raise their issues and failures openly in the meeting, and the purpose of the meeting will not be met. By attending the meeting, managers can identify areas in which people can be coached and mentored to build a high-performing team. They can later work with team members on this strategy.
As with any activity, if the Daily Scrum is not run effectively and for the desired purpose, it will become an overhead and appear to be a waste of time. The team will not understand its benefit. These meetings provide a platform for the team to collectively review and plan their work for the day to ultimately achieve the sprint goals. They provide an opportunity for team members to raise issues and collaborate to resolve them. These meetings help the team self-organize. It is not about only answering three questions but also that the three questions guide the teams to a more focused discussion, They also create a sense of self-accomplishment and accountability in the team. An effective Daily Scrum helps teams achieve their sprint goals, and they can also see improvement in their sprint velocity over time.