This blog post is the third one of the Agile Performance Reporting series.
3. Cost control
The third controlling process of PMBOK is cost control. It’s goal is to control the changes that influence the cost baseline.
There are 4 inputs that are used in cost control:
- The cost baseline
- Performance reports
- Change requests
- Cost management plan
As outputs we usually see things like:
- Revised cost estimates
- Budget updates
- Corrective actions
- Estimate at completion
- Lessons learned
Let me try to translate this into agile terminology.
Cost is often an important constraint in an agile project as well. Not often do we have the luxury of swimming in a pool of money. Even if we did, as a business owner, we would still like to get as much value out of our investment. That’s why most projects are estimated and budgeted.
What would be the input of your ‘agile’ cost control?
- The cost baseline = your calculated budget based on estimated or measured sprint velocity, often in the form of a cost burn-up chart.
- Performance reports = the timesheets and invoices of previous sprints
- Change requests = the evolution of your product backlog
- Cost management plan = not prescribed in agile, but generally a sound project management practice. Determine at the start how you will treat cost variances.
What would be the output?
- Revised cost estimates = an updated release cost burn-up with trend lines
- Budget updates = an updated release cost burn-up with trend lines
- Corrective actions = depending on the constraints, modify scope or timing or budget
- Estimate at completion = an updated cost burn-up with trend lines
- Lessons learned = a mandate of the project board to implement improvements that help the team to deliver more value for money.
If cost is your major constraint, and there’s no way you can get additional funding, then this is something you want to watch closely, even in an agile project. You can do this with a cost burn-up chart.
The chart shows how much budget has been spent during the previous sprints. We can calculate this, because we have the invoices of all our team members. It’s just a matter of distributing the monthly timesheet data to the sprints.
But we also need a budget forecast. This can be calculated because:
- We know how many sprints we need to complete the project, thanks to our velocity measurements and our up-to-date product backlog.
- We forecast how many days each team member will be present during the remaining sprints.
If you enter the actuals after each sprint, you can use this graph to monitor your cost and it’s evolution on a regular basis.
Again, the chart doesn’t give you one precise number, it gives you a best case, an average case and a worst case scenario. This is key to all agile reporting. There is a cone of uncertainty, let’s not ignore it. Instead, monitor it continuously and act accordingly.
A budget burn-up chart is a great tool for reporting to senior management, for instance in a project board. In an agile team, the product owner carries responsibility for the budget. However, when things get out of bound, it is often the project board who takes decisions. When budget is the major constraint, you have to work with time or scope.
As a product owner, you can prepare such a project board meeting.
OK, we’re heading towards a budget overrun, let’s prepare some corrective actions.
- We can drop feature 120.
- We can go for a simplified version of features 121 and 122.
- We will release one sprint earlier and move features 121 and 122 to a next release.
- These are user stories that were added to the backlog, are they all necessary?
- The team has identified these organizational impediments that hinder their performance.
Many people think that it is impossible to report about budget in an agile project. Actually it is pretty easy, once you realize that the only things you need are invoices, an up to date product backlog, sprint measurements and a team capacity forecast.