Guidelines to run a daily“scrum” meeting

Figure 1: How often does your daily meeting sound like it could easily be a status report email including the whole team?

For firstcomers, a stand-up daily scrum meeting (or just “daily”) is a 15 minutes long meeting aiming to bring everyone on the same page, identify blockers and take strategic actions if required in order to accomplish the team goals (usually the sprint goal).

This meeting usually revolves around 3 main questions: “What did we accomplish? What do we plan to do? Is there anything blocking us?”. Over time this meeting may become very robotic and lose its strategic value.

In this article I propose a method to run this meeting and optimize it taking away the “why isn’t it an email? feeling”. If you are short on time, the main idea is summarized by keys questions related to the work process (hint: kanban columns) and tracking the speed in which the tasks are transiting in the process.

Scrum Daily — Focused on sprint goals

Even though it is mostly common in a “scrum environment”, this meeting may occur at any kind of project (waterfall included). In this section we will consider the context of a team focused on the sprint goals. A very useful tool to bring insights on the sprint health is the burndown chart, as exemplified below.

Figure 2: This burndown chart accounts the remaining cumulative story points over time. We use story points to estimate the effort, if you want to know more about burndown chart, please click here. At every step down, the team finished a story. This image is a burndown chart from a real world scenario. During many sprints to come this team would obtain a similar chart.

In this chart you can clearly see a plateau, it means the team was not able to conclude the stories. A major reason relies on the fact that everybody was working simultaneously at different things, which took longer to finish, hence the plateau. Most of these unfinished stories would be concluded on the early days of the next sprint, as you can observe happening in this chart as well. In this scenario, you are running a high risk of not delivering value for your stakeholders at the Sprint Review… This may trigger a long list of undesirable side effects, which we shall discuss another moment…

5 questions of doom

During our sprint retrospectives, we oftenly complained about how our meetings were lasting too long and our constant lack of focus. Well, if everybody is looking at different things, how can we require focus anyway? In order to address this issue, we came up with 5 questions to be answered during our dailies:

1. What can be accomplished today?*
2. Is there any hidden work (usually unplanned tasks not included in the sprint backlog) or anything slowing us down?
3. Is there any story we may not deliver at the end of the sprint? **
4. What is the best strategic move we can take as a team?
5. Is our team goal for today clear to everyone?***

Side-notes:
* By “accomplished”, we may consider the story itself or may be the tasks related to the story. This will depend on what is bothering you the most: are there tasks taking too long to be done? Are the stories taking too long to meet the definion of done? This will depend on the moment and the story itself…
** Ideally, these should be the least important stories.
*** This question may not make sense if you focus on a specific story. Leave it as the last question to define the end of the metting.

After adopting these questions, in a matter of months, our burndown chart started to look a bit more like the one below:

Figure 3: Meanwhile this is still far from ideal, this chart depicts a team with a complex unplanned work emerging during the sprint, however still able to deliver value continuously

Differently from the previous scenario, in figure 3 our plateau is at the early stage of the sprint, followed by a negative slope. As a member of the team at that very moment, the methodology partned with a constant burndown chart analysis provided useful insights into the better strategy to accomplish the sprint goal. As soon as we realized we were at a plateau, our five questions proved to be very powerful method to guide the team in the best moves to ensure a constant delivery of value.

Story-based vs Person-based sprint backlog

Figure 4: The sprint backlog reflects the work in progress and it can be assembled in many ways. In this figure we represent the two most common scenarios.

The sprint backlog is another extremely useful tool to be used during a daily. What is the right way to display your sprint backlog? Answer: The one fits you the best. I will quickly describe my experience with both models.

Story-based backlog: In this model we should consider the first story at the top (in our case: story 1) as the most important story in the sprint. Following this model, it gets easier to spot wheter you can stop the least important tasks and allocate the team to focus on what is our currently the main priority. As a thumb rule, you could iterate over the stories in progress and run the “5 questions of doom” for each. If your daily is getting longer than 15 minutes, it may be a sign you have too many stories in progress. As the team finish stories, they may start to work on other stories. If the sprint ends and any story is not done yet, at least we made sure it is not the most relevant.

When applying this method, a reasonable side effect may come in place: you can easily lose track of what a specific individual is doing. This is useful to avoid micro-management, as you can also consider some members of the team may act in a transveral role among the team. But bad apples are everywhere, indeed it does open a precedent for team members who tend to overly “work in pair”, “analyze shady things” and indeed may not be delivering most of the value to the project…

Person-based backlog: In short, this model loses most of the positive aspects from what was pointed before. So why taking this approach? In some projects you may have people playing very different roles and they are partaking in the daily meeting. You cannot just simply ignore their presence, as they are also a part of the team. Even though they have different roles, ideally they should be focused on the same project. What is the best we can extract from this scenario? In this approach we let other members understand what everybody is actually doing, which may be insightful in some contexts.

For this model to work properly, those five questions might be adjusted a bit in order to better fit to the team reality, which might depend on the member roles. For example, you can change “what can be accomplished today?” for “which deal can we close today?” or “Did any lead become a client today?”. This will depend mostly on the roles present in the team.

As a personal suggestion, which may be the best from both worlds, I recommend applying the story-based backlog method, apply the questions for each story in progress and right after, turn the 5 questions to the team members who were quiet during the entire meeting. This may work as a provocative way to force engagement meanwhile maintaining focus on the priorities. But can also bother some people. Be careful. This guideline may not work in your context, take this article as a handful of ideas to turn your daily meetings better.