agile - How granular should tasks within a story be? -

we've been implementing scrum , 1 of things wonder granularity of tasks within stories.

a few people inside our company state ideally tasks should finely grained, is, every little part contributes delivering story should represent task. argument enables tracking on how performing in current sprint.

that leads high number of tasks detailing many technical aspects , small actions need done such create dao component x persist in database. i've been reading ken schwaber , mike beedle's book, agile software development scrum, , i've taken understanding tasks should have kind of granularity; in 1 of chapters, state tasks should take between 4 16 hours complete.

what i've noticed though, such small tasks tend overspecify things , when our solution differs we've established in our planning meetings need create many new tasks or replace old ones. team members refrain having track each , every thing doing inside sprint , creating new tasks since means we'll have increment our total tasks in our burndown chart not adding task aggregates value.

so, ideally, how granular should tasks inside each story?

schwaber , beedle "roughly 4 sixteen hours."

the upper bound useful. forces team plan, , helps provide daily visibility of progress.

the lower bound useful target tasks, avoid fragility , costs of overspecification. however, team may find shorter tasks useful in planning, , free include those. there should no mandated lower bound.

for example, 1 of our current stories includes task send team -- task take 0 hours, 1 want remember finish.

the number of tasks in burndown chart irrelevant. it's remaining time matters. team should feel free change tasks during sprint, schwaber , beedle note.