What is the purpose of daily scrum? - Facts and Myths
Hi,
I have read the scrum guide. I have acquired PSM I certificate. But still... There is probably so many opinions related to Daily Scrum as many people is practicing Scrum. This is why I would like to start this topic.
I would like to list below what I have heard and I would like to ask you about for knowing your feelings and get feedback about it from you.
1) From my point of view in 100% of the teams that I have met, I have noticed that the Daily Scrum is status report meeting. Nevertheles if it was to/for/with management or for other team members.
I have heard that this is the time for the team and it depends from them how they would like to use this time. So is one of the goals is reporting the status or not? Even not direct one...
2)How to make daily scrum better than status meeting and get much more value from it?
3)Should Product Owner be ALWAYS on the meetings? One says yes, other say no. One people say that this does not help the teams because of their kind of stage fright due to presence of PO (the guy with the gun at his belt). The other sasy that it allows to react faster and solving the issues. I see it as the reason of reporting style of meetigns. What is the happy medium?
4)If team don't want to organise it, should it still be practiced? The question is like famous: "to be or not be be"? Is it something that must be for saying that we have scrum or not?
5) Should it be really strictly only 15 minutes and not any one more? If we have for example 16 or 20 minutes does it mean that we are not following scrum?
6) Do you have any other doubts, myths or facts that would you like to discuss about Daily Scrum?
Hi Andrzej,
Interesting questions, and something I think most Scrum teams wrestle with at times.
1) The biggest issue I have had as a Scrum Master has been to stop the daily scrum descending into a status update to the product owner - or me!
So to fix that. Make sure the team know what the daily scrum is for. Namely to share information with the TEAM about what they've done to get us closer to the sprint goal, what they plan to do today, and what is stopping them.
If they need specific 1-2-1 time with the PO, or anyone else, take it offline. There's another 7-8+hrs in the day left!
2) See 1!
3) The PO doesn't have to be there. It is in their interest to be there so that they can help resolve impediments. If the team fear the PO there's something wrong. This could be misconceptions around the PO's power, or something as simple as breaking down barriers with the PO. Are they co-located? Maybe have lunch together (whole team including PO)
4) YES! The daily scrum should always happen. Same time, same place, every working day!
5) YES! Its a timebox. You may be having too many discussions which causes the overrun. Deal with that, and your 16-20 mins will go away.
One thing to bear in mind. You're not alone with these issues and concerns. The good thing is that they can all be overcome!
Best of luck.
Hi Andrzej,
Here are my thoughts on each of your questions:
1) It is for the team to sync up so they can get visibility on where they are on achieving their shared Sprint Goal. It is not about accounting for their 8 hour day. It is about inspecting where they are so that they can output a plan for the day. So I suppose you could justify using the word 'status report' for the team, but that tends to have too many other connotations. So best stay away from it.
2) Restrict conversations to the items on the Sprint Backlog. Give the team the objective of updating each other, their board, and their burndown. Let them figure out how best to do it. If the Scrum Master is leading the meeting, have them step aside. If management is making it feel more like a status update, kick them out.
3) The Product Owner is not a part of the Daily Scrum. They may find it beneficial to observe, but if it is at all affecting transparency, then they should not be there. You mention that having them there could help solve issues faster, but the Daily Scrum is not the place to solve issues. Otherwise you will never get it done in 15 min. :) You raise the issues in the Daily Scrum and then solve them during your work day.
4) If they don't want to do it, then it is a sign of something worse happening. They do not take their Sprint Goal seriously and they do not see value in Scrum. Shouldn't they want to see where they are on their journey? If they don't care, then we need to focus on the bigger issues of commitment, respect, and trust.
5) 15 minutes is more than enough. In fact, I get restless after 10 minutes. If you need more time, it is probably a sign of other issues, such as attempting to solve problems, justifying your 8 hour day, or too many people on the team.
6) Here is one: The three questions may be a handy guide, but not necessary for a successful Daily Scrum.
Hope that helps!
Don
> 6) Here is one: The three questions may be a
> handy guide, but not necessary for a
> successful Daily Scrum.
Just to add to this, another option is to walk the board and plan how to progress each item. This is more typical of kanban than Scrum, but it can be a good idea to mix it up once in a while to maintain freshness. There are advantages & disadvantages to this technique which Charles Bradley has written about:
http://www.scrumcrazy.com/SP-Daily+Scrum+Pattern+-+Walk+the+Items
+1 to what Don and Ian said, especially Ian's reference to my web site. ;-)
Re: #3
Having the PO attend has upsides and downsides, but does not really violate Scrum either way. "Solving issues" is sometimes an ok thing to do in the Daily Scrum, sometimes not -- depends on the team and whether the team is able to solve issues, have the PO present, inspect and adapt the plan via yesterday/today/obstacles, and sill meet the 15 minute time-box. I've seen it happen, but not usually with beginner teams.
For more info on this, see the following patterns on my Daily Scrum pattern overview page:
Product Owner Attends
The After Party
Defer Obstacle Resolution
Allow Obstacle Resolution
Overview page here: http://www.scrumcrazy.com/Overview+-+Daily+Scrum+Patterns