Tracking and Reporting

The project is underway and I need a feature-level view of where we are. Burn-down charts for user stories are great but do not give me the business-level picture. Burn-down charts calibrated in hours are dangerous – you can burn-down lots of hours of effort but accomplish nothing! Completed hours of effort get counted, story-points for unfinished user stories should not be counted. This is why project tasks masquerading as user stories should be ruthlessly rooted out.

My team signed up to deliver 10 major features to a customer, and I want to know 2 basic things:

  1. How much of the feature development work has been completed?
  2. Are we on the right trajectory to complete the project on time?

The first thing I want to see is a big picture status summary for feature development status. Something like:

Feature Completion Status

Feature Completion Status

Note that the data used to build this chart has been filtered clean of all non-customer-facing “user stories”. This chart represents delivered “business value” and not just work done.

The basic takeaway from this chart is that:

  • 6 out of 10 features are 100% complete
  • 3 are partially done, and
  • 1 is not yet started

Next, I want to drill down into the partially completed features to understand what risks we might be facing. For this, I need a chart along the following lines:

Feature Status By User Story

Feature Status By User Story

In this chart we have a breakdown of each feature into it’s constituent stories, and the status of each of those stories, where B = Backlog, D = Defined, P = In-Progress, C = Completed, and A = Accepted. Additionally we have the total planned story points for the feature, the number accepted and the resulting percent complete (Accepted Points/Planned Points). Feature Six immediately stands out because it looks like no planning has been done for this feature, and thus we may want to explore that further to determine the risk of having to exclude it from the release, or taking some other remedial actions to get it back on track.

Now let’s take a look at a release burndown chart to see what that might tell us. I have rarely seen a a nice clean textbook burndown chart on a real project. They typically might look like the following:

Release Burndown

Release Burndown

Key Points:

  • Project Start = March 18
  • Target Finish = July 01
  • Initial scope: ~ 1400 story points
  • Additional scope to the tune of an additional 600 points added through 1st week in June
  • Team has completed ~ 1000 story points, approx. 350 per month
  • Team has approx 1000 points remaining, ~ 3 months. This implies a mid-September finish
  • Team options: move release date to mid-September, or, reduce scope by approx. 600 points

Of course, action should have been taken much earlier to either contain the scope additions or acknowledge a later finish date. The overall point is that the release burndown chart is a powerful tool to help teams forecast progress and the likelihood of finishing on time. It can also be used to make clear the implications of scope changes on schedule.

Here is another way to assess progress:

Scope Completion Trend

Scope Completion Trend

This chart paints a more positive picture:

  • Consistent progress is being made from month to month
  • Work-In-Progress (WIP) is stable
  • Teams appears on track to complete all work within about 1 more month.

It is very much worth the effort to pull this kind of data together so that team’s have visibility of overall project progress on a daily basis.

 

Print Friendly