The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Tamara Sulaiman on Oct 05, 2007
AgileEVM is an adaptation of the traditional project management practice of measuring actual value of integrated cost, schedule and scope against a baseline plan using Earned Value Management (EVM) metrics. The methods of measurement have been adapted to easily fit within the Scrum project management framework. AgileEVM can be used both in conjunction with traditional EVM metrics across the entire product life cycle to measure cost efficiencies. This is an important addition to an Agile program management structure - giving important early warnings of trends across the entire product life cycle.
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Because the AgileEVM method derives the same metrics as traditional earned value management techniques, the two can be combined in a mixed methodology program to give results at the program level. For example, the earned value derived from an Agile project can be combined with the earned value derived from a traditional plan driven project within a program or portfolio, resulting in the total earned value for both. By providing the cost efficiency information across all types of projects in a program, AgileEVM helps to spot potential risk areas earlier and gives metrics analysis information to include in decision making.
AgileEVM was initially developed in response to a need for specific performance information on a fast moving project using the Scrum framework. The team involved had decided to move to one week sprints for this release. The final release plan was fairly fluid, with the Product Owner identifying new features every week that were to be included in the release. Adapting the traditional earned value management metrics to this Scrum project allowed the ScrumMaster to accurately predict the impact of these requirement changes, despite a fluctuating velocity, on budget and schedule for the release. The ScrumMaster was able to then share this information with the Product Owner and the team, giving them information to help make additional decisions.
Two years after implementing Scrum and AgileEVM on a single project, Tom Blackburn, program manager at Info Tech, Inc, a market leader in transportation construction management software, now utilizes the earned value data in a dashboard to communicate important budget and schedule information on projects in his portfolio.
Company product leaders use the results of this information in conjunction with the burndown data as input to product investment decisions. In addition, the earned value metrics are posted in the co-located team rooms together with the burndown and Agile metrics for every sprint. The result is that teams can effectively share data with related product teams resulting in improved communication across the product life cycle.
"We realize that one of the key benefits of using AgileEVM is using the data in conjunction with the burndown; it gives us advance warning of a trend. The more information we have: the better decisions we can make" said Tom Blackburn, "I track the value of the CPI (Cost Performance Index) and SPI (Schedule Performance Index) over time as a means to allow my teams greater insight into the project."
The AgileEVM method provides easy cost tracking using information that is already accessible by using this methodology. AgileEVM links actual work completed with budget and schedule in a clear and concise manner. This helps support release planning because trends can be seen over time, resulting in deeper understanding around how each team is performing.
Earned Value Management (EVM) metrics on large projects or programs have been used as a way to 'roll up' project metrics to the program level. This method directly translates to an Agile program as well. Whether the program uses Agile methods in all phases of the product life cycle,( i.e. development, maintenance and support) or has an mix of traditional and Agile methodologies, EVM metrics can be measured across projects and integrated up into a single set of metrics reflecting progress against a plan at the program and/or release level.
As program manager responsible for Info Tech, Inc. owned products, Blackburn has expanded his use of the AgileEVM techniques from one initial pilot development project to include projects up to the program level for two separate products. In the two years since the technique was first adapted, he has expanded his use of the metrics across Appia® and Bid Express® programs; two software applications used in the transportation construction industry. These programs include projects representing the full product life cycle for each product, from new development to maintenance, support and marketing projects using a mix of traditional and Agile project management methods. He now has a single set of simple metrics for each program for measuring the cost efficiencies of all projects related to a product.
Earned Value Management (EVM) is a widely recognized technique of project management. It is the subject of in-depth study by the Project Management Institute's (PMI) College of Performance Management and is now included as a standard in the "Guide to the Project Management Body of Knowledge" published periodically by the Project Management Institute. EVM integrates the areas of technical performance, schedule and actual cost to provide metrics for work actually accomplished. By comparing the earned value (EV) with the planned value (PV) the actual progress on the project is compared against the expected progress. Using this information, metrics assessing cost efficiency and schedule efficiency are calculated. Metrics forecasting the expected cost to complete a project and total expected cost of a project based on past project performance are derived.
(note: The term value in EVM does not refer to business value. The term refers to value as expressed by the project or program budget.)
| Earned Value Term | Definition |
| Planned Value (PV) | The value of the work planned to be accomplished based on the budget (in dollars or hours) |
| Earned Value (EV) | The integrated value of work actually accomplished based on the budget (in dollars or hours) |
| Actual Cost (AC) | Actual Cost incurred for that increment of work |
| Budget At Complete (BAC) | The budget assigned to complete the work |
| Estimate To Complete (ETC) | The forecasted amount to complete remaining work (in dollars or hours) based on past performance. |
| Estimate At Complete (EAC) | The forecasted total amount for all work in the project plan based on past performance. |
Earned Value Metrics
| Metric | Formula | Metric Analysis |
| Planned Value | BAC * Planned Percent Complete | The planned value indicates how much value was planned to have been generated by a particular milestone or point in time. |
| Earned Value | BAC * Actual Percent Complete | The earned value indicates how much value has actually been generated at a particular milestone or point in time. |
| Cost Performance Index (CPI) | EV/AC | This metric indicates how many cents have been "earned" out of every dollar spent. It measures cost efficiencies. |
| Schedule Performance Index (SPI) | PV/AC | This metric measures schedule efficiency. It indicates how fast you are progressing against the rate of progress planned. |
| ETC | (BAC - EV)/CPI | This metric is the forecast amount to complete the remaining work. |
| EAC | BAC / CPI Or AC + ETC |
Forecasted cost for the total planned work. |
These key metrics are the same measurements in AgileEVM as in traditional EVM. Only the method for obtaining the measurements has been adapted. Agile accentuates the use of rich collaboration and the frequent delivery of fully-operational tested systems, as well as fostering the human component of software development. Agile software development focuses on delivering business value early in the project life cycle that are based on timely customer and market demands. AgileEVM was specifically development to measure and forecast progress on Scrum projects. While the technique is valid on other Agile methods, AgileEVM works particularly well with the Scrum elements of an estimated, prioritized backlog and measuring at Sprint boundaries.
In AgileEVM, story points are used as the measure of work planned and work performed; providing the basis for all of the traditional earned value calculations. The other adaptations were to change (more context) how expected percent complete and actual percent complete are calculated. In AgileEVM expected percent complete is derived by dividing the number of complete sprints by the total number of planned sprints. Actual percent complete is derived by dividing the number of story points completed by the total number of story points planned for a release. It is important to note that the story points used in AgileEVM at product backlog level, as estimates of relative size not at the sprint task level.
In order to calculate the initial baseline in AgileEVM five data points are required.
Each sprint boundary was established as the 'measuring point' to re-baseline any changes (i.e. work added or removed from the plan) and re-evaluate the earned value results. To calculate the AgileEVM metrics, four data points are required:
The research paper presented at the Agile 2007 conference provides proof of the validity of the AgileEVM approach. The paper asserts that AgileEVM:
AgileEVM Equations
| Item | Definition |
| Budget At Complete (BAC) | The planned amount you expect to spend |
| Actual Cost (AC) | The actual cost to complete the work |
| PRSP | Planned Release Story Points for the release. Story points are defined at the Product Backlog level. |
| Expected Percent Complete (EPC) | Current Sprint(n) / Total planned Sprints |
| Actual Percent Complete (APC) | Story points completed / Total planned Story points |
| Planned Value (PV) | PV = BAC * EPC |
| Earned Value (EV) | EV = BAC * APC |
| Cost Performance Index (CPI) | CPI = EV / AC |
| Schedule Performance Index | CSPI = EV/PV |
Tamara Sulaiman is a Managing Consultant at SolutionsIQ where she is focused on coaching teams and organizations transitioning to Scrum. Tamara brings to this work over 15 years of experience in business management and software development. She is a Certified Scrum Trainer (CST) and Project Management Professional (PMP). Since 2003 Tamara has assisted teams in transitioning to agile methods both as a hands-on ScrumMaster and as an Agile Coach. As a Managing Consultant, ScrumMaster, and Project Manager, she is focused on providing value to key stakeholders and customers through effective delivery of software.
Tamara has published author of articles on AgileEVM and is co-author of the original research paper "AgileEVM - Earned Value Management." She is co-originator of the AgileEVM materials and processes that integrate the traditional project management practice of Earned Value Management with the Scrum framework. Tamara is currently focused on Scrum and Agile at the program and portfolio level, and integrating quality and financial metrics in a ‘dashboard’ format for evaluating project and portfolio health.
Anyone know if she's related to Hani Suleiman?
Different spelling... I made that mistake while editing and had to fix it :-)
This sounds complicated to me!
We have been using Scrum and big visible charts all over the place however I am not sure how much value would EVM add to the existing way we work? Most of the time we are looking at the burndown chart, velocity chart, plenty of Maven reports and that is it.
Have we already tried this on a project and see how it works? To me for now it looks like a lot of work with little benefit for the team working on the project. It seems to get a lot into costing and not sure if the team should be looking into that. The Scrum Master may be but mostly it should just be the product owner i guess.
Thoughts?
I wonder if there is any ideas about how to estimate the budget for a scrum development.
Mike Cohn has done an excellent job at describing budget estimations in his book 'Agile Estimating and Planning'. I have used his techniques on several scrum projects with success.
Vikas,
EVM is a requirement on most all US government contracts and must be reported. While I agree that the scrum team in general may not get a huge amount of benefit, it is usually a contractual agreement. The Scrum team is more worried about being "done, done" at the end of the sprints which would in the end provide them with a SPI of 1 or greater (if they finished early). From a CPI point of view, it would depend upon the resources used during the sprint (more or less than planned to get the work done).
But in the end, I believe that the ScrumMaster and Product Owner team will get more from EVM than the Scrum team itself.
The Expected percent completed to me seems questionable to me, of course I have not been involved with Agile very long. The problem is it makes an assumption that the planned velocity will be the same for every sprint. It appears to me on new projects the velocity may vary significantly in the first few sprints until the team gels and that the change could be planned for up front. A better number to use would be the number of story points/the total story points.
Just a thought, how do others feel?
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
7 comments
Watch Thread Reply