big visible charts

Estimation Risk

2004-03-14T02:45:29Z

This technique for communicating the risk of estimates being wrong on a software project was supplied by ThoughtWorker Robin Gibson. Robin is a process improvement guru currently working in Sydney, and keeps this is his kit bag to help bridge the communication gap between business and IT groups.

]]> The data collection is quite simple. Robin collects all of the stories in a agile project into a spreadsheet, where he groups them by functional area. In this case, there are 350 stories in 18 functional areas (the functional are names have been changed for confidentiality reasons). Then every story is characterised as follows:

It is prioritised as either critical, essential or non-essential
Its completeness (do we know all of the story details?) is set as complete, incomplete or unknown.
Its volatility (is it likely to change?) is set as low, medium or high
Its complexity (how hard is it to build?) is set as simple, standard or complex.

The priority levels can be averaged across a functional area to find the priority of the area overall. The completeness, volatility and complexity together represent the risk that the estimate for that story will be wrong.

This data can now all be charted like this:

Each bubble represents one functional area. The size of the bubble changes depending on how many stories are in that functional area. The highest priority functional areas are on the right-hand side of the graph, and the lowest are on the left. The highest-risk functional areas are at the top of the graph, with the lowest-risk ones at the bottom.

Its now easy to see all of this information at a glance. Any functional areas in the bottom right corner of the graph (high-priority and low-risk) are no-brainers to do. Functional areas in the top left corner of the graph (low-priority and high-risk) might never get done.

But wait, there's more... The whole project can now have its estimates summarised in one simple pie chart for everyone to see. Our example yields the following result:

It can plainly be seen from this chart that only a very small part of the system is unlikely to have its estimates change. Even more startling, a full 19% of the system is highly likely to have the estimates change.

This information can be used in a bunch of different ways, from initiating requirements workshops of architectural spikes (both to help reduce estimation risk) to including appropriate contingency funds in the project budget. Whatever the outcome, sharing this information with your team will mean everyone is better informed.

Iteration plan 2

2004-03-08T12:15:26Z

Andy Marks has supplied this example of a BVC that he has used to help manage iterations within a project that he has worked on. Thanks Andy.

]]>

Each line refers to a single story and contains the following information:

Story name and owner (obscured)
Current real cumulative hours for iteration
Estimated story size in real hours
Whether or not the story has been checked in (after completion)
Whether or not the story has been signed off by the customer
The owner's estimation as to how much of the story has been done as a %

There's also some sundry information at the iteration level (e.g., non project hours, velocity, capacity, etc).

Who have you paired with?

2004-03-07T02:24:57Z

At one of our regular retrospectives a few iterations back, the team decided that we had a bad habit of not rotating our pairs enough. More specifically, we tended to pair with the same few people for all of our tasks. That meant we could improve the sharing our knowledge to other team member.

]]> Perryn Fowler was charged with trying to rectify the situation, and he drew this chart up on a whiteboard shortly afterwards:

The idea here is that you put a mark in the square that intersects your initials and your pairs. We didn't enforce any rules other than that. Instead, we just let people come to the realisation that they were filling in some squares a lot, and others not so much.

Iteration plan whiteboard

2004-03-07T02:23:15Z

I'm a fan of Big Visible Charts. Ron Jeffries recently reminded me that I've been meaning to blog for a while about one I use to help manage my iterations. Its the whiteboard that I use to draw up the iteration plan and track progression through stories. Here's what it looks like:

]]>

I've removed the story names to protect the innocent, but you can see a few things at a quick glance.

Each story card has a name and number.
People have signed up for stories to work on them.
Relative sizes of stories are immediately obvious.
Total size of the iteration can be seen (in this case we scheduled 44 points worth).
Progress on stories can be seen by the shaded areas.
The current status of our FIT tests can be seen.

This is enormously interesting to anyone involved with the team when they go past. Issues are sometimes noted on the board (see the "stalled" note). Anyone interested in a particular story can tell if it is done or not. I can get an early indication if we are not going to complete all the cards, or if we need to schedule more. All in all, this is the most widely and actively used tracking tool on the project.