One Word Can Change Your Daily Scrum

In my experience, the daily Scrum serves two purposes:

  1. for team members to make and follow up on commitments to one another, and
  2. for team members to raise and start resolving impediments.

Both these purposes are directed towards reaching the Sprint goal.

I started coaching a development team in an IT department this week. Most of the team is officially full-time on their project, but unlike the consulting teams I often work with, no one is ever really full-time on a project. There are production apps to support, people management issues, requests for technical help from other projects, non-project meetings, and a variety of other distractions.

Observing this team’s daily Scrums, I noticed that they talked a lot about what they did in the past 24 hours and what they would do in the next 24. Everyone seemed busy and could account for their time. But I had a hard time connecting their busyness to the work they’d committed to do in the Sprint.

So, I suggested a slight change to the three questions that I learned from Mishkin Berteig. Instead of answering the questions, “What did you do in the last 24 hours?” and “What will you do in the next 24?,” I had the team answer the questions, “What did you complete in the last 24 hours?” and “What will you complete in the next 24?” I recommended that they point at tasks and stories on the task board while answering the questions to keep them focused on the work for the Sprint.

There were some objections:

“But I’ll feel uncomfortable saying I’m not going to complete anything today…” To which I say, “Good. You should feel uncomfortable if you’re not helping the team follow through on its commitment for the Sprint.”

“But our tasks are too big to complete in a day…” “Many of them are. This will give you an incentive to make them smaller in the next Sprint, which will increase your visibility into the state of the work.”

Nonetheless, they agreed to try it, and I’m glad they did. The change in the daily Scrum with the new questions was striking. Conversation was more focused on their commitments. Since team members couldn’t use work from outside the project to show how busy they were, they were motivated to fight the distractions and find project tasks they could commit to. The few team members who are spread across multiple projects now can see clearly where the multi-tasking is hurting their commitments to this team.

If your daily Scrums seem unfocused, even though everyone has lots to talk about, consider changing the questions to change the team’s behavior. Just one word can make a big difference. Try asking each other:

  1. What did you complete since we last met?
  2. What will you complete before we meet again?
  3. What impediments are keeping you from completing something?

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Good tip. I’m going to bring this up with our Scrum master, Schmidt. The application developers are usually pretty on point, but our architect and DBAs often rattle off several items that were worked on but not completed in a given day. And the DBAs always have distractions to report that they feel justifies their lack of work completed for the Sprint goals.

  2. I see that pattern, too. The more senior you are, the more likely you are to have work outside of one team’s sprint goals, therefore the greater need to justify your lack of direct contribution to DONE. On the team I wrote this post about, I didn’t change the language because of the interns…

  3. Great post, Richard! I have often struggled with getting teams (especially those new to the agile paradigm) to have effective stand-ups. They often direct their “reports” at the PM/Scrum-master/Coach rather discuss with the team in general, and the stand-ups become a rote exercise, just something that gets done as part of the process. I’ll try this tweak and let you know how it goes …

    P.S. Looking forward to how things progress in your new venture.

  4. Interesting approach.

    I love the idea that our stories should be small enough that failing to complete them in single-day work increments should not be a common occurrence. But the one potential hang-up or loophole I see here is the blocking criteria. Do you ever have status reports that are “I failed to complete X and i am blocked by the fact that there is not enough time in the day.”

    I can see where such a report would be valuable if it is interpreted as an issue with the story size rather than with the lack of alacrity with which the reporter is working.

    • @Adam – The items under discussion in the Daily Scrum are typically tasks, not stories. No matter how big a story is, it should be possible to decompose the work into tasks of less than a day each.

      The point of changing the questions is to surface issues and impediments early rather than hiding them behind, “I’m still working on X.” I haven’t yet seen this interpreted as the person working too slow. Teams seem to get the point and focus on either finding the issue that prevented the task from being completed or making their tasks smaller.

  5. I have nade that suggesion a number of times but the SM and team continually commit to stories that are too large and the tasks are not as well understood as they should be. So the members really can’t say ‘ I completed ….’ We have 5 hours tasks that go on for 3 days, Its very frustrating to see bright people struggle.

  6. Laurence’s suggestions are really valuable. We also apply “completed” instead of “worked on” as best practice.

    Another best practice we apply is talking about stories completed not tasks (of user stories) completed. As a team we agreed that we can’t have more than N stories in progress, therefore any activity related to other than the top N stories is a sign for losing focus.

  7. That’s a helpful tip Richard. Often teams tend to get into technical discussion, especially with Architects and DBA’s around. Adding the word “complete” will definitely set the right targets and get teams more focused on achieving completion of assigned tasks.
    Also, as said it is preferable to target completion of tasks rather than target completion of user stories. Though completion of user stories is the end goal, but on a daily basis we need to work on smaller goals that are completing the assigned task. For that matter, we are now focusing on breaking user stories into granular tasks that are easy to track and give clarity on the work that needs to be accomplished.

    Thanks.

  8. Spot on, Richard! And all too common. With the end-goal being delivery of business value (“What did you complete for me lately”?), the prevalant “working on” is neither SMART nor of any value. Further, it is neither transparent, measurable, nor collaborative. I routinely coach team members (core and external) the value of focusing on what got done, what will get done, and what needs moved so I can git r done. It’s like a daily scrum of cyclists: why would they value huddling up daily to hear, “…rode yesterday; going to ride again today; no obstacles”?! Normally we are all “working on” something; everyone is “pedaling”. Imagine plotting directions on Google Maps from destinations “here to there”! It would not compute. We need to plug in specific from and to destinations. Just like in the daily scrum.

    Thank you for this article.

    @JBoRice

  9. I really like this idea BUT my team pair program a lot (something I am a huge advocate of), often they will talk about starting something or finishing something within a stand up/scrum and someone else will say “hey Ill pair up with you on that” and if we limit to only talking about completed or completing Im wary that we may miss out this, comments? ideas?

Richard Lawrence

Is co-owner of Agile For All. He trains and coaches teams and organizations to become happier and more productive. He draws on a diverse background in software development, engineering, anthropology, and political science. Richard is a Scrum Alliance Certified Enterprise Coach and Certified Scrum Trainer, as well as a certified trainer of the accelerated learning method, Training from the Back of the Room.

Connect

richard.lawrence@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author