tinyPM 2.1 introduced three types of project scope charts. We would like to write few words about differences, advantages and disadvantages of using each of them. We will use all three types of charts on the same project data, this way we can better compare the information that can be read from them.
Burndown chart
(with initial project estimation as a starting point)
As you can see, the project started with a backlog containing stories worth about 50 story points in total. When we use the initial estimation as a staring point we simply put the total backlog effort on the chart and each following iteration we mark how much effort there is still to be burned (blue line) and what is the expectation (the green line).
The green line never goes up because this would mean that we expect negative velocity. However the blue line may go up in one case, which is a feature creep. In other words, the line goes up when at some point of time (T10) more new stories get into our backlog than we can actually complete. This way at the end of the iteration we have more effort left than we had at the beginning.
So we can instantly see the feature creep effect using this type of burndown. But what can we say about our team’s activity between T10 and T14 or even T20? Did they do anything? Iterations where passing by (green line continuously heading down to the level zero) but we cannot see any significant move on the blue line. Does it mean that the team did not do anything, or that the backlog got as many user stories each iteration as we could complete. Actually it may be each one of those explanations. So the point is, that with this type of burndown we don’t know that exactly.
Finally when the green line hits the zero level we can see how late we are. In our scenario the project was supposed to be finished by the T14, but at that point the team was still missing over 30 points (new stories not included in the initial scope) and the distance kept growing.
You may say this project was in a deep trouble, but we intentionally chosen such data, because when everything goes well and the lines dance close to each other, there is nothing interesting to observe and the devil is in the details. What is so valuable about burndown charts, is that they can quickly warn us when some bad things start to happen. This project could have actually be rescued somewhere between those T10 and T14 points.
Advantages:
- simple to draw even on the white board
- can show a feature creep
- can show the point where the team loses the ability to actually complete the project
Disadvantages:
- doing nothing and doing only enough to balance a feature creep looks the same on this kind of chart
- cannot read the velocity out of this chart
- your backlog needs to be estimated at the beginning, otherwise you will soon cross the zero level (which will look odd)
What types of projects is it good for:
- good for projects with some initial vision represented in the backlog and estimated at the beginning (at least as the epic stories)
- good for projects with fixed-price contract as then we usually have an initial estimation and we want to watch it burned according to a planned velocity
Burndown chart
(with total estimated effort as a starting point)
This type of chart is recalculated each time it is viewed and the burndown always starts with the total currently estimated effort for all backlog items. So even if the project stars with about 50 story points, when we take a look at it after few iterations it shows current total which may be for example 80 points.
Here we can only observe the relationship between plan and execution. We assume that stories may be added to the backlog at any point of time. We may even start with few stories. Until the blue line stays under the green one, everything is fine. If we accept all those new stories (by simply extending the budget or by working based on T&M contract) then at the point T10 there is no trouble in our project – we’re still doing fine having velocity higher than expected.
At T14 we can see that the development stopped for some time. Probably at the point of T14 it reached zero (and maybe has been released), but later the velocity started to decrease (blue line above the green one).
On this type of chart both lines always go down. It does not tell anything about the feature creep in the project, but only about the changes in the team’s velocity.
The last observation that we can make with this chart is that at T29 planned effort reaches zero while there is still some real work to be done. This means that even with all those new stories we should have finished at that point and now we’re getting late.
Advantages:
- you may actually see the changes in team’s velocity in the project
- does not require any initial estimation, nor the fully populated backlog
Disadvantages:
- hard to maintain on the white board (requires recalculations for the past iterations)
- feature creep may not be seen
- treats all stories as “must haves”
What types of projects is it good for:
- as it does not require any initial estimation it’s best for some research projects or exploratory work where stories are invented based on the results from the recent iterations
Burnup chart
This type of chart actually climbs up. It also introduces the third series (gray line) which is the “current total effort”. It combines advantages from the both previous burndows and at the same time does not have their disadvantages.
We start the project with zero completed and planned effort. Total effort may start also with zero or it may start with some initial backlog stories estimation. The goal is to reach the “total” gray line with the blue one, so actually build all those planned features.
Here we can clearly see both – the velocity of our team (on the blue line) as well as any feature creep by looking at total effort line (gray one). If the gray line goes up, then stories are being added to the backlog (or re-estimated with some higher values) . When it goes down, it means the scope to reach gets smaller.
At the T10 we’re doing fine in terms of team’s velocity but at the same time our project scope gets larger. It’s time to decide if it’s something wrong or if we accept those new ideas. At T14 we’re done with some part of our product, and it looks like we’re are done just in time. However there is still lot to do (for example for release 2.0). T28 is the point when we actually planned to reach the goal (green line meets the gray one), but somewhere between T14 and T28 our team has lost it’s initial velocity and now we are still missing about 20 points (blue line still not there).
Advantages:
- shows most of the interesting patterns in all kinds of projects
- easy to maintain even on the white board
Disadvantages:
- none that we know of unless you find this chart being painted upside-down
What types of projects is it good for:
We hope that those examples will let you better choose the best type of chart for your project. We are waiting for you suggestions or any other ideas on how to visualize the project status even better.
Follow us on Twitter
Read our Blog
Find us on Facebook