Please login or join to subscribe to this thread
Interesting your question, especially coming from a specialist
Honestly, I would like to hear your thoughts on this topic
Why not, there are always ways to calculate EVM in Agile projects, nevertheless the priority is to deliverable value using these simple performance metrics in conjunction with the more typical Agile metrics (the Iteration burn-down and release burn-up charts for example) provides objective analysis to share with teams, management and customers. The early warning that the AgileEVM metrics show, validates changes to release plans and provides business with the opportunity to make priority trade-off decisions early in the project lifecycle.
The baseline is the number of planned iterations in a release, the budget in the planned release and the total number of story points planned.
Knowing all this, AgileEVM is easy to calculate and is a measure that helps to manage the release, sometimes make sense to use it, it all depends of project manager and the project duration.
What measures we need to calculate this:
1 - The total storypoints completed;
2 - The number of Iterations completed;
3 - The total Actual Cost;
4 - The total story points added to or removed from the release plan.
Earned Value- it is the sum of the estimated story points for the features up until the calculation date.
Planned Value - it is the sum of story points planned until calculation date.
Actual Cost is what the name implies: the cost in dollars to complete a set of features, until the date.
Planned Value for a given iteration is the Expected Percent Complete multiplied by the Total Budget ( Expected Percent Complete equates to the number of completed iterations divided by the number of planned iterations).
This came up earlier this year with an agile team (software development) working for a bureaucracy that required EVM on all projects. I was opposed because, in my opinion, the classic EVM calculations were producing lies. (Full disclosure: I'm fairly disgruntled with EVM even in predictive lifecycle projects for the same reason; I think too many PMs rely on simple reporting numbers instead of using EVM as a tool to call our attention to important project details.)
In this project, there was no contractual budget, schedule, or scope to use to calculate EVM. Rather, by the time we reported the numbers, they were wrong. Yet there we were, submitting required reports and pretending they meant something. Every time, I'd let them know the numbers were complete fiction, and every time they'd acknowledge this fact and yet request the next EVM report.
Yes. I use it on project based on Agile. No matter that you can find papers written by authors of Agile based methods that can guide you.
Yes, it is. "Traditional" EVM is still relevant because there are (many) projects that are not full "software based", SW is a component of the full package that may imply "physical" work.
Construction, telco, industrial, product development, etc.
Hybrid approach is the step to take, PMs will tailor and adapt EVM accordingly to the project requisites and necessities.
@alexandre costa. In my view any metric based on story points is useless or close to that. SP were invented for political reasons and even the person credited to invent them apologized for the way they are used.
Basically it is very easy to change a backlog item size from 5 to 8 or 8 to 12 without a problem. Velocity and "EVM" based on story points are too easy to be gamed (remember that's why they were invented)
@alexandre costa. My question is related to the PMI/ISO EVM standard, not to the fluffy Agile "metrics" like burndown, velocity etc. None of those metrics can and/or should be used outside the development team, especially not with the Sponsor or Product Owner.
@wade. I personally agree with you. Expenditure doesn't equate value for the client (regardless that it is approved or authorized).
@sergio. what are the units that you use? Money, story points, something else?
Please login or join to reply