Daily Scrum – Person-by-Person or Story-by-Story?

Is your daily scrum conducted person by person? Do you jump back and forth from user story to user story because people working on the same story don’t speak one after the other? Does this context switching make it hard to understand the progress of that particular story?

I think the standard, and most obvious, way of conducting the daily scrum is to simply go around the room person by person. But, there is another way – going story by story through the sprint backlog.

I have tried both ways. When I was new to Scrum, it just seemed obvious that you would go around the room. This method will probably work fine for small teams or teams who take on a small number of user stories in their sprints. In other words, if there isn’t much context switching in the scrum, then going around the room should work fine.

But as your team grows the opportunity to switch context back and forth between stories will grow. And this is where the second scrum method, going story by story, can help.

With this method, you’ll ask who is working on a particular story and those team members will answer the scrum questions. That way you get a full picture of the progress on that story at once. Mike Cohn describes it this way:

For some teams, conducting the daily scrum by product backlog item can make much more sense than going person by person. When going item by item, someone on the team (often the Scrum Master) says, “OK, let’s talk about this product backlog item next. Who worked on it yesterday? Who is going to work on it today? And is anyone stuck on anything to do with this item?” When a team conducts its daily scrums this way, there is less lost context.

I used this method for a large Scrum team and everyone preferred it over the person by person method. However, I did notice some problems that you need to watch for.

The first was that the scrum can become mini status reports for each story. Because you now have multiple people talking about a story, it can be tempting to drill into details. Instead of each person answering the scrum questions and moving on, a discussion can start. So be careful about that and if necessary remind people to avoid status reports.

Another potential problem can occur if some team members are working on multiple stories. Those team members will have to get accustomed to only talking about the story being addressed instead of all their stories at once.  This isn’t a huge issue as long as they stay focused on the story currently being addressed.

Have you tried the story by story method? Let me know how it worked for you.


Scrum Master Mistakes

We all make mistakes as Scrum Masters. As we say “Scrum is easy to learn, but difficult to master.” We do our best and learn from our mistakes.

Mike Cohn talks about some mistakes he sees in his blog post “Three Mistakes Scrum Masters Make and How to Correct”.

I could have guessed the first and third mistakes he writes about. But, the second surprised me. Basically, Mike says the Scrum Master should not run the daily scrum.

I definitely have a take-charge personality and I do keep the daily scrum moving along by calling on people. And I think Scrum Masters need a leader personality in order to encourage the team to follow the Scrum principles.

I understand the desire to have a team which runs the scrum itself, but I’ve always seen my role as a facilitator. Now, I’m not trying to take over the scrum, but I’m making sure it doesn’t bog down, instead of being a silent observer. I regularly remind team members that they are sharing information for the benefit of the team, not for the benefit of the Scrum Master. Also, each Scrum team I’ve been on has had some remote members and calling on people was necessary at some point during the scrum.

However, I can see that a more hands-off approach will help the team become more independent and self-reliant. So this is something I will work on. I’ll ask the team to start the scrum and give the input without being prompted.

I can see another possible benefit. I mentioned earlier that the information shared in the scrum is for the benefit of the team itself. I tell my teams that the scrum’s purpose is to plan the work for the day so it supports the completion of the sprint goal. Although, I struggle to drive that ideal home to some team members. Sometimes input for the scrum can be too brief and not very helpful, or sometimes it’s more like a status report. Maybe a more team-driven scrum will help improve on this.

Let me know your what you think and what works best for you.

Focused Standups

If you are a fan of The Walking Dead you know that Rick’s group (the main characters of the show) ask strangers three questions before allowing them into the fold. “How many walkers have you killed? How many people have you killed? Why?” All prospects must answer these questions and they help Rick’s group determine if someone will be a valuable addition. This is important in the apocalypse.

Our daily standups shouldn’t resemble the apocalypse, but we also answer three questions. “What did I do yesterday? What am I going to do today? Do I have any impediments?” These questions help our Scrum team understand if we are moving forward at a reasonable pace and if we will successfully complete the sprint.

Each team member should stay focused on the three questions during their turn. This helps keep the standup effective and short. Everyone is empowered to remind team members to keep the standup on track and to the point. Don’t assume this is the sole responsibility of the Scrum Master or team lead. If someone is going off in the weeds, politely ask “Can we discuss this more after standup?”

During my turn in standup, I try to limit what I say and use the following format:

  • Yesterday I worked on / completed [task/story].
  • Today I will work on / complete [task/story].
  • I do/don’t have an impediment [which is …].
  • I need to talk more about [some topic] with [some people] after standup.

In my opinion, the last statement is just as important as the three questions. Make a habit of including it when you have more to discuss and your standups will be shorter. Waiting to have additional discussions after the standup will allow people who aren’t involved in the discussions to go back to work.

If your Scrum team is properly sized, then it should only need 15 minutes for standups. But if the standups regularly last longer, encourage everyone to use the format above. Post it on the wall if needed. If that doesn’t work, consider time-boxing the standup. When 15 minutes are up, standup is over and it’s time for additional discussions. Overtime, team members will learn to keep their input to the point.