Home > Ketura > Tour > Step 3: Tasks

Ketura Tour Step 3: Tasks

  • Screenshot showing the task list for an issueAn issue captures what needs to be achieved, but it doesn’t of itself describe how the issue will be resolved or who would do the work.
  • To address this, tasks are added to an issue for each work item that needs to be completed for the issue to be resolved.
  • The tasks for an issue thus form a mini ‘to do’ list for the issue.
  • Each task is assigned to a particular person, or it can be unassigned if it hasn’t yet been decided who will do the work. Tasks can be reassigned if necessary.
  • The system keeps track of several work values for each task: work done, work remaining, planned work.
  • Work done is the total amount of work that has been undertaken on the task thus far.
  • Expected work remaining is the estimate of how much work there is left for the task, made by the person to whom the task is assigned. This figure is automatically adjusted by the system as work is done on the task, but can (and should) be revised by the task’s assignee at any time if his or her expectations change.
  • Planned work is the project manager’s estimate of how much work should be needed to complete the task, typically based on an initial expected work remaining estimate made by the task’s assignee. The system uses this value and compares it to the total of work done and expected work remaining, making it easy for the project manager to see when a task, issue, milestone or project is in danger of requiring more work than originally anticipated.

The task list for an issue thus lists all the people that will do work to complete the issue, and the sum of the work estimates for the tasks gives an estimate of the total amount of work needed to deal with the issue.

Examples of tasks

A software company using Ketura might create an issue if a customer reports a bug in one of that company’s products. But what work needs to be done to fix the problem? A task is added to an issue for each work item. Typical tasks for fixing a software defect might include:

  • Identify the scope of the issue and estimate how much work will be required to fix it;
  • Fix the problem;
  • Update the issue with a description of the changes undertaken;
  • Update any product documentation affected by the issue;
  • Test thoroughly to ensure that the issue is fixed;
  • Have a colleague perform a review of the changes undertaken;
  • Submit the changes to the source code repository;
  • Record the issue as being complete by changing the issue’s state to ‘Resolved’.

Note that you could just have a single task for the issue, called something like ‘Fix the issue’. Indeed, that might be appropriate for some types of issue. But, using a list of tasks like the example given here has several potential benefits:

  • The work required, and the people who will do it, can often be described more accurately using several tasks instead of one. This makes it easier to estimate the amount of work required and helps Ketura to give more accurate schedules for a project containing the issue.
  • Many organizations will wish to define set procedures for dealing with issues. These procedures can be described using tasks. When someone finishes a task, he or she marks it as complete, thus indicating formally that the procedural step represented by the task has been completed.
  • Many issues require work by several people. The only way to describe this in Ketura is by using different tasks, each one assigned to a particular individual.

Task sets

Most organizations will find that they end up with a few different sets of tasks that they wish to use over and over again. Such lists of tasks can be stored as task sets in Ketura. All the tasks in a task set can be added to an issue in a single operation. It is also possible to have Ketura add a task set to an issue automatically when an issue is created or changes its state. This is discussed further in Ketura Tour Step 8: Workflow.

Continue the tour