Auto Tracker

CunninghamAndCunningham? (http://c2.com ... but you already knew that) provides a service (for a monthly fee) to host the special WikiWikiWeb (developed in cooperation with RoleModelSoftware) that will take data from a template and RollUp? the results. WardCunningham and KenAuer are working on a paper that describes it in detail, but until then, here's a short description:

For a given iteration, we have a page describing each of the stories/tasks we're tackling. E.g.

IterationSix?

For up to date tracking status, try http:rollup.cgi (BrokenLink 20050412)

The goal of this iteration is good. The following tasks/stories are part of this iteration:

AddGraphReadingsToNavigatorStory?
AdjustIconsTask?
AddQueriesForUserDefinedFieldsStory?

...

Then for each story/task, we can break it further into tasks (or not). If we break it into tasks, it looks basically the same as the above ... it's just another node in the tree. E.g.

AddGraphReadingsToNavigatorStory?

For up to date tracking status, try http:rollup.cgi

The goal of this iteration is...

The following tasks/stories are part of this iteration:

AddGraphReadingsNodeTask?
AddGraphReadingsToExistingPerspectivesTask?
AddGraphReadingsPerspectiveTask?

...

Eventually, we get to the leaves. They use a template (keyed on the suffix 'Task' in our case) when created, and we fill in the details. E.g.

AddGraphReadingsToExistingPerspectivesTask?

Risk: Low EstimatedTime?: 1.5 ActualTime?: 0.75 RemainingTime?: 0.5 Developer: JoeProgrammer? Pairs: JeffFada?, JoeMama?

Currently, nodes in the tree stop at Results. We'd like to add a node under the Results node to include Readings. When the Readings are selected, show a Graph which displays those readings... it should be the same graph we currently see when we press the "Graph" button when a Result is selected

At the beginning of each iteration, developers who have signed up for tasks enter the EstimatedTime? and the RemainingTime? (which should start out to be the same).

During the iteration, at the end of each day (or more often), developers update the ActualTime? and RemainingTime? fields for all of the tasks they worked on... NOTE: ActualTime? + RemainingTime? will not necessarily equal EstimatedTime?.

At any point, if I want to see how a story or an iteration is going (with respect to estimates), I can just go to the corresponding "http:rollup.cgi" to see a table which shows me the items and the totals. It looks something like this:

 Rollup of IterationSix?
ActualTime? EstimatedTime? RemainingTime?
 ..AddGraphReadingsNodeTask?1  1  0
 ..AddGraphReadingsToExistingPerspectivesTask? 0.751.5  0.5
 ..AddGraphReadingsPerspectiveTask?  0  1  1
 .AddGraphReadingsToNavigatorStory? total 1.753.5  1.5
 .AdjustIconsTask?0.5  0.25  0
 [...]
 .AddQueriesForUserDefinedFieldsStory? total 4.5  5  1.5
 IterationSix? total13.25  46.5  33.75

So, I can see at a glance stuff like:

how much more time is remaining to finish the assigned tasks of the iteration,
whether we are currently in the ballpark of our estimates,
which particular story/task(s) are threatening the completion of the iteration,
whether there's more time than work remaining (or vice-versa).

This ever-present feedback which helps me (as the coach) or anyone else on the team (e.g. the official Tracker) ask some good questions at the next stand-up, such as:

Has everyone been updating the wiki at the end of the day? (hopefully the answer is "no" when the data that prompted me to ask showed we were behind schedule).
It looks like the XYZ story has been giving us some problems... is it under control? is the customer aware of the issues?
It looks like Joe has more tasks than he can finish in the remaining 5 days of the iteration. Joe, how can we help you out?... Mary, it looks like your tasks are done, can you help?

This allows us to make the role of the Tracker a lot less time consuming.

By the way, we could also organize pages by developer (which tasks are assigned to whom), or any other means. We can "rollup" the entire project, or any part of the project by simply creating a new wiki page with bullet items which point to other pages that contain stories/tasks.

NOTE: We can, but we typically haven't. We would if we found much value in it. So far, we have found that rolling up the current iteration tends to give us all the feedback we need to make forward thinking decisions. Some project archaeologist could possibly find some interesting things by analyzing old iterations, but I don't know how valuable they'd be for what purposes. I have lots of guesses, but for a variety of reasons (mostly because the iteration pages tend to get munged at the end of an iteration and we have tended not to think about preserving them before we munge them), I wouldn't have a lot of confidence in much of the numbers.

Hope this helps.

-- KenAuer

Ken - you may think YouArentGonnaNeedIt but - does the rollup work by summing numeric header fields, or by looking explicitly for EstimatedTime?, etc? I can think of other uses for the more general case, and it doesn't seem (to me) like the code would be all that difficult either way. -- BrianEwins

It looks for any field with numbers in it. Field is defined as a leading space followed by text followed by a colon. It has been interesting to watch it roll up our "as of: 991229" date fields. We just ignore the result. -- KenAuer

Here's a trick from ScRibble, one of my Wiki clone experiments that went down a related path: By extending the link pattern to allow for optional trailing digits in links, tasks can be kept in order (in rollups) automatically. That is, instead of IterationOne?, IterationTwo?, ... IterationSix?, ScRibble allows ProjectIteration1, ProjectIteration2, ... ProjectIteration6. One downside: you lose the ability to have IterationSixPartTwo?. :) -- DaveSmith