Need to restructure the team's Standup
Hello,
I am a new SM for an established Scrum team. One of the first things I noticed about the team is that their Daily Standup is more of a status update on individual tasks, rather than what was accomplished, what the plan is, or truly inspecting. They use Jira to track the sprint tasks so during the standup, they go down the story list one at a time and whoever is working on the story, provides an update. I fear they have lost sight of the purpose of the standup, and this format allows individuals to hide.
I would like them to move to a more traditional structure (I don't like to use the word structure, but its all I have) in which each individual speaks about what they accomplished, etc. My question is, how can I frame this in a way that helps the team understand the value in this way of doing it vs what they are currently doing? Maybe someone can better articulate the benefits and purpose than I can?
Or, if you think I am off-base in my analysis, I'd love to hear your thoughts!
Thank you,
-Ryan
I don't understand the distinction between "a status update on individual tasks" and speaking about "what they accomplished".
Does the team have specific Sprint Goals? Do the "tasks" in the Sprint Backlog align with those goals? Is the team working first on tasks directly related to the Sprint Goals? When the team members are giving their "status update", are they identifying if a task is behind where they anticipated it to be and are they determining ways to get the back to plan or how to adjust the plan as necessary?
If the answer to any of those questions is "no", that's a problem to be resolved. If the answer is "yes" to all of them, I don't see how they are missing the purpose of the Daily Scrum.
What evidence is being provided for limited WIP and a good rate of throughput for completed user stories? Can the team empirically prove that the risk to achieving the Sprint Goal is being controlled?
I personally have a preference for my teams to "walk the board" as opposed to going around the room and having each individual speak. This is a preference though, and I always try to defer to the team and how they like to work, especially if they are meeting their sprint forecasts and their Sprint Goals.
Yes, "walking the board" may allow individuals to hide, but if the team is performing well, I would just wait and see if team self-management addresses the under-performing team members. Good topic for a retro discussion, perhaps.
You said that the Development Team is well-established, and you are new to the Scrum Team. In a similar situation, I would continue to observe, take notes, and try to make timely suggestions to the team when they are experiencing some pain related to one of my observations.
Good luck.
Checkout this video, it may help and may be good for homework for the entire Scrum Team. https://www.scrum.org/resources/daily-scrum-not-status-meeting
I've actually experienced both methods (the "what I did/what I'm doing/what's stopping me" and "walk the board"), and for me, what shouldn't be lost in the daily standup is the concept of having transparency in inspecting where the team has progressed towards a Sprint Goal, and what adaptations they can work on in order to meet the Sprint Goals.
There's a big difference between knocking off tasks within a User Story to get it to done-done and knocking off tasks to either prettify charts, make good numbers or just indicate "doing stuff". How much of item drill-down are you seeing, if you don't mind me asking? I know JIRA gives the ability to label "sprints" to detail the Goals, but do they use an item structure that is User Story broken into tasks, or Epic broken into user stories?
If you're using Sprint Goals, it would be good to ask the team how they are meeting them after they give their "update". If they are well-established, they can acknowledge and self-organize in order to meet the Sprint Goals.
More importantly, how's the Done-done increments at the end of their sprints?