I recently described the Work Item List. The second type of artifact used in an Agile Work environment is the Task. At its most basic, a Task is a simple description of how to do some bit of work towards completing an item in the Work Item List. However, there are some important things to remember when using Tasks.

What is a Task

Normally, an item from the Work Item List is broken down into multiple Tasks. These Tasks are all the things that need to be done or built to get the item into a deliverable state.

In general, the process of creating a bundle of Tasks for a given Work Item is a design or analysis process. It is a problem-solving process. The Tasks themselves represent the solution: the building blocks of the structure of the Work Item. Tasks do not normally represent the problem solving or analysis process.

Here are two contrasting (somewhat contrived) examples of Tasks generated for a “Home Office Addition” to make this clear:

Example 1 Bad:

• determine requirements for home office
• design home office layout
• check home office layout with client
• choose furniture and decor
• build home office
• install furniture and decor
• unpack books and files into home office

Example 2 Good:

• 300 sq. ft. maple hardwood
• 4′ x 7′ custom desk
• Aeron chair
• red leather sofa
• 16′ custom bookshelves
• 22″ double French doors
• 8′ 4-panel vinyl triple glaze bay window
• 36 2x4x10′ metal studs
• … drywall
• … other building materials and furniture and decor

Generating Tasks

The whole team works together to come up with the Tasks for every Work Item being worked upon during the iteration. The majority of the Tasks are determined during the timeboxed iteration planning meeting. Sometimes, the iteration planning meeting is not long enough to get all the Tasks defined. Sometimes new Tasks are discovered during the course of the iteration. Either way, it is fine to make changes to the bundle of Tasks as the work proceeds.

Special Tasks

Due to the timeboxed nature of the iteration planning meeting, a Team will sometimes find itself knowing that there is more analysis or problem-solving needed for a given Work Item. In this case, a special Task can be created to indicate that this analysis work needs to be completed. For example, the task might be labled “Finish analysis for Work Item 62”, or it might say “Team meeting to finish Task generation for Work Item 62”. Other ways of writing these Tasks include “Research…”, “Solve…” or “Discuss…”. Everyone needs to recognize that these tasks represent risk and uncertainty about how to get the work of the iteration complete.

Sometimes work needs to be done that is outside of the control of the Team. The Team should always try to find creative solutions to avoid this situation, but it is almost inevitable that Tasks will come up for which the Team does not have the expertise or the authority. These Tasks need to be treated very carefully since they can seriously hinder a Team’s forward progress. The Process Facilitator should usually consider these Tasks as obstacles to be removed.

Working on Tasks

Typically, a single person takes responsibility for a single Task at a time. A person may end up working on other tasks for two reasons. First, if the Task he/she is responsible for has an unavoidable wait, then that person may go find someone else to assist until the Task is ready to be worked on again. Secondly, another person may have an urgent need for assistance and call other people away from their current Tasks.

Tracking the Work

In their most basic form, Tasks are assumed to all be roughly the same size or effort and small enough that they are only done or not-done. Therefore, tracking the work on the Tasks throughout the course of the iteration is kept very simple: how many tasks are remaining to complete in the remaining time of the iteration? There is no ambiguity: Team members report on completion of tasks to the Process Facilitator who updates a burndown chart to show the quantity of remaining work.

Gotcha’s

Tasks must be written to avoid including wait time. For example, a Task that says “Get the parts delivered” actually includes three steps: make the request for the parts, wait for the parts to be delivered, receive the parts. Since it is often hard to predict how long a “wait” will be, it is important to break this down into two separate tasks: “order the parts” and “receive the parts” and then treat the wait time as an obstacle to be removed/minimized.

Affiliated Promotions: