Project Management Central

Please login or join to subscribe to this thread
Agile and Earned Value Management
Network:0



i had a coworker, a fellow PMP tell me today that you can't do earned value management if you are using Agile Software Development. I'd like to hear other thoughts on this topic. My opinion is that Agile doesn't mean you don't plan milestones and forecast timelines. The opinion in our local Agile leadership seems to be that Agile means figuring it out as you go.
Sort By:
Network:135



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.
Network:69



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.

Good luck.
Network:233



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.
Network:0



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.
...
1 reply by Wade Harshman
Feb 07, 2019 9:02 AM
Wade Harshman
...
That is true, Agile is not the absence of planning, or estimating, or accountability to the customer. If you've committed to a fixed date or a fixed budget, I think there are ways to track your progress that don't require EVM.

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.
Network:1735



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.
Network:233



Feb 06, 2019 5:12 PM
Replying to Douglas Jacobs
...
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.
That is true, Agile is not the absence of planning, or estimating, or accountability to the customer. If you've committed to a fixed date or a fixed budget, I think there are ways to track your progress that don't require EVM.

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

Content ID:
ADVERTISEMENTS

"I know the meaning of life - it doesn't help me a bit."

- Howard Devoto

ADVERTISEMENT

Sponsors