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#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?