A lot can be said about backlog items: are they use cases? Features? User stories? Requirement documents? As far as I’m concerned there is no true answer to this question. The most important thing is that the backlog item is approachable, limited, and achievable. This isn’t very different from any project framework you decide to use. But Scrum, and Scrumworks in particular, needs task. And this is the core of iterative agile planning.

The implementation of a backlog item is the sum of it’s tasks. But tasks also serves another purpose: Tasks are small objectives that are estimated and allows developers to achieve small goals, hopefully every day. In other words, it’s important to do a good “tasking job” before implementing a backlog-item:

  1. Tasking should never be done by a single individual. Multiple views will give more information and input on how to implement the backlog item. Two people is doable (peer planning), while three people mean quality. More than three becomes a crowd.
  2. The backlog item should be fully understood. Either through up-front requirement documents but in any case through contact with a product owner or a stakeholder. Also, any architect or someone with vast experience should have some eyes on the case.
  3. Tasking is best done in a room with a whiteboard, where a telephone and a computer is present.
  4. There’s no limit to what is defined as a task, except that it should be “doable” within a certain timeframe and must be possible to complete, or set a “done” status to it. Examples:
    1. Limited, doable task: “Implement Product list GUI” might be a task that you would understand together with the backlog item
    2. Too small a task: “add header text to the web page”: this could be part of a larger GUI task
    3. Tasks that are always a part of the backlog item: “testing”. Make sure to timebox it, and add all tests in the “description” field. Also, state what automated unit tests are used
    4. Tasks that are not doable: “Plan implementation”. This is excactly the purpose of tasking! Tasks like “planning” is supposed to lead to a set of tasks. Also, planning is (hopefully) something any developer do all the time as new challenges arises. Therefore it’s not a doable task, but rather something done up front and done when implementing and should be included in any doable task estimate.
    5. Too large tasks: “Implement database layer” if this means to implement the database layer once and for all for the whole application, it’s too big a task AND it breaks with the agile through of implemeting vertically (add functionality for each feature from top to bottom).
  5. In my experience, a task should be anywhere between 3-12 hours of implementation.
  6. Implementation hours are ideal hours: the time it takes to implement the task when you sit in front of the computer producing code. Phones, e-mails, meetings, toilet visits and web browsing is not included in those hours.

The purpose of good tasking is to:

  1. Have a good understanding of what needs to be done before actually doing it
  2. Communicate efficiently to other team members what has to be done
  3. Get an early warning of impediments or external threats that must be dealt with in order to solve the task.
  4. Get a fresh (and hopefully more accurate) estimate to the backlog item (sum of tasks = backlog item)

Happy tasking!