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 Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.
2020 Scrum Guide – Ken Schwaber and Jeff Sutherland.
Sounds simple enough right? And yet whenever I train people on Scrum, the Daily Scrum, or Standup as its often referred to, is the one Scrum Event that seems to incite the most conversation. Why is that?
Often those 15 minutes reserved in the day turn into 45 minutes of hell while each team member monotonously talks about what they did yesterday, what they are planning on doing today, and often skip past the fact they might have some kind of impediment slowing them down. The 3 questions formed the basis for the Daily Scrum in the old Scrum Guide, and I for one am really glad Ken and Jeff took it out in the new revision.
Should the Daily Scrum be strictly time-boxed to 15 minutes? In theory yes, in practice it rarely is, and if you are a team that uses the Daily Scrum for what it’s supposed to be used for its rarely necessary to time-box it anyway. Generally we find that when the Daily Scrum goes over 15 minutes, then there is some anti-pattern creeping in, something is wrong.
The Daily Scrum shouldn’t be a status meeting, ever. If the Scrum Master, or Product Owner, is ‘running the meeting’ and getting an update from each team member and asking questions around what work they are doing, then you are probably living in pseudo project management hell rather than being part of a high performing Scrum Team.
The Daily Scrum should be a very useful check-in for the team members to make sure everyone in the team is on the same page, everyone is focused on the goal, and nobody is getting accidentally stuck in a rut trying to solve a complex problem by themselves. The Scrum Master and Product Owner don’t even need to be there, but its often nice that they are nearby so the team can ask them questions to clarify something.
Here is an example of what I would consider a typical example of a Daily Scrum for a high performing team:
Jim the junior developer enters the office and heads to the kitchen area to make himself his first coffee. Jim is usually the last one in the office of the team, so the team has agreed that when Jim arrives it triggers the need to have the Daily Scrum. A few of the other team members also go to make another coffee with Jim and casually chat about the weather. Sam the Senior Dev has her face firmly planted in her screen and is oblivious to everyone around her as she furiously tries to find the bug thats causing the build to break.
Everyone but Sam starts to move towards the Kanban board as this is the place the team has agreed to hold the Daily Scrum each morning so they have a visual focal point around which to align. Sam is still sitting, not aware of her surroundings, so Jim politely shouts across the room, “Morning Sam!”, which breaks Sam’s concentration and brings her attention to the fact everyone is waiting for her.
“Oh sorry peeps,” exclaims Sam, “I was totally engrossed in that problem I’m trying to fix.”. Sam now joins the others at the Kanban board.
The Daily Scrum has now begun. A couple of the team members ask Sam some questions about the problem, hoping to understand what she is working on, and they all know that sometimes just explaining a problem to someone else can give you new ideas and perspectives to help solve the issue. Jim offers his time to come pair with Sam and ask the stupid questions, be the rubber duck, so that he can learn a little more about how Sam goes about solving problems, and also learn a bit more about the part of the code base Sam is working in.
The other team members tell each other what they’ve been working on recently and how it helps the team meet the Sprint Goal, and what they are probably going to work on next if they manage to finish off soon. Terry the test specialist shows the team how she came up with a great new way to automate a regression test thats been taking her ages to test every time they work on that part of the product. Sam see’s a small issue with the way its been automated so Teri and Sam agree to take some time after lunch to sit together and see if they can improve it a little.
Steve the Scrum Master observes all this happening and smiles satisfactorily at how well the team work together.
Please do not use the word Stand Up as the Daily Scrum is not a stand up requirement and having people on my teams who are unable to stand up are quite left out of such ideas.
Hi Eric, I totally agree with you and I make a point of referring to the Daily Scrum as the Daily Scrum and not a standup. I hope you read the article and saw that I was consistent throughout with the use of Daily Scrum and not Stand Up. I did refer to the phrase ‘Stand-up’ once in the article to point out that that phrase is commonly used and that is potentially what people might google when looking for articles on the Daily Scrum. I’m 100% behind the notion that you do not have to stand up to have a successful Daily Scrum.
Comments are closed.