Intro

Several teams now use burn down charts to track the progress of their work, so that they can see when they are falling behind, and decisions such as "this blueprint needs to be postponed" can be done as early as possible.

What is a work item?

A blueprint describes an entire goal or project, can sometimes take many weeks to complete, and can need more than just one person to implement it. For efficient tracking, these need to be broken down to several steps, each of which should not take more than two days. Items which need longer should be split either logically, or if that's impossible, artificially like "do something 1", "do something 2", etc.

One work item has :

• precisely one assignee who is responsible for it
• a status (todo, done, postponed)

Defining work items

Two methods of adding work items to a blueprint are currently supported: they can be added by linking bugs from the blueprint using the Link a bug report link, or by recording them in the blueprint's whiteboard. Where applicable, linking to a bug is preferred because this permits integration with the full package and bug management workflows and doesn't require any editing of the blueprint whiteboard to update status. However, some work items don't map well to bug reports on packages, so both methods are supported.

Work items in the whiteboard

The start is indicated by a line "Work items:" (anywhere in the whiteboard), then exactly one line for each work item, and finally an empty line to end the work item list. Each work item is one line with the description, then a colon, and the status, and optionally has an assignee prefix (which should be the Launchpad account name) in square brackets:

• Work items:
  package gnome-monster: DONE
  write gnome-monster MIR: TODO
  [seb128] patch gnome-monster to support green monsters: POSTPONED
  
  pitti, 2009-11-27: can you please clarify the precise shade of green for the proposed patch?
  [.. further whiteboard discussion here... ]

Valid states:

(capitalization does not matter)

The default assignee for a work item is the blueprint assignee. Use the [assignee] description syntax for blueprints where several people are involved.

Please see desktop-karmic-network-ui for an example.

Work items as linked bugs

Each bug linked from a blueprint will be inspected, and each Ubuntu task on the bug, either on an Ubuntu package or on the Ubuntu distribution (no package assigned), will be treated as a work item, with two exceptions:

• Tasks with a status of 'Invalid' are ignored and not treated as work items.
• If a bug includes tasks for multiple distroseries, only one work item is generated for each source package. If a task is present for the current devel distroseries and is not marked "Won't Fix", that task's status will be used; otherwise, the task not qualified by distroseries will be used.

Milestone targets and assignees are taken from the usual bug task fields.

Task states are derived from the bug status, as follows:

Setting up blueprints

For work item tracking to actually work, blueprints need to

• have an assignee (unless all of the work items explicitly specify one)
• need to be targetted to a particular distribution release (this is both a good tool to postpone blueprints later on by untargetting, and also avoids work item scanner exploding on trying to scan a gazillion blueprints)
• can optionally be targetted to a particular milestone, if the development cycle is divided into several subcycles
• The whiteboard can have a separate "Status:" area, which describes the overal status in more detail. These are copied verbatim to the "status" column in the generated report. As with work items, the status area ends with an empty line.

Subcycle tracking

For Lucid, we started to divide the entire development cycle (6 months) into three smaller phases (alpha-2, beta-1, final), and thus started to create milestone specific reports, too. For blueprints which can't/are not meant to be finished within one subcycle, it is recommended to split the work items in several blocks, each with a Work items for lucid-alpha-2: like heading. The milestone name must be exactly like in Launchpad (i. e. not Alpha 2, a2)

For a full cycle report, all blocks which match work items.*: are counted. (Capitalization is irrelevant)

Example:

• Work items for lucid-alpha-2:
  package gnome-monster: DONE
  
  Work items (lucid-beta-1):
  write gnome-monster MIR: TODO
  
  Work items:
  [seb128] patch gnome-monster to support green monsters: POSTPONED

If there is no (valid) milestone in the work items.*: line, they will be assigned to the milestone of the entire blueprint. Thus, if you do not have work items spanning across several subcycles, using "work items:" and properly milestoning the blueprint will do the right and intuitive thing.

Reports

The current reports are generated hourly by team, release, and milestone on http://people.canonical.com/~pitti/workitems/. If you want to use those scripts by yourself, or do custom SQL queries, you can also download the current sqlite database.

Generator scripts

The launchpad-work-items-tracker project contains scripts to process those work items and generate reports:

• collect scans blueprints of a particular release and puts them into a database, which stores the status of all work items on every date, spec status/descriptions/priority, milestones, and team structure.

• html-report generates a HTML report with a by-blueprint, by-assignee, and by-workitem list.

• burndown-chart generates a burn down chart.

• generate-all iterates over all available milestones and teams and builds reports and burndown charts for all combinations.

The configuration for a particular report set is kept in a single file. See config/lucid.cfg in the bzr branch for an example of the Canonical team report for the Ubuntu Lucid release. These reports are generated with

•  ./collect -d ~/public_html/workitems/lucid.db -c config/lucid.cfg
   ./generate-all -d ~/public_html/workitems/lucid.db -c config/lucid.cfg -o ~/public_html/workitems/

Please contact Martin Pitt for questions, or if you need to change the configuration and cannot commit to the branch yourself.