Micah has written before about using burn charts to track team progress. One of his tips is to use a project’s projected finish date to help the client understand what changes can or must be made to the scope and budget. I’ve long been curious about calculating when a project will finish, so after reading Micah’s post, I did some research.
Read more on Estimating Project Completion with Burn Charts…
Uncertainty is inherent to software development — it’s impossible to precisely predict how long individual tasks will take. And that makes it very difficult to manage software projects using traditional project management tools.
Read more on Transparent Project Management with Burn Up Charts…
Burn charts have been a staple of Atomic-run projects for quite a while. They’ve also been the subject of much discussion both internally at Atomic and at-large in the Agile development community. The basic concepts are simple, and we’ve found them useful — especially when they are allowed to evolve as we learn how to better engage our customers and teams. I’m going to tell a story of one such evolution.
First, if you’re unfamiliar with a basic burn chart, check out Mike Marsiglia’s previous post about Atomic burn charts. Got that down? Great!
I’m going to follow the story of a ficticious company, Acme, Inc., working on a custom order management system. Our burn chart experience started simply, as Mike’s example illustrates: one big scope bucket (represented by the blue line), and a team of three working to realize the features represented in our backlog (represented by the green line).
Read more on Evolution of a Burn Chart…
When managing a software project that has both design and development scope, I have come to prefer using an integrated backlog of tasks and separate burn charts to track design and development efforts.
Atomic continuously experiments with project management practices that help our poly-skilled teams manage their efforts and predictably deliver custom software products.
I’ve previously written about using integrated backlogs and burn charts and noted in my post that an integrated burn chart can be a bad solution if your team will have people inconsistently allocated throughout the course of the project. Inconsistent allocation can be problematic for burn charts regardless if the team member is a designer or a developer, but I’ve found through experience that it’s almost always true that the design effort on a project will have inconsistent allocation. The potential burn chart distortions resulting from inconsistent designer allocation are also likely increased due to a hours per point skew between design and development tasks. Read more on Pitfalls of Integrated Design and Development Burn Charts…
If your team is not focused on delivering intermediate project milestones, they are missing what’s really of value. It’s easy to miss the forest for the trees if you’re only focusing on task-level points estimates and velocity tracking.
I’ve become frustrated with how burn charts focus on showing progress through an entire backlog and don’t clearly show the importance of incrementally delivering chunks of value.
Burn Charts Are Not Enough
Atomic has been experimenting with several approaches to help us focus, report against, and manage scope against intermediate milestones.
Read more on Moving Beyond Story Points, Iterations, and Burn Charts…
At Atomic, burn charts are an important component of our project management practices.
A Burn chart is a high-level visual indicator that reveals project progress over time. Generating these charts at regular intervals provides key insights for both the business customer and the development team.
Some of these insights include:
- Confidence about delivery dates
- Confidence about anticipated cost
- Impacts of scope change
- Measurement of accomplishment
Read more on Atomic Burn Charts…
A couple of years ago I wrote about how I was using Epic stories for early project estimations. Recently John Rusk posted a question in the comments:
I have a question about this: “We make no attempt to restrict that the total number of points from the resulting stories adds up to the previous estimate of the Epic”.
How do you find that affects your burn charts? In particular, imagine you are half way through a project. All the epics up to that point in the project have been “expanded” into smaller user stories. But the epics after that point have not yet been expanded. Imagine also that, when expanding an epics, the total number of points in the small stories is typically greater than the total of the original epic.
This would mean that past work has reasonably accurate numbers of points associated with it, but that future work, still in epic form, is underestimated. (Since, when you decompose the future work, its point value will typically go up, so therefore its current point value is too low).
If this happens, it may skew your burn charts and make you think you’re closer to finishing than you really are.
However, from your description of your success with this approach, I take it that this problem doesn’t actually affect you. I have used a similar approach myself but, being concerned about the above problem, I have always taken care to preserve the same total point value when breaking down the epics. Hence my interest in hearing how you have tackled, or avoided, the same problem.
I am using Epics to get a very rough estimate of the size of the project, without having to spend an inordinate amount of time wading through the details at the beginning of the project (at the point of maximum ignorance as Carl is fond of saying).
Read more on Breaking Down Epic Stories…