How granular should tasks within a story be? [closed]

Question

We've been recently implementing Scrum and one of the things we often wonder is the granularity of tasks within stories.

A few people inside our company state that ideally those tasks should be very finely grained, that is, every little part that contributes to delivering a story should represent a task. They argument that this enables tracking on how we are performing in the current sprint.

That leads to a high number of tasks detailing many technical aspects and small actions that need to be done such as create a DAO for component X to persist in database. I've also been reading Ken Schwaber and Mike Beedle's book, Agile Software Development with Scrum, and I've taken the understanding that tasks should really have this kind of granularity; in one of the chapters, they state that tasks should take between 4 to 16 hours to complete.

What I've noticed though, is that with such small tasks we often tend do overspecify things and when our solution differs from what we've previously established in our planning meetings we need to create many new tasks or replace the old ones. Team members also refrain from having to track each and every thing they are doing inside the sprint and creating new tasks since that means we'll have to increment our total tasks in our burndown chart but not necessarily adding a task that aggregates value.

So, ideally, how granular should tasks be inside each story?

Answer 1

Schwaber and Beedle say "roughly four to sixteen hours."

The upper bound is useful. It forces the team to plan, and helps provide daily visibility of progress.

The lower bound is a useful target for most tasks, to avoid the fragility and costs of overspecification. However, occasionally the team may find shorter tasks useful in planning, and is free to include those. There should be no mandated lower bound.

For example, one of our current stories includes a task to send something to another team -- a task that will take 0 hours, but one we want to remember to finish.

The number of tasks in your burndown chart is irrelevant. It's the remaining time that matters. The team should feel free to change the tasks during the sprint, as Schwaber and Beedle note.