Very often I hear scrum standup meetings go something like this:

Fred: “yesterday I used Git bisect to find out where and when bug #1234 was first introduced. That didn’t work so I created a new unit test to reproduce it and asked Alice what the naming convention for unit tests was and…“

Stop. Do you see the problem here?

Fred is not telling me what he’s done yesterday. He’s telling me how he’s done it. He’s using up his precious 5 minutes of public airing to tell his working day in the minutest detail. And chances are, that nobody cares. At least I don’t.

I would much rather hear his tell us something along these lines:

Fred: “yesterday I wanted to fix bug #1234, which we’ve agreed was a blocking one that should take priority. It’s impossible to find out when exactly it was introduced because we have many commits that include several, unrelated changes. I’ve been working on a unit test but I wasn’t sure of the naming convention and was delayed a bit.“

See the difference? Full of valuable information for the ScrumMaster and future material for the sprint retrospective. In addition, Fred now gives some context for his teammates, explaining not only what he was doing (instead of how) but also why he was doing it, in case anyone was not clear about it.

If you’re a ScrumMaster, watch out for standup meetings that degenerate into endless lists of I did this then I did that finally I did this other thing. Explain to your team that you and your team want to know what everyone is working on, what was accomplished, and what are blocking issues. Everything else is of accidental, not essential, interest.