Many development teams do not practice Daily Standup or Daily Scrum . Rejection is usually due to a misunderstanding of the event’s function and incorrect implementations. The result is the belief that Daily Scrum is a waste of time – and in such circumstances it often is.
According to the latest Scrum Guide (2020), the purpose of Daily Scrum is, and I quote:
“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”
The “famous” three questions, which many equate with the Daily Scrum, have not appeared in the Scrum Guide since the 2017 revision, when they were presented only as a suggestion. In Scrum Guide 2020, they are no longer mentioned at all.
Standard format
A common format for the three questions that developers answer at the Daily Scrum is:
- What have I done since the last Daily Scrum?
- What do I plan to do today?
- What is stopping me from progressing?
Questions in this form really sound like a starting point for a status report, which is not the intention of the Daily Scrum.
The first question in particular can degenerate into “justifying one’s own existence” in the wrong context. When developers start competing who can present their work in a better light, the problem is not the Daily Scrum, but the organisational dynamics. The organisational climate needs to be such that a developer won’t feel embarrassed to admit that he hasn’t progressed towards the Sprint goal. And not just on one, but on several consecutive Daily Scrums. Other developers are expected (if it is in their power) to offer help to a developer with a problem (question 3) after a Daily Scrum event. Why after Daily Scrum? Solving the mentioned blockage is a specific discussion in which not all team members can participate constructively and their presence at the discussion would be a waste of time for them.
Improved three questions
The first suggestion to improve the dynamics of the Daily Scrum is that teams use the full text of the questions as they were last presented in 2017, rather than abbreviated versions.
The full version of the questions is:
- What have I done since the last Daily Scrum to help the team progress towards the Sprint goal?
- What do I plan to do today to help my team progress towards the Sprint goal?
- What is stopping me from progressing towards Sprint goal?
The difference is the reference to the Sprint goal. Other developers are not interested in the meetings and training sessions you attended yesterday. Only the activities that brought the team closer to the goal of the current Sprint are relevant. Questions framed in this way help developers to focus on the business purpose of the Sprint (Sprint Goal).
Daily Scrum KPIs
“Daily Scrum is a mechanism for reducing coordination costs, not for controlling work.”
In the spirit of the above statement, the Daily Scrum can reveal:
- blockages between team members
- waiting for approvals
- dependencies on other teams
- the need for additional expertise
- …
The Daily Scrum also has its own KPIs that the team can measure if it is considering changing the format or even cancelling the event. In this case, the development team measures the following KPIs before and after the change:
- Number of detected blockages per Sprint (question 3).
- Average time from detection to resolution of detected blockages.
- Sprint stability. This is the number of user stories modified/added/replaced/removed divided by the total number of stories pulled into Sprint.
- The percentage of Sprints where a team has reached the Sprint goal.
- Number of coordination errors per Sprint. An effective Daily Scrum should reduce this number.
A couple of examples of coordination errors that could be counted during a sprint:- two developers unknowingly doing the same thing
- the user story gets stuck on the task board because it is not clear who should take it
- development is complete, but the testers didn’t know the story was ready to go into testing
- unforeseen dependency on another development team
- the user story went into development with the wrong version of the acceptance criteria
- integration failed because teams did not agree on the interface
- user stories are returned from testing to development due to misinterpretation of acceptance criteria
- …
Daily Scrum Event Dynamics
The Scrum Master(SM) and Product Owner(PO) are not required to attend the Daily Scrum event. This is especially true for PO. Daily Scrum is an event that developers organise for themselves.
SM and PO can in principle be present, but should not speak. What’s more. If they notice that the developers are turning towards them while they are speaking, it means that they have started to perceive the event as a status report. In such a case, the SM and the PO should simply remove themselves.
Daily Scrum is limited to 15 minutes for a reason. This event is primarily a formal complement to the osmotic communication that ideally already works in a collocated team. Developers inform each other what they are working on, what they are planning and what is holding them back from achieving the Sprint goal. And that’s it. Discussions and planning that result from this information are carried out after the Daily Scrum in a circle of relevant people. Who is relevant for further discussion is left to each individual to find out on the Daily Scrum. There is no more boring thing than being forced to listen to a 20-minute debate between a couple of developers that is specific to them and irrelevant to the rest of the audience. To avoid this, there is a 15-minute limit and a rule that debates are held after the event.
Daily Scrum allows for transparency of work and thus (after the event) the grouping of relevant (to the problem) developers into teams to solve the revealed problems. Hence the slightly misleading claim that “Daily Scrum is an opportunity to plan and adapt the Sprint backlog”.
- Planning in the context of the above statement is meant only as planning to plan. Members agree on who is best positioned to work together on that day and which developers will work independently.
- Adapting the Sprint Backlog is just a result of new insights. For example, if an informal group formed after the Daily Scrum realises that aditional step is needed to reach the Sprint goal, they will add it to the taskboard. The same applies to changing the priorities of user stories within the Sprint or replacing them with more optimal ones – as long as these changes support the Sprint goal.
Other Daily Scrum formats
We should also mention that many Kanban teams, instead of the three questions, successfully use Walk the Board format for their Daily Standup. The event in this format is usually longer, but results are similar. The main difference is that the Walk the Board method focuses on identifying blocked and slow-moving cards and ways to speed up their flow through the development process.
In addition to these formats, there are also formats that focus on a specific factor, such as Risk-focused Daily Scrum, Blockers-first Daily Scrum or Swarming Daily Scrum.
Whatever the Daily Scrum format, for it to be productive, the organisation needs to create a climate of safety. Team members should not be afraid to express their opinions for fear that it will affect their position or that someone will make fun of them. Creative participation is at the top of Maslow’s hierarchy of needs. For it to be present, the organisation must make an effort to fulfil the lower pyramid levels (physiological, security, belonging and respect).
DAILY SCRUM - HOW TO MOVE FORWARD?
The three questions are not set in stone, but they are a good foundation for an effective Daily Standup. I would recommend that development teams, rather than reinventing the wheel, use this format and ensure that other organisational factors support the functionality of the event. Daily Scrum dysfunction is often a reflection of organisational dysfunctions which changing the Daily Scrum format will not solve.
In my previous article, I described Scrum patterns. To keep in line with that the topic, there are some very useful patterns for Daily Scrum. Some are no more than one line long.
Samples related to the Daily Scrum:
