Estimating Tasks and Management’s Role in Scrum

Here’s an interesting question that just came in from a local scrum master. It’s about estimating tasks and management’s role in choosing the practices that a scrum team uses.

Question

Chris,

The team I am working with wants to do an experiment where they will stop estimating task in hours. Their sprint burn down will be then tasks vs. days instead of hours vs. days. The team believes that they will be successful with this and they are also thinking of creating an initial working agreement for this experiment e.g. any task that will be added will not be longer than a day of effort.

I am supporting this but somehow I have failed in explaining and convincing management. They want me to explain the benefits and the purpose of this experiment. They point to scrum books that say tasks should always be estimated in hours and a burn down chart can only be shown using hours. How do I convince management to allow the team to proceed with this experiment?

Answer

Your team is on the right track in moving away from task-hour estimates. We used to think that estimating tasks in hours was a useful practice, but over time, we have learned that it causes more harm than benefit.

One of the issues is that we never find all of the tasks during sprint planning. There will always be tasks that get discovered after we begin the work, lots of them! The very best teams I’ve worked with can find about 60% – 70% of the tasks during planning, and those are the best teams.

When we start looking at estimated hours, we get a false sense of certainty and we start making bad decisions based on that. One common bad decision is to do “capacity planning” where we make sure there are “enough hours of work” for everyone on the team. This is a terrible idea! What happens when we discover the tasks that we didn’t know about during planning? If we planned ourselves “full” we are now seriously “behind” just because of our use of task hours and capacity planning.

My only suggestion for your team is to go for even smaller tasks. I generally recommend that tasks should be small enough that they feel like no more than 3 hours of work. I don’t want to know how many hours of work; I just want the binary answer to the question: Does this seem like 3 hours of work or less? If the answer is yes, we are good. If the answer is no, then break it down some more. The reason is that breaking it down helps us better design how we will do the work.

You may also want to explain to your managers that one meta benefit of the experiment is that the team learns that they are free to experiment and improve. That’s really key to scrum: the development team owns how the work gets done. With that ownership, comes empowerment and also responsibility for the outcome. Management doesn’t need to be convinced to let the team try this experiment; management needs to be convinced that it’s the team’s job to continually improve their practices and management’s job is to create an environment where that can happen.