Project baselining and tracking

As a project manager, independent of methodology, you need to keep track of four things: Scope, schedule, budget, and quality. Nothing new here. In Agile, the favorite method (or at least my favorite method) of keeping tabs on your project is through the burn-up chart. This chart covers scope, schedule and budget. Tracking quality will be the topic of another blog post.

You start out with a certain amount of scope for your project, that you can express in story points, ideal man days, dress sizes or whatever metric you choose, as long as it is numeric and everybody involved in the project understands and agrees on its meaning (There will be future blog posts discussing the various options of measuring scope and their implications, as well as estimating the initial scope of a project). Please note that scope is treated as a variable through the project, we keep budget and schedule fixed.

The schedule follows from the speed at which you implement scope; this is of course known as the velocity, the amount of story points implemented per sprint. In order to baseline your project, you must have some idea of the velocity up front. If your team has been working together in the same composition in the previous project, they will have a pretty good idea of their velocity. If the team works together for the first time, you need to discuss and agree with them on a velocity that they feel can realistically be achieved. If possible, make corrections for known holiday periods or other absences. The alternative is of course that you use the first few sprints to determine this velocity, but then you cannot give a baseline schedule up front. This may or may not be an issue depending on your business processes regarding project funding, approval and kick-off.

You will also have a fixed budget within which your team must deliver the scope. This budget can be expressed in real man days or a currency. The translation from scope to budget must also be agreed upon with your team; at least as far as man days are concerned. The actual dollar amounts will depend on the rates and salaries of the team members, and also invoicing and payment cycles are not likely to match your sprints. Tracking the budget in monetary terms is therefore a little more complicated, but there are no fundamental reasons against it. Since you have already established a baseline schedule based on your expected team velocity, you can also produce a baseline cost progression based on expected team member availabilities. I will refer to the speed with which you spend budget, i.e. the amount of man days or dollars per sprint, as the burn rate.

So now we have four metrics: baseline scope to be delivered, baseline delivery schedule based on expected team velocity, a budget and a baseline cost progression based on expected burn rate. You can plot these in a graph versus time, in units of fixed length sprints, see the figure below.

In this graph you see that up until sprint 10 the expected velocity is the highest. That’s because one of the teams is expected to leave the project after that. From Sprint 20 on, only a minimal team will be taking care of post-release work. The baseline cost progression follows the same pattern. Scope is expressed in story points, budget in man days.

In order to make this a burn-up chart, you need to update the amount of story points delivered (as per your Definition of Done) and the amount of man days spend after each Sprint Review. After several sprints, the result will look something like this:

You see here that the actual scope delivery is above the baseline, and that the actual cost progression is slightly under the baseline, so this project is going good. You also note that the blue project scope line has upward bumps at sprint 5 and 10. At this point re-estimations and new user stories resulted in additional scope. According to the scope trend line, this project will finish by sprint 15, and according to the cost trend line, around 1800 md will have been spend at that point. Of course the trend line does not yet take into account the reduced staffing that will come into play after sprint 10, making these projections for cost and schedule too optimistic in this particular case. However so far this project has performed slightly under budget and it is ahead of schedule since more scope has been delivered than projected.

A different outlook would be the one below:

This project is running behind schedule; less scope has been delivered than planned, and at the same time more budget has been spend. At the same time, additional scope has been added to boot. The scope trend line indicates that all current scope will be delivered by sprint 22 (but only if we keep all teams on board, so no reduction in velocity), and the cost trend line indicates more than 3000 man days spend at that point, a 50% overrun. This project is headed for disaster, and it’s time for immediate remediating action. And that action would be to start dropping non-essential scope items so that the blue project scope line goes down again, as well as tackling any impediments identified by the team as a reason why they need to spend extra time.