For my "Hello World" blog I'd like to do a little showing off by presenting a Burnup with Forecast graph that I have pioneered with a long-term client. We really have gotten some members of the business and upper management to flip over the amount of information and the reliable status that they can glean from this graph.
Here's a brief explainations of two important terms: - Effort Days: Think Ideal Days. I'll explain in a later blog why using the term Effort Days works a lot better than Ideal Days
- Task Cycle: One week of time, similar to a short iteration, but not the same. (This technique is documented in my book.) Each task cycle is numbered in this format: year - month - week in month.
This graph contains a ton of data. The left half of the graph is my take on the traditional burnup. The total height of the bar for each task cycle tells us whether overall effort on the project is holding steady, increasing or decreasing. The yellow bit in the bar lets us know how much work we've planned to complete for each task cycle. You can compare the line between the yellow and orange bits of the bar in one task cycle to the line in between the yellow and green of the next task cycle to read how much work we completed in comparison to what we had planned. The new and unusual element in this graph is the diamonds that tail off to the right, forecasting how many total effort days the team should have done at the end of each task cycle until the project is complete. We have this information because we performed a rough estimate of the entire project at the feature level before we started (the key term here is rough, we refine estimates as we learn and as we break features into tasks). The diamonds form a line the wends its way up the graph (instead of shooting a rigid diagonal) because different types of people will have to do different work at different times. We have developers, configuration specialists (because a lot of this project involves customizing an off-the-shelf product), load testers and a report developer. No, we are not using a fully agile approach here. Because of the nature of the work, the requirement that we commit to delivery dates, and the need to hit those dates, we are driving a course somewhere in the nether region between agile and traditional process. And, honestly, we're happy with it that way!
Trackback(0)
Comments 
Write comment
 |
TrackBack URI for this entry
Show/hide comment form