Please login or join to subscribe to this thread
You can certainly use EVM with Agile, but because you are performing the work differently, your cost and value estimates are broken out differently. Figuring it out as you go doesn't mean you are completely without a game plan.
FYI - there are lots of web articles about EVM on Agile.
I lived in Singapore for awhile and they had an interesting slogan - low crime doesn't mean no crime: be vigilant!
The same can be said about Agile - low planning does not mean no planning: be vigilant!
You can do EV with Agile but it does require a plan (baseline) for reference. How you pull that together in your environment is the crux of the matter.
Some Agile teams are comfortable with a PM pulling a plan together based on the information at hand, e.g. velocity applied to the outstanding backlog is one technique. It's easy enough to apply and can be used as a base. Once a month or two refine your plan based on the revised velocity and backlog and rebaseline.
Some Agile teams and Orgs are not comfortable with this extrapolation as they feel it hems them in and is counter to their understanding of Agile (which it isn't, but that's another discussion). So in this case, what do you do? A potential way forward might be to plan major milestones with the team instead of minor ones, but you'll have to figure this out based on the dynamics of your team.
Once you have a plan/framework you then need a way to compare plan to progress. Cost is the obvious one - it's what EVM was based upon. I've worked with others, though it requires a bit of faith to believe that the numbers have the same meaning. E.g. Planned # of completed backlog items vs actual completed is one obvious way. Sprints could be another. # of deliverables could be used too.
What is it you're trying to measure?
EVM basically measures performance based on a baseline. There are real limitations to this, even in a predictive project (i.e. your project expenses may not be distributed evenly over time, so any formula comparing budgeted cost and actual cost can be skewed). To add to these limitations, your agile product development might not have a fixed schedule or budget. So I'm just curious what metric you really need. If you're capturing all this data and running EVM calculations that don't help your team, then that's merely waste.
Thanks to each of you for your feedback. One response to Wade is that I wasn't really looking to drill down too deeply. The general dialogue is a debate I regularly get into with some of our IT folks who feel up front planning because the most basic isn't really conducive to good agile application development. My counter is usually... then how was it you told our customer you estimated this could be done by XX/XXX if you weren't doing some sort of baselining of milestones and when you would hit them. It's sort of an ongoing debate where they aren't wanting to provide solid estimates to the clients because they say you figure out Agile work as you go. My response is that you normally flesh out details in agile as you progress but that doesn't mean you don't do a reasonable degree of base line planning up in order to provide your clients with meaningful expectations. I hear the word Agile worked an awfully lot in lieu of giving the client some sort of meaningful target planning up front and modifying it as necessary throughout the life of the project.
I am using it right now with a convination of ES (Earned Schedule) no matter there is not schedule in Agile (except you use DSDM for example). I agree with @Keith and @Robert.
Don't get me wrong, if you find that an EVM formula is useful, then you should at least try it for awhile. It's just my knee-jerk reaction when management wants a new report to ask why. I'd have the same reaction to your coworker, though, because there are very few absolute "cannot" practices if your organization is really agile.
I'd be curious to know how it works, if you try it.
Please login or join to reply