Discussing non-Tasks during daily Scrum meeting?
Often during the daily stand-up my Team members give an update on non-development tasks like "I attended a meeting, waiting on my badge, having a meeting with the client., etc..".
As the Scrum master I tolerate it because our timebox has not been compromised.
But is it proper to update the team on activities that's not directly related to developing the product?
If the Daily Scrum timebox is not being compromised yet with non-sprint topics, that is good. However, that is no guarantee that will be the case going forward.
My suggestion would be to keep the discussion focused on the sprint work during the Daily Scrum, and only if time permits at the end of the Daily Scrum, open the meeting for any additional discussion that may benefit the team.
Keep in mind that the Daily Scrum is the team's opportunity to get on the same page regarding sprint work. It is not a status meeting. There really is no reason for a team member to bring up meetings/activities that have nothing to do with the sprint, unless the result is a capacity impact that affects the team's ability to complete sprint work.
Ask yourself why team members feel the need to "look busy" in the Daily Scrum by recounting all of the activities they participated in? What can you do to change their focus and perception of the meeting?
> ...is it proper to update the team on activities that's not
> directly related to developing the product?
From your reading of the Scrum Guide, why not ask yourself a slightly different question. Is it proper to update the team on activities which are not directly related to the Sprint Goal?
Why do they report on tasks like "I attended a meeting, waiting on my badge, having a meeting with the client., etc.." ?
Is it because they want to justify (=> the Daily Scrum is used as a status/report meeting) ?
How does it help the Dev Team to progress toward the sprint goal ?
In my opinion what matters on the daily scrum is the progress in achieving the sprint goal. Its purpose is to synchronize the work, plan the next 24 hours and report impediments that disturb the team. There is no sense to talk about the stuff that are not associated with the sprint goal.
Imagine a situation when some team member everyday talks about meetings, his breakfast, sick childer etc.. How could it help the team in achieving the sprint goal? It is just a waste of time even when you don't exceed 15 min timebox.
I agree with Jaroslaw -- the time for the Daily Scrum should not be wasted. Timeboxes for all the ceremonies are maximums. There's no need to fill up the time if the team can accomplish the purpose of the meeting in less time.
As Scrum Master, you have a great opportunity to assert yourself and guide the team in positive ways towards better practices. Remember the Scrum value of Openness, and stop tolerating weak practices in your team! I hope your teams become stronger because of your strength and perseverence.
Your comments are consistent, and inline with what I have been thinking also.
Going forward I'm considering that the Team only speak to their specific task number (in this case a Jira ticket). That way, we don't stray from the purpose of the stand-up.
Remember that the Daily Scrum is the Development Team's event. If they are achieving the purpose and not exceeding the time-box, then it is not a violation of the rules. In terms of lean and waste, it might be seen as more productive to restrict conversation, also consider possible downfalls are there with any limitations. How might the sense of empowerment through self-organizing be affected? Does this snowball into denying some joking around which keeps the event from being mundane? Will there be a shift to a more status meeting type of execution? (If it is already, then that the concern that should probably be addressed first.) HTH
Going forward I'm considering that the Team only speak to their specific task number (in this case a Jira ticket).
I have personally seen excellent results using this approach (and it is my preference for teams conducting their standups). It keeps the meeting focus strictly on the sprint work, which is the purpose of the sprint in the first place, and avoids the "roll call" status approach from traditional 3-question standup practices.
Let us know what results you observe.
In fact, it's quite extent to focus on the baton and not on the runners, that is, I know teams who review items top-down (by importance instead of following an talk order of the members of the DT). Their talk is focused on which was the progress, and will be the progress and any impediment to make further progress, then the next item and so on. This way can be more "chaotic" because not everybody has something to say and when there's collaboration to carry out an piece of the place between two or more people, just the update of one of them can be enough. So it's not so organized as round-robin talk. But on the other hand could be beneficial.
About not task... is the current sync good enough between the DT?
Are these tasks not to related to the Sprint Goal (needed to be controlled or measured for any purpose?, e.g. the DT is lately missing the Spring Goal, etc.).
What about asking the DT how useful are these updates for them and to achieve de Sprint Goal?
About not task... is the current sync good enough between the DT?
Are these tasks not to related to the Sprint Goal (needed to be controlled or measured for any purpose?, e.g. the DT is lately missing the Spring Goal, etc.).
What about asking the DT how useful are these updates for them and to achieve de Sprint Goal?
Sanjar, regarding having the team members speak to their task numbers in JIRA, great. Also coach them to state the Summary (headline) of the task, not just the ticket number. It is meaningful and everyone listening knows what the work is.
Great feedback.
Darlene, I've found that team members just seamlessly read off their ticket number and summary. Good happenstance.
Where there is a physical task board present, encourage team members to go up to the board and actually point to the relevant item. It's surprising how many adopt a sudden look of bafflement as they realize that the item is in the wrong column or has the wrong avatar on it, and has not been magically updated by the fairies since the last scrum. It's an opportunity to assess team ownership of this information radiator, and the plan it should represent.
From experience, walking the board often results in a status meeting as much as passing the baton and 3QF. Having a discussion is natural and supports team collaboration over speaking as individuals in a group. Why are people reciting ticket numbers and summaries? That can be a red flag indicating people working in isolation, perhaps even waterfall inside Scrum
Back to the original question, I've seen a Development Team create their own Daily Scrum rule that work not related to the Sprint Goal would not be discussed unless it was an impediment. The rule was founded in the management attending the Daily Scrum desiring an accounting of each team member's time. As a side effect, the team members began to slide toward a status report format. As soon as management became enlightened and stopped attending, the team removed the rule to foster better communication through conversation.
Remember that the Daily Scrum is the Development Team's event. If they are achieving the purpose and not exceeding the time-box, then it is not a violation of the rules. There is no reason to interfere.
Alan, I agree with you halfway. The Scrum stand-up is an opportunity for the Developers, yes, but also an opportunity for the Product Owner to get a pulse on progress and understand implication of blockers.
I have no problem with discussions in a stand-up, so long as it doesn't hurt timebox and is related to the tasks.
Just some quick brainstormed thoughts . . . Would telling a joke be out of line? What about the possibility of unseen impediments or efficiency reducers that could remain hidden by restricting the dialog? If the observing Product Owner felt he/she was not getting the information desired, would that influence a change in the Daily Scrum? What risks to achieving the event's purpose could that create? How would effectiveness/efficiency be affected by allowing the Development Team to identify and discuss possible impediments then bring them to the Scrum Master and Product Owner immediately following?
My stand-ups are not so robotic and musty. We do quip and joke.
My observation of Scrum is that while it's particular of it's definitive expectations, it's neutral or silent in other areas, like the observing PO or even asking the Team if there's any discussion points post-stand-up while everyone is still in the room.