One interesting observation I have seen regarding Scrum at Rackspace Apps deals with task breakdowns. Breaking down a story from the product backlog is an important step to create the sprint backlog. Breaking things down into smaller pieces is going to increase estimation accuracy, as well as help the team understand all the different parts of a story.

But tasks don’t mean anything. The story is the functional piece of software the product owner requires, not any individual task. Tasks only serves as a compass for a team to track progress during a sprint. It is important to remember this and not become obsessed with task breakdowns.

With that said, how should teams go about breaking down a story into tasks? How granular should they go? Well, all teams are different, but I think I have found the general rule that works well

You are too granular when the team starts talking about the invalidity of tasks during a sprint.

Just this week, I had a team discussing how most of their task breakdown was not valid near the end of the sprint. It ended up that the story had about 3 tasks, not 6. When this starts happening to teams regularly, they need to take a step back and get less granular. Invalid tasks are a waste that should should be eliminated.

The general Scrum recommendation is 4-16 hours per task, and I definitely see anything under 4 as usually a waste. I have some teams where their breakdown is 2-3 days. It seems high, but in the end, if they are getting their stories done at a regular pace, it is fine with me.

But then again, do you even need to estimate tasks to begin with?