Work item tracking

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

Right now, the preferred and easiest method is to add work items to a blueprints' 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.

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 mention the current work items in "Work items:", and store the previous/future ones in a separate block, so that they don't get picked up by the scripts. Example (suppose we are in the beta-1 cycle):

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

Then you just need to rename the heading when a new cycle starts, if you (a) don't want to carry over the "DONE" ones from the previous phase, or already want to plan ahead for the next phase.

Reports

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

• workitems.py scans blueprints of a particular release, name pattern (desktop-lucid-*), and optionally, milestone, and puts them into a database, which stores the status of all work items on every date. It is capable of generating a HTML report with a by-blueprint and by-assignee list, and text/CSV/raw dump outputs.

• burndown-chart.py generates a burn down chart from CSV data as produced by workitems.py.

The current reports are generated hourly by team, release, and milestone on http://piware.de/workitems/. The most interesting file is report.html which combines the textual reports with the chart (e. g. see the desktop team's karmic report), but if you want to use those scripts by yourself, you can also download the current sqlite database from those directories.

E. g. the current desktop and mobile alpha-2 reports are generated with those commands (please note that the desktop one additionally pulls work items from a wiki page):

• 03 * * * * workitems.py -d data/desktop-lucid-workitems.db -r lucid -p 'desktop-lucid-' -m 'https://wiki.ubuntu.com/Kubuntu/Todo/Lucid?action=raw'; workitems.py -d data/desktop-lucid-workitems.db --csv --to 2010-04-01 | burndown-chart.py --output=www/www/workitems/desktop/lucid/burndown.png --height=450 --title='Desktop Team Lucid Burndown' --title_y 400 -; workitems.py -d data/desktop-lucid-workitems.db --html > www/www/workitems/desktop/lucid/report.html
  
  15 * * * * workitems.py -d data/mobile-lucid-a2-workitems.db -r lucid -p 'mobile.*-lucid-' --milestone lucid-alpha-2; workitems.py -d data/mobile-lucid-a2-workitems.db --csv --to 2010-01-14 | burndown-chart.py --output=www/www/workitems/mobile/lucid-alpha2/burndown.png --height=450 --title_y 400 --title='Mobile Team Lucid Alpha 2 Burndown' -; workitems.py -d data/mobile-lucid-a2-workitems.db --html > www/www/workitems/mobile/lucid-alpha2/report.html

Please contact Martin Pitt if you need updates to the cron jobs, or a new report.