In the spirit of supporting empiricism and self-management, there should be no single Daily Scrum meeting template used by Developers. Such 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.
Perhaps you’re a Developer looking to improve your Daily Scrum, and you need some tips. Or maybe you’re a Scrum Master and you’ve heard that the Daily Scrum is lackluster. 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, the Daily Scrum is wasted by merely providing a checkpoint of where you are on that path. The Daily Scrum should be a place where the Developers check where they are in relation to their Sprint Goal, and find the next best step to get them closer. We can look to American Football for an example.
Imagine you’re out on the field, down by seven. There’s only minutes left in the fourth quarter. Your star running back is hurt. Your last two plays gained you nothing. It’s third and long. What are you going to do next? You need a quick huddle to determine your next move.
Just as that team huddle is crucial to figuring out what to do next to achieve the goal, the Daily Scrum is a critical micro-planning event for the Developers to create their Daily Plan. And just like the football team’s huddle is focussed on getting them closer to the end-zone (their short-term goal), a good Daily Scrum focuses on how the Developers can get closer to their Sprint Goal (their short-term goal).
Person by Person
A very common approach for most teams during the Daily Scrum would go something along these lines:
- Cari-Anne: I finished up fixing the defective Contact Form yesterday, so I’ll move on to publishing the new blog post today.
- Robb: I’m almost done with the new course registration form, I’ll keep working on that today, and then start implementing the new pre-class email template.
- Jason: I’ve made good progress on the class registration bug we discussed yesterday, but I’m stuck on the a date/time issue I can’t seem to figure out. Is anybody available to help me out?
- Greg: I should be available. I’m close to wrapping up the new course listing design. I’ll help you out with that registration bug, and then start revamping the Next Steps email if I get time today.
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, realize that it’s okay if some members occasionally have nothing major to contribute. 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?” and then making your Daily Plan from the answer to that question.
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 Scrum Guide describes the Sprint Backlog as “a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.” In other words, Developers should be able to quickly see their progress towards the Sprint Goal by looking at the Sprint Backlog.
Burndown Charts and Kansan Boards are two popular optional techniques that Developers use to visualize their progress toward their Sprint Goal in the Sprint Backlog.
Burndown Chart
The Burndown Chart is a graph with a negative slope (that is, it goes down as it goes to the right) 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, Version One. You can also make your own simple Burndown Chart using a spreadsheet.
A 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 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 resolved, either by the Developers themselves, or with the help of the Scrum Master.
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
There’s No Perfect Daily Scrum Meeting Template
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 Scrum.
There’s no one perfect template, but there are lots of ways to be effective.
Tagged with: