Concept: Over the past year, I have focused my posts on the connection between Earned Schedule and Agile. Next month, I will introduce a new topic. To close my posts on Agile, I will highlight the pro’s and con’s of Earned Schedule for Agile projects.
Practice: ES has advantages and disadvantages for Agile projects.
 Pro:
- Time-Box Performance Metrics: Sprints are time-boxes. Unsurprisingly, techniques that help you manage time-boxes are valuable to Agile projects. Earned Schedule has descriptive, predicative, and prescriptive measures of schedule performance that yield insights into how time is being used on the project.
- The ES and SPIt are descriptive metrics—they quantify past performance.
- The EACt is predictive—given past performance, it estimates how long the project will take to finish. Statistical analysis expands the scope of the prediction to cover a range of values given a confidence level.
- The TSPI is prescriptive: given past performance, it dictates the future performance level required to achieve the target duration.
- Quantitative Analysis: The most common Agile techniques for schedule management are primitive. For instance, the familiar Burn Chart depicts Release Point completion versus the planned burn rate.
- Burn Charts typically omit any reference to the value planned and earned for a Sprint’s deliverables.
- The Charts are pictorial, rather than numerical, suggestive rather than quantitative, and count-based rather than value-based. So, they provide at best an intuitive impression of schedule performance efficiency and duration impacts.
- By contrast, ES metrics are based on Earned Value. Because ES metrics are numerical, they enable us to statistically analyze schedule performance, quantitatively estimate finish dates, and set threshold values to mark the boundaries between performance levels.
Con:
- Some ES Metrics Don't Fit: Some ES metrics are not a good fit for Agile projects. Longest Path (described in previous posts) and Schedule Adherence (to be described in future posts) depend on fixed sequences of deliverables linked by dependency chains. The chains occupy specific time periods that, as a whole, cover the project timeline from start to finish.
- Conceptually, Agile projects cannot guarantee such a network exists. The principle of independence means that equivalent Backlog Items can be substituted for one another. In theory, the order in which they are scheduled is determined on-the-fly.
- Even though complete independence is not realistic, there are times when equivalent Backlog Items can be substituted for one another dynamically. That possibility undercuts the assumption that supports LP and SA.
- It should be noted that some implementations of Agile retain the notion of a fixed network of activities, at least for the next “wave” in Rolling Wave plans. [1]
- Some ES Metrics Are Point Estimates: ES metrics such as the EACt are point estimates. Point estimates can be misleading. The apparently precise fix they give on the future does not reflect variations in performance that are likely to occur.
- That’s why it is preferable to have a statistically sound range of likely values for duration, rather than just the point estimate.
- Unfortunately, the stats require a sufficient amount of data to be reliable—typically, 30 or more observations.
- There are techniques for calculating stats with smaller sample sizes. We have found, however, that the spreads produced by such calculations are wide. Their width inhibits their usefulness.
- So, the stats work best on projects with long durations and short Sprints.
- Projects Without Constraints:For many Agilists, the biggest negative for ES metrics reflects a more generic concern: the idea that metrics of any sort are suspect. As a colleague of mine once said, “Even if you get the EVM numbers, isn’t it more important to actually produce ‘useful deliverables’?”
- The apotheosis of such sentiment is the #NoEstimates movement. It challenges the need for any estimates. By extension, the usefulness of any metric other than the basic Burn Chart is questioned.
- To be blunt, if you believe that projects can be run independently of time and cost constraints, you probably won’t see a need for ES metrics, or at least, any metric beyond a Burn Chart.
- Arguments on this view abound, but they are outside the scope of my posts. [2]
- My view is that, if your project is bound by time and cost constraints, ES metrics in general and estimates in particular cannot be ignored.
|
