In my post on March 1, 2015 I said that agile recognizes most effective software processes cannot be defined up front. And that the PMO finds it difficult to measure agile projects. Classic key performance indicators from project business can definitely be used for controlling of agile projects. They only need to be adapted. Sounds easy, right?
- Planned Value (PV): The value of work planned to be accomplished based on the budget (in money or hours)
- Earned Value (EV): The integrated value of work actually accomplished based on the budget (in money or hours)
- Actual Cost (AC): The cost actually incurred for that work
- Budget at Complete (BAC): The assigned budget to complete the work (planned budget)
- Estimate to Complete (ETC): Forecasted amount to complete the remaining work (in money or hours), based on the past performance
- Estimate at Complete (EAC): Forecasted amount for all work in the project plan, based on past performance
- Cost Performance Index (CPI): This metric indicates how many cents have been “earned” out of every dollar spent. It measures cost efficiencies.
- Schedule Performance Index (SPI): This metric measures schedule efficiency. It indicates how fast you are progressing against the rate of progress planned.
How can they be calculated (in agile)?
- Budget at Complete (BAC): The planned amount you expect to spend (taken from base project plan)
- Actual Cost (AC): The actually incurred cost for that work, usually taken from reporting tools or ERP-systems
- Planned Release Story Points (PRSP): The planned release story points for the release, defined at the product backlog level
- Expected Percent Complete (EPC): Current sprint / Total planned sprints
- Actual Percent Complete (APC): Completed story points / Total planned story points for that release
- Planned Value (PV): BAC * EPC
- Earned Value (EV): BAC * APC
- Estimate to Complete (ETC): (BAC-EV)/CPI
- Estimate at Complete (EAC): AC+ETC or BAC/CPI
- Cost Performance Index (CPI): EV/AC
- Schedule Performance Index (SPI): EV/PV
And in addition: What does a story point cost?
Or said in other terms: “How can we use data from past projects to determine the cost of future projects, based on agile estimations?” At work I was confronted with the same issues. You do a new project, estimate all user stories, but what a customer (still!) wants is a number, he wants to know what he is expected to pay in the very end. Of course there exists a book on agile contracts, but until you reach that consensus with your customers you still have to do something. I figured out that instead a team estimates the complexity of the user stories in story points, but then also in traditional effort (hours, days) is waste and not necessary.
All the things you learnt from past projects can be taken to calculate the future project!
- The possible end-date can be calculated based on the average velocity of a team. After you see how many iterations it will take to fulfill the whole product backlog of that release, you know the possible end date.
- The project cost can be calculated by using the amount of story points for the whole product backlog of that release, multiplied with the cost of a story point.
- The costs of a story point can be determined by AC completed/Story Points completed – The actual cost of completed user stories divided by the completed story points.
See: With some adjustments you can use traditional KPIs also in agile projects.