Scrum Tasks As Done or Not Done

Tobias Mayer has a great post on modifications to the standard Scrum that have worked for him. One of these is the idea that tasks are not measured in hours:

Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such. This approach serves two purposes: firstly, ease and accuracy of burndown (burndown on tasks rather than hours, making the whole process binary: a task is done or it is not done) and secondly it raises impediments which developers themselves may not see. For example, an incomplete task may be in that state because a developer was called off into some long and meaningless meeting, but because “that is the way we work around here” this is not seen as an impediment. Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.

Nice to know I’m not alone on this idea of trying to get away from a focus on the exact hours for a task. If all of the tasks are a day or less, tracking becomes simply done or not done. We haven’t used this approach formally on any Scrum projects, but I may bring it up at a retrospective and suggest to a team that they might try it out for a Sprint. I also really like the idea of having a burndown chart that tracks number of tasks completed rather than hours.

The whole point is are you getting the backlog items, aka features, done or not. The tasks are just some of the details on how you get there.