Bringing notes to Daily Scrum
As a Scrum Master, I came into a Scrum team that ran Daily Scrum based on issue, as in they would open up Jira and go ticket by ticket to give status updates on the tickets.
After meeting with a couple members of the team, they expressed interest in trying the more traditional format of going person by person instead, still having the Jira board up for reference.
We tried it for a Sprint, then took a Roman vote on whether to continue the format for another Sprint.
The one dissenting vote was based on the person having trouble remembering their own update, and focusing on remembering the update (or bringing notes to glance at) without being able to focus on what the other team members are saying.
I empathize with this position - as a Scrum Master for multiple teams (and without a great memory), I often have to bring a few words on a post-it to Daily Scrum to remind me what I'm working on and will work on that's relevant to each team. And this person is a Platform and People Manager, also involved in multiple teams.
As a team, we suggested he try going first each standup so he can then concentrate on others' updates, and to help with how he's feeling, pointed out that some of us sometimes do have to bring notes to this and other meetings, so he's not alone.
I know that bringing notes and prescribing what order to go in for Daily Scrum are frowned upon.
What have you tried or what might you suggest I try to help him feel more at ease at Daily Scrum? I'd like for him to:
- be ok with bringing a note to standup to jog his memory OR not feel like he needs a note
- be able to concentrate on other team member's updates, especially when he's so knowledgeable about the system and our priorities
Thank you!
Does the team feel that they are better able to plan and adjust for the next 24 hours given the changes they've made in the Daily Scrum?
Changing behavior can be challenging and often requires a lot of discipline. If writing it down notes helps the person contribute best to the Daily Scrum then I personally don't view it as a problem. As a Scrum Master I would often jot down anything I wanted to make sure I brought up with the team to help keep myself accountable for making any new issues or knowledge transparent. I would also write down any new habits I was trying to practice... for example... 'less advice, more curiosity'.
Thanks, Tony, for the re-focus. I will ask that of the team to help remind us of what's at the heart of Daily Scrum.
I know that bringing notes and prescribing what order to go in for Daily Scrum are frowned upon.
Where does this come from? It's definitely not in the Scrum Guide, that's for sure - there's no prohibition on bringing notes and no mention of the order of who talks about what. The team should figure out what works for them.
Don't forget that the whole purpose is to plan the work that happens starting after the Daily Scrum until the next Daily Scrum, specifically with respect to how the Development Team is going to move closer to achieving the Sprint Goal. How that's done is not specified, but the Scrum Guide gives an example of a structure that may work for some teams.
Bring on the notes!!
Like previously mentioned, if you start with the intention of the Stand-Up, its purpose is to collaborate amongst each other about their plan for the day. If the team feels the current implementation isn't effective then ask them how to switch it up, or what they think would help. Then try it and iterate.
For us, we don't exactly go story by story, but epic by epic or down the list of sprint objectives. That at least keeps the topics together by context. We mention end of day projected progress just to help prevent surprises of dependencies/handoffs (ex. code review), while giving everyone their own accountability since they set the expectations themselves.
Hope that helps. I'd be interested to see how it turns out for you.
I noticed you used a lot of terms such as "status" and "update". Is it possible that this team's direction toward an individual focus changed the daily scrum to more of "a status update / reporting" versus "a syncing up as a team to progress together toward the sprint goal"?
Either way, there's nothing wrong with bringing notes in my opinion. But it sounds like this may be a symptom of over-reporting/providing a status update rather than simply synching up as a team to progress on the sprint goal.
If daily scrums ever feel funky, I always ask myself, "what is the goal of daily scrum?". Even if we follow the most popular format (what you did yesterday, what you're doing today, what are your blockers, etc.), we may not be achieving the goal of daily scrum.
Thank you, Michael, John, and Thomas - I'm not sure where I got the idea of "no notes" and "no order" from but I think it had to do with Michael's point about it not turning into a status update meeting.
It all does seem to come down to the goal of Daily Scrum, so I'll keep checking in with the team to make sure we're meeting that.
@Season Hughes, Does the team have a Sprint Goal? Are all team members aware of what that Sprint Goal is? Who normally leads the Daily Scrum?
As a Scrum Master, I came into a Scrum team that ran Daily Scrum based on issue, as in they would open up Jira and go ticket by ticket to give status updates on the tickets.
Walking the board is a viable approach, but it is no more about giving "status updates" than the traditional format. The objective should still be about developing a team plan for the next 24 hours. Reading the board typically from right to left:
- Is anything currently blocked/impeded?
- How can we resolve issues that threaten the Sprint Goal?
- Should the Scrum Master take any impediments in hand?
- How can we bring our current work in progress to completion?
- Once these items are finished, what new work might we potentially start?
- Will anyone on the team require help, and if so who can provide it?
Definitely bring on the notes! For that matter, anything that can align the Scrum team with the sprint goal should be encouraged.
I happened to coach the team in Scrum (non-IT but working in a healthcare technology start-up) who had frequently changing scope and timelines. We managed ourselves with the help of JIRA and Trello. However, in our daily stand-ups, we often discussed user feedback which definitely brought new knowledge to the entire team and we were able to make adequate modifications in our work immediately without changing or diverting from the sprint goal(s). The notes we took or the notes anyone brought to the daily scrum became a set of guidelines over the period of time (after testing the hypotheses) and a great onboarding resource for new team members.
I observed that by focusing only on task boards during the daily scrums, we were missing several opportunities for better development as well as opportunities to remove impediments immediately. Hence, we made sure that the appropriate notes were also included during the daily scrum without extending timebox for the daily scrum. As a result of that, only high-priority, high-risk, high-impact issues were taken up by the team for discussion during the daily scrum. I was happy to see the team self manage the issues and learn on their own.