It´s helpful to calculate the cost of everything you have planned at the beginning. Then, you should have a system in wich the planned cost is updated constantly. Finaly, the actual cost is calculated at any time and the project team would be able to perform EVA easily.
All aspects of earned value analysis may not be possible to apply in Agile projects. However, you may try to use schedule performance index when certain road-map is decided for next few sprints and scope is finalized. Saving Changes...
Given that you wouldn't normally have a detailed breakdown of scope during the early stages of a project following an adaptive lifecycle, you do need to adapt EVM somewhat to get it to work. One way to do this is to calculate your PV and EV at a higher level than the detailed work items in your product backlog.
For example, if you are doing frequent releases (e.g. once every few sprints) then you could calculate PV and EV at that level assuming you have a well defined product roadmap.
Kiron Saving Changes...
Joseph GherloneCo-chair, Naval-NRO Coordination Group| US Navy, Naval Information Warfare Systems CommandPentagon, Arlington, VA, United States
Has anyone addressed this in longer form - book, long article, etc. I would be very interested in best practices for tailoring EV practices to Agile processes. Saving Changes...
We are struggling with applying EVM in very large acquisition projects that span many years. Unless you have very talented and disciplined staff knowledgeable with EVM, and the requisite EVM system, I doubt very much it would work in such an environment. However, I see that you (Joseph Gherlone) are with DoD who are very good with EVM (mandatory on defence procurement), so it could be possible, but it may be more trouble than it is worth depending on the size, complexity, cost of the project. Curious also to see what others have to say. Saving Changes...
Wade HarshmanScrum Master| GDITIndianapolis, In, United States
By an amazing coincidence, this was a topic of deep discussion this week. I couldn't possibly capture all points of view on this discussion, but I'll try to summarize our conclusions. Just note that if we'd had even more time to continue the discussion, we might have come to some different conclusions.
BLUF: There are better models to communicate project status when normal constraints are not fixed. If you must use EVM, be sure your customer understands the calculations and limitations in your situation.
Summary of the conversation:
1) As a project management tool, EVM has well-known limitations and problems. If used incorrectly, it can produce very misleading indicators.
2) EVM calculations assume fixed scope/schedule/budget. If these are not fixed, the calculations are meaningless. (i.e. You can't use your budget to calculate schedule variance if you haven't defined your budget. You can't determine if your project is "on schedule" if your scope continues to change.)
3) Agile projects/products allow for constant change. (If the scope/schedule/budget is fixed before you begin, you could simply follow a predictive project plan.)
Therefore, using EVM on an Agile project will lead to misleading information.
You may be required to use EVM, like the person we talked to, due to a contractual agreement with a customer. If that's the case, you can adapt EVM to whatever it is that you currently have. You may not have a clearly defined scope, for example, but you might have a budget and a deadline. You might also have a forecast of how much work you team can accomplish in that time. There are better models for communicating project status when your constraints are variable. I believe we have a responsibility to educate our stakeholders and customers about this, and to work with them to determine what metrics and reports are worthwhile.
If you must use EVM, you need to communicate two things very clearly to your customer:
1) EVM calculations will produce misleading results because your scope/budget is not clearly defined. Previously reported results become obsolete any time the scope or budget changes. In this instance, calculating EVM is non-value adding waste, or Muda. At worst, it will produce inconsistent data and lead to poor decisions.
2) You have modified the EVM calculations to make it more compatible with the project information you have available. In other words, if you must provide this information, then be transparent with your customer about the information you're providing to help them understand what's being reported. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I am using it. It is no problem to use it. My recommendation is you search on the internet works on that matter mainly from Allistar Cockburn and Mike Cohn. Saving Changes...
