In the spirit of supporting empiricism and self-management, there should be no single template a Scrum Master should support. Daily Scrum meeting templates can turn into rigid processes which turn into a group of engineers reporting status like a bunch of robots. No one gets value in that.
Since Scrum Masters do not even need to attend the Daily Scrum, you’re looking for things that you can teach developers. What are those things?
Tools in the Daily Scrum Toolbox
Goal, Goal, Goal
Rather than looking at the end goal in a linear way, Scrum doesn’t have a designated path to get there. Therefore, Daily Scrum is wasted by merely providing a checkpoint of where you are on that path. Football, for example, is a great analogy.
Imagine you’re out on the field, losing by five. You’ve got about 60 seconds left in the game. Johnny’s hurt. What are we going to do? The huddle to determine your next move? That’s similar to the Daily Scrum. What do you need to accomplish now? You want to win the game, sure, but what can be done in this moment to get you closer to that goal?
Person by Person
A very common approach for most teams during the Daily Scrum would go something along these lines:
- Cari: One of our customers experienced a bug incident yesterday. I’m still waiting for the engineering department’s feedback on the same. Additionally, I successfully ran four onboarding sessions with a 70% sign-up rate for those who signed up.
- Rob: Good. What about you, Greg?
- Greg: I booked three demos yesterday, and I’ll be launching three new sales cadences today. Our email service provider has been down for the past two days, so let’s see how that goes today.
- Rob: I see. Jason, any pointers?…
While this person-by-person approach can work, it has its downsides. For starters, it’s slow and may lengthen the Daily Scrum. A person-by-person strategy may update the team on the progress of each individual but not inform the team of the general progress toward the Sprint Goal. Thus, your goal may be in jeopardy and you wouldn’t even know it.
The above conversation sounds more like an infantryman’s status report. The danger of such lackluster reports is that the meetings can progress in mindless circles with no real value derived. The Scrum Team may also be tempted to contribute anything and everything in the name of giving a status report to the boss.
Instead, chill out; it’s okay if some members occasionally have nothing to say. To increase engagement and the value of the Daily Scrum as an Event, direct the conversation back to what’s relevant in measuring the progress. You should be asking “Where are we in relation to achieving the Sprint Goal?”
If possible, define clear metrics of what progress means for each Sprint Goal and use that as a conversation starter and guide for Daily Scrum discussions.
Add Visualizations
The team should continuously visualize the product development journey and track relevant key performance indicators (KPI)s to understand where they are at any particular time.
There are a few ways in which you could formulate a visible and traceable journey.
Burndown Chart
The Burndown Chart is a graph with a negative slope that tracks the remaining tasks against the amount of forecasted work Developers plot the actual burndown against the ideal trend line. Many common agile development tools support this such as Jira, Azure DevOps, or you can just make one using a spreadsheet. A few other tools you may consider using include;
- Atlassian Jira
- CA Agile Central (Formerly Rally ALM)
- VersionOne
- IBM Rational ALM solutions
- Microsoft Azure DevOps Server
- Basecamp
- Azure DevOps
Burndown Chart is like a candle that acts as a real-time measure of progress during the entire Sprint. The team lights the candle at the beginning of the Sprint and marks progress each day by how much candle is remaining. The aim is to have all of the wax burned down by the end of the timebox. Impediments may arise that require unplanned hours from the developers.
Similarly, some challenges may arise that weren’t anticipated during the Sprint Planning hence triggering the Scrum Team to make adaptations to the Sprint Backlog without affecting the Sprint Goal.
Kanban Board
Kanban is Japanese for “signboard.” A Kanban Board is more hands-on as anyone on the team can post updates and see progress at a high level.
A Kanban Board groups the tasks into columns of the level of progress. It is organized into a visual task board often using posters or sticky notes that list basic information about the task which may include the number of hours required to complete it or the amount of time spent on it so far. The Kanban Board helps the developers update the Sprint Burndown Chart but also provides overall transparency into progress toward the Sprint Goal.
Better yet. a combination of the Scrum Burndown Chart and a Kanban Board will paint an even more clear picture of progress by showing work in progress, and the likelihood to complete the Sprint Goal within the Sprint. They both help deliver maximum value to the customer and accomplish goals.
Impediments to Progress
Take time to understand the Developers’ journey and how they are defining and using processes to their advantage. Encourage an open forum for developers to discuss any blockers or hold-ups encountered during the Sprint. More generically, you want the developers to feel comfortable raising impediments to progress that may jeopardize the Sprint Goal. Impediments must be removed.
Ask Different Questions
The Daily Scrum isn’t a status meeting to answer the three traditional questions addressing yesterday’s accomplishment, today’s work, and blockers encountered. That is a suitable place to start, but a goal-focused Scrum Team will go beyond that.
Let your visualizations help you uncover questions you aren’t asking. Like, “why has that work item #2 been stuck in progress for 7 days?”, or “I see the testing has not been completed for work item #7, can I help with the testing?” These are questions that help the developers deliver value more seamlessly and consistently.
Good questions can help the developers make changes based on real-time performance, how much time is left in the Sprint, and what’s slowing them down
Bottom Line
View the Daily Scrum Meeting template as a starter pack that needs constant improvements. The tips listed above may also not be comprehensive in themselves. You can constantly adapt the list as it best suits individual Scrum Teams.
Now that the cat is free alas, remember your role as the Scrum Master is to guide and inspire, not to enforce some particular modus operandi. Communicate the guidance and let the Developers do the rest. Only make sure that they derive value from the Daily Scrums. There’s no one perfect template, but there are lots of ways to be effective.
Tagged with: