How do you do EVM in an agile development environment..?
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Last week I was asked if I knew a way to do EVM in a particular agile development environment. In this particular agile software development project environment, the development team conducts two week scrum sprints. The duration of the project is not known. The total scope of the project is not known. The budget for the project is not known. Though the development team is happy with the current arrangement, management wants a better view into various aspects of the project effort and wants to see EVM reporting. When asked how to do this, I was at a loss for words (a loss for appropriate words that is). Has anyone done this..? Saving Changes...
Sort By:
Don KimPROJECT-TO-PORTFOLIO MANAGEMENT EXPERT| Seeking opportunitiesSacramento, CA, United States
Do a search on Google for "Agile EVM" and you will find tons of resources. I've attached one of the better ones. Since your doing Scrum sprints and this is for software development, think in terms of planned stories against what was "earned" vs. the "actual". This could be represented in the burn down chart tracking the project's velocity.
I have not personally done this, but have (and currently doing) done traditional EVM projects and don't see why this couldn't be applied to Agile. My thinking is that if your also procuring the services of an outside vendor, this would be a great way to track against an Agile procurement contract. Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Don, thanks so much..! Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
Hi Mark,
It doesn't sound like this effort is a project, and so EVM would not be appropriate.
This effort has no scope, budget, or schedule. It is an ongoing product development effort, but not a project. Without a baseline to measure against, one cannot do EVM.
To resolve the dilemma, one needs to find out the management team's expectations. To be blunt, what difference would it make to the business if the development team was laid off tomorrow? This answer still may not permit EVM, many product development efforts consist of a constance stream of changes and enhancements that are not packaged as a project effort. In this case, management reporting may consist of a monthly report on enhacements delivered, costs for the month, and benefits arising from the enhancements from prior months - new customers, customer demos, internal cost reductions, or even just e-mails from users regarding the enhancements. Simple cost-benefit measurement (although it is never actually simple).
On the other hand, if management is expecting some defined deliverables or specific releases, then the development team will need to adjust their approach. The development team will need to commit to delivering spedified scope at a specified time with a specified cost. I don't think this breaks agile, it merely adds a layer of planning. This gets the effort back into the domain of a series of projects and permits use of EVM.
To do EVM, one must organize the work as a project. If the work cannot be organized into a project (which is common), then an alternative measure of cost and benefit would be required. The actual execution of the effort in two week sprints is immaterial, it is the overall organization and packaging of the work to be done.
Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Wayne, thanks so much, you have described exactly the situation. The development team does not want to adjust their approach and management is frustrated. While I do not know the deep details, the overview that I was given suggests an environment that would not be able to do Agile EVM per the various models that are out there which have as assumptions the existence of both solid agiles practices in place and an ability to use a burndown method metric. I suspect this issue is not all that uncommon. I hope we continue to hear and learn from others. Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
Wayne and Mark, thanks for this interesting discussion and some good points highlighted. Before we measure anything, the very first thing we have to do is to find a base reference. Without a reference, the measurement is meaningless as there will be nothing to compare to. Mark mentioned that the tripple constraints are unknown, meaning that we do not have a reference as a comparison. Even if we could use other means to do EVM, the outcomes might be meaningless. When management reads the reports, they do have to set their expectation right and know what are the assumptions made in the approach to obtain the reports. In other words, the PM needs to educate them on what they are reading to avoid setting the wrong expectation.
Well, the problem does not lie in the measurement system but rather, as Wayne pointed out, in the environment. Imagine, if I start off a journey without a map, without knowing where I want to go, without knowing how long and how much I need to spend in the journey, what do we call this? Vagabonding? Saving Changes...
Don KimPROJECT-TO-PORTFOLIO MANAGEMENT EXPERT| Seeking opportunitiesSacramento, CA, United States
I will agree with what the other's have said with regard to establishing a solid baseline first, before applying AgileEVM to this particular Agile project. But on the other hand, this is the kind of situation that Agile was established for in the first place to handle!
One would have to establish that due to the unknowns, if management desires to use AgileEVM (or even to proceed with the project?), then you'd have to negotiate to run a few iterations and at the beginning of each iteration, the customer and team must negotiate what to do and what is achievable given the available resources.
After a few iterations have been completed is typically when the customer and team will be better able to estimate the number of iterations, staffing requirements and cost to complete the project. Whatever number of iterations you have completed could be used as a retrospective point of reference for future iterations, and allows you to start solidifying the baseline targets for AgileEVM.
Any new requirements would be prioritized by the customer and team, allowing the customer to gauge the total budget required by the project. They would also have the ability to decide not to implement or trade some functionality if the incremental cost seemed too high for the proposed value that would be gained.
As I mentioned in the first reply, you'll want to map and establish Agile terminology and methods (story points, requirements backlog, etc.) to EVM (EV, PV, CPI, SPI, etc.) in a manner that makes sense and provides cost and schedule (EVM is pretty weak in this area, IMHO) quantification that is appropriate and would make sense to your management.
This is no easy feat, so I'd read up on the literature and think and plan carefully how to proceed. Good luck! Saving Changes...
Anonymous
As Don Kim stated, there is much written on the topic and I might add: both for and against the use of EVM for agile work. It is also one of those topics that can be like throwing gasoline on a fire. Take a look at some of Scott Ambler’s blog posts at drdobbs.com and all of those out in the blogosphere that have taken exception. Makes for good reading. I have no doubt that there will be situations in which Agile EVM might be useful, may be required by a federal contract, or might be used as a way to allow agile to transition into a traditional environment with a traditional PMO that requires traditional reporting. If the organization has fully utilized sprint and release burn-up/down charts, has an established velocity for the teams and really understands the basic agile metrics… then they might consider EVM … only if required. I’ve used EVM on several traditional projects (not an expert) and made considerable use of agile charts. The basic agile charts have a wealth of knowledge in them and tell me much more about what’s happening than EVM. Plus, the agile metrics area easy and make for great visible charts for use by the team. I have not had many teams that really cared about their BCWP, ACWP, SPI, CPI, etc. but I have had great teams that looked at a Sprint burn-down chart and made beneficial course corrections, all on their own initiative. The beauty of the various agile methods is that they are lightweight, low overhead, and productive. Adding EVM to agile should be not be taken lightly or done “just because”. Plus, more and more organizations are starting to shift their focus away from a project-centric view of the world to a stable team-centric view in which there is a continuous product/feature flow pulled from a central backlog. EVM has the possibility of holding you back; stuck in the world of once-and-done projects. I’d much rather know my velocity for getting things done versus knowing how I was doing against a plan that may be out-of-date. Agile embraces regular change. Regular change and EVM might be incompatible. Saving Changes...
Ken SalorantaSr. Managing Consultant Estimating SMEWinnipeg, Manitoba, Canada
What is the question that management is trying to answer through EVM? There may be alternative or even existing agile approaches that already answer that question.
As well, since you don't have a firm scope, that must mean that with each iteration you add new stories to your backlog. You should take a look at Ranged Burndown Charts described by Scott Ambler in his Disciplined Agile Delivery book. Basically, in your forecasts, take into account not only your gross velocity (# stories completed in the sprint), but also your net velocity (# stories completed - # stories added in the sprint) to forecast in which sprint you would finish all stories. These two numbers will give you a forecast range for the # of sprints between which you should complete all the stories (those known + those still to be discovered). Saving Changes...
