Sprint Tasks Over 12 Hours Considered Harmful

Back when I was a programmer in traditional command and control companies I would estimate large vague tasks in days or weeks. We avoided listing granular tasks because it’s no fun having micromanagers hold us to detailed plans that invariably turn out to be wrong once the work is started. Microaccountability would impede the creative process.

In good Agile teams, the Sprint Tasks are constantly, freely, and blamelessly revised by the team. There’s also more collaboration. Your old CYA habit of hiding behind large vague tasks is unnecessary when your boss isn’t breathing down your neck. Breaking tasks into smaller chunks becomes a useful way of communicating what you’re doing with your self-managed team and a more honest way of re-estimating progress for the Sprint Burndown Chart.

(Note that Product Backlog Items are distinct from the Sprint Tasks I’m talking about here.)

If you see a pattern of tasks more than about a day long, investigate whether there are trust issues making team members uncomfortable revealing to each other what they are actually doing.

Also note that *placeholder tasks* of many hours are useful for items toward the end of the Sprint that haven’t been started yet. When you start them, break them into more granular tasks, always subject to change.

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
One comment on “Sprint Tasks Over 12 Hours Considered Harmful
  1. Michael James says:

    If you are using Sprint Burndown Charts generated by tools like ScrumWorks (the absolute best free tool for Scrum) or ScrumWorks Pro (the only commercial tool designed exclusively for Scrum) and you have a task two or more people are working on, we recommend entering the total of everyone’s remaining hours on that task. For example, several programmers working together in a room with a projector would quickly exceed an arbitrary 8 or 12 hour limit.

    Our underlying goal here is to keep tasks small, visible, and moving quickly so impediments are easily detected.

Leave a Reply

Your email address will not be published. Required fields are marked *