The team I’m working with now ran into a situation last week that started me thinking about this issue again. The team is new, in its second sprint. In our initial team-formation gathering, we created a working agreement, and someone proposed, without being cued, that each team member update the time remaining on their current task before standup every day.

As ScrumMaster, I’ve been drawing the burndown chart by hand each morning, five minutes before standup starts. Last Thursday, after we started standup, someone said: “Hey! The burndown is wrong; we finished these two tasks.” I said, “Congrats on that! Tomorrow’s burndown will be more accurate.”

I’ve noticed that in the days since then, tasks are updated dynamically during the day.

Why did this work? It might be because our burndown chart is very visible to everyone in the company, including senior management, and because everyone on the team is aware that this project is one that’s being watched by their coworkers. So maybe they care about the burndown being right more than a team that’s got two dozen sprints under its belt. I don’t know; I’ll let you know what happens when this team is into Sprint 10…

Cheers.

+ Michael

I don’t want to come across as dogmatic on this issue (goodness knows there is enough of that around already) so I’m glad that you have inspected and adapted and your teams are successful.

I think it would be a shame if we got into the habit of the ScrumMaster always doing this.

We used to take our best technical leaders, make them project managers and bury their beautiful minds under the burden of a team’s administration. We certainly don’t want to repeat that mistake with our ScrumMasters.

With a team that does not see the value in updating the To Do hours it might be interesting to discuss the impacts at the retrospective. Perhaps this discussion may lead to an innovative change in the team’s process.

I’m not a fan of the parent-child metaphor when describing the relationship between ScrumMaster and team. I understand the point you are trying to make but to me that relationship is somewhat patronizing.

Regarding the practice of capturing time remaining on tasks: my tip was based on spending extended periods of time with many teams. My suggestion is very much that team members do update their individual task time remaining but rather than expect them to enter them in an electronic system, just communicate it verbally to a “human” system. In my experience, the interaction goes something like this:

ScrumMaster: “Hey John, you got a minute? I’m trying to get the burndown updates and I see on the taskboard that your name is on these three in-progress tasks. How many hours do you think you have left and is there anything you need or any way I can help?”

(I never ask how much time has been spent on a task – I find that useless.

I’m not sure what you mean by making a team-member less *accountable* to the number or why accountability to a number is important, but I don’t see how the interaction above would do so.

Likewise, I’m not sure how this in any way impacts the mindset of the self-organizing team. Nor do I think the team becomes any more dependent on the ScrumMaster than they are on any other team member.

“The ScrumMaster becomes frustrated and disillusioned” – I have not observed this. I’m not saying ScrumMasters don’t get frustrated but I don’t think this is the cause.

Ken, I agree in an ideal world all team members would happily update their own time. Unfortunately in my experience, this degrades into a ScrumMaster whining daily for people to update their hours. “…don’t forget to update your hours”…”did you update your hours?”….”c’mon guys, update the hours” (somewhat parental in tone too).
Given a choice, I would far more prefer a team update its own hours – just like you suggest. I’ve seen it done very successfully directly on a task board. But in order for even this to work, *everyone* on the team has to willingly do it all the time. Everyone has to buy-in to the value of the hour-update. Trying to get 100% of people to buy-in is a big mountain to climb and I would opt to fight other battles elsewhere.

Giora

Please don’t stretch the analogy too far, it would be a shame if you thought I was suggesting development teams are immature, I’ll leave that to Scott Adams.

So how do we get our teams to update their hours remaining? Well if it is valuable then there will be an impact. So as a ScrumMaster you might want to let the team fail a sprint so the team can inspect and adapt. Just make sure you have regular retrospectives.

Of course, don’t use the inspect and adapt technique for teaching your kids to cross the road or take care of their teeth.

At home we use Love and Logic as a parenting approach and it tends to find its way into my leadership approach at work too. But, don’t tell anyone;) It is all about teaching responsibility through empathy and consequences. I highly recommend it.

In Jim and Charles Fye’s work, they would say something like this to a six year old: “I can play Lego’s with a guy who cleans up his room.” This tells them what you will do.

Since you are trying to gain responsibility in your team, a Scrum Master, I might say to an agile team: “I can facilitate planning meetings for a team that updates their remaining numbers”

I also like to call those “I trade ya’s.” I will give you something, if you give me something. I find putting them in the “I will” form is much better than a direct order like:”Pick-up your room.” Thought from a constantly learning parent!

In a small team with a small scope system with limited dependencies, it doesn’t matter because the deadline is the deadline and some piece of …. is going to ship regardless of the quality or issues.

In an enterprise environment with integrations, dependencies and across teams, allowing developers to hold their breath until they turn blue ;-) is a very bad idea.

I agree with you! I am discovering that team complacency can be a huge factor in agile adoption failure. (I guess I need to update my list of 12 failure modes to 13!) The less the team owns, the more complacent they can become. So, part of buying into and embracing the Scrum process is believing in the power of reporting your personal commitments and what is left to do on them. Daily. Without this, the ScrumMaster starts to look and feel like a traditional Project Manager “owning the schedule” IMHO.
Thanks,
Jean