Concept: Over the past decade, Earned Schedule has been elaborated, empirically verified, and adopted by diverse industries. During the same period, the Agile framework has become widely used. Earned Schedule for Agile (AgileES) combines the speed and responsiveness of Agile with the accuracy and control of Earned Schedule.
Figure 1
Practice: Why use Earned Schedule on Agile projects? Certainly, doing so defies Agile convention, which disparages established project management practices. Witness the popular hashtag #NoEstimates (Woody Zuill) and the book by the same name (Vasco Duarte). #NoEstimates claims the following:
At the extreme, the idea of projects itself is questioned, as evidenced by the hashtag #NoProjects.
In this context, an attack on Earned Value techniques should come as no surprise, although its vehemence may be shocking.
Such objections from #NoEstimates and #NoProjects have been ably met by commentators like Glen Alleman (see the #NoEstimates topic in his blog, herdingcats.typepad.com).
As for the challenge to EVM, even Agile proponents have recognized the value for managing project cost performance. In the words of one study:
Unfortunately, the same study echoed Agile concern when it came to schedule performance management. Consider the study’s observation concerning the use of EVM on two Agile test projects:
Contrary to this view, I believe that there is good reason to use EVM techniques, particularly ES, to manage schedules on Agile projects.
Agile takes many forms. So, I need to identify the Agile concepts most relevant for Earned Schedule. I will not, in turn, address ES basics—I assume that the reader is already familiar with ES concepts. (If not, have a look at previous posts in this blog.)
Here are the Agile, specifically Scrum, concepts that are required.
- Product Backlog: The Backlog lists the requirements that the project is to deliver. The list is prioritized, and it’s sized. The sizing is done in Release Points (or Story Points or Ideal Team Days).
- Release Points: They can be any numerical value as long as they measure how much work is required to produce a backlog item.
- Velocity: The velocity is the expected number of Release Points to be completed in each Sprint.
- Sprint: A timebox—a fixed period of time usually one to four weeks in duration.
- Burndown Chart: The most common Agile metric for assessing schedule performance. It shows the number of release points that remain after a given period of time (typically, at the end of each Sprint).
- Ideal Burndown: The Burndown is assessed against the Ideal Burndown line. It runs from the number of Release Points that should have been completed at the end of the first sprint to zero Release Points at the last planned sprint. The ideal burn rate is calculated from the mean planned Velocity.
How do you interpret Burndowns? Answer: If the Burndown runs above the Ideal Burndown, the project is behind schedule. If it runs below the Ideal, it is ahead of schedule.
Example--Burndown View. Figure 1 is from a real Agile project. Its details will be described in subsequent posts on Agile. For now, note that, overall, the Burndown line sloped down. That’s a good thing because it indicated Release Points were being completed, depleting the remainder. Initially, the Burndown hovered on or slightly above the Ideal Burndown line. That indicated the project was on or slightly behind schedule.
At Sprint 5, the Burndown appeared to rise a bit more above the Ideal Burndown, but it was not clear from the graphic if the increase was significant. At Sprint 6, the Burndown jumped above the Ideal Burndown line, making it clear that the project was behind schedule.
ES Added Value. What value does ES add? Burndowns are based on the number of Release Points, not on their time value. And, Burndowns are pictorial, not numerical. Thus, they suggest rather than measure schedule performance efficiency.
By contrast, ES metrics like the Schedule Performance Index for time (SPIt) are based on the time value of Release Points, telling us how well or poorly time is being used on the project. Because they are numerical, they enable us to forecast finish dates and to set threshold values that mark boundaries between different project statuses. Here is the difference ES makes for the example.
Example--ES View. One key difference is that the SPIt alerted us to a problem earlier than the Burndown. Using the thresholds in Table 1, we could see that Project A slipped from Green to Yellow at Sprint 5. Root cause analysis started at that point—we did not have to wait for Sprint 6 for the problem to become visible.
Table 1
Associated with this advantage is another. Project A was part of a large program. It contained a mix of Agile and plan-driven projects. The numerical results produced by ES gave us a common yardstick for measuring performance across projects, regardless of their project management approach.
Finally, ES provides an Estimate at Completion for time (EACt). This metric is not available through Burndowns. In this case, it told us that with the decline in performance, the estimated end date was being pushed out by two weeks. We assessed the seriousness of the situation using the thresholds in Table 2.*
Table 2
Given that Project A had 10% contingency, we decided that the deviation at Sprint 6 was not serious enough to warrant a re-baseline.
ES complements Agile Burndowns for schedule performance management. To the simplicity and impact of the Burndown visual, ES adds the time value of deliverables, quantifying schedule performance efficiency and forecasting the finish date.
Footnotes:
*In Sprint 1, the Burndown makes schedule performance look good while the SPIt is poor. The large number of Release Points and the scale of the graph mask the shortfall in productivity. At the end of Sprint 1, the Release Point remainder was supposed to be about 4800, but it was only 5000. That difference looks small given the scale of the chart, but the time earned for the period was only about 70% of what it should have been. This shows what can happen when the assessment uses the number, rather than time value, of the deliverables. We did not weigh the result heavily because of the circumstances surrounding Sprint 1. More on this in later posts.
References:
Ambler. S. (2011, May 3). Agile and EVM Strategies. [Blog post]. Retrieved from http://www.drdobbs.com/architecture-and-design/agile-and-evm-strategies/229402730.
Duarte, V. (2016, August 31). #NoEstimates. [Website]. Retrieved from http://noestimatesbook.com/.
Kelly, Allan. (2014, Dec 5). No Projects—Beyond Projects. [Blog post]. Retrieved from https://www.infoq.com/articles/kelly-beyond-projects.
Sulaiman, T., Barton, B., & Blackburn, T. (2006). AgileEVM—Earned Value Management in Scrum Projects. Agile '06: Proceedings of the Conference on AGILE 2006 (pp. 7-16). IEEE Computer Society.
Van De Velde, R. (2014). Earned Schedule for Agile Projects. The Measurable News, 1, 29-35. |
