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: The previous post outlined a mathematical proof of ES validity for Agile projects. Unsurprisingly, if we change the proof’s assumptions, we get different results. Perhaps surprisingly, there are projects with good reason to change the assumptions, despite a downside in doing so.
One key assumption concerns the valuation of Product Backlog Items. The researchers mentioned in the previous post characterized the valuation as follows:
“To provide measures for work, we need to introduce a valuation for sizing Backlog Items. This allows us to measure how much work is completed for velocity calculations. The method for sizing these can be any numerical value. A few examples are: Story Points, T-Shirt Sizes with Ideal Team Days applied, Function Points and Working Days.“*
Leveraging the notion that the valuation can be “any numerical value”, I introduced the idea of Rate into the aforesaid proof. It enabled me to complete the deduction of ES Release Date from Agile principles.
Initially, I thought of Rate as a univocal term. That is, a single Rate applies to all Release Points (aka, Story Points) in a project. This is consistent with the Agile view that Release Points are fungible, i.e., treated as equals.**
It is also consistent with our practice on many projects, where the Rate we use is specifically the Resource Rate. If team members are our employees, we often use a single blended rate. It’s convenient for our customers and useful as a sales tool for our company. If team members are client or vendor employees, we sometimes do not have access to actual rates, due to confidentiality constraints. In those cases, we use a standard rate calculated from the budget and Release Point total.
There are, by contrast, projects where multiple rates are a better fit. For the sake of transparency, some customers ask us to use the specific, agreed-to Resource Rate for each team member.*** Release Points are still fungible, but the Rate applied to the points varies, depending on who is responsible for delivering them. For instance, a novice might have a rate of $40/point and a master $80/point.
When different rates are applied, Release Date calculations for Agile Burndown and ES can diverge. It’s easy to see why. Say that, in each sprint, novices are expected to produce 100 Release Points, and, masters, who are few in number, are responsible for 50. Suppose that novices actually produce 140 points, and masters complete only 10.
As illustrated above in Figure 1, after four sprints, the Release Point Burndown looks good—the points are being completed at the expected velocity. The ES Burndown tells a different story—the time value of the deliverables is behind expectations, and the gap is growing.
It’s not that the Release Point Burndown is wrong and the ES Burndown is right (or vice versa). Instead, it’s a case of different points of view. Consider the following analogy.
Say we have two cars, A and B. Car A gets 25 miles/gallon of gas, and Car B gets 30 miles/gallon. Does that mean Car B is more fuel efficient? Maybe. But, suppose we add that Car B requires Premium gas at $3/gallon, and Car A uses Regular at $2/gallon. That means Car B costs $.10/mile, but Car A costs only $.08/mile.
Now, let me ask again, which car is more efficient? From the perspective of mileage, Car B can go farther on a gallon of gas and would be deemed more efficient. From the perspective of economy, Car A would be more efficient because it costs less per mile.
Similarly, the Release Point Burndown highlights the time-value of counts, and the ES Burndown highlights the time-value of costs. With differential rates, the two perspectives can diverge. It’s a healthy conflict that can expose hidden problems.
In the example already cited, the Release Point Burndown indicates that the expected velocity is being achieved. The ES Burndown unmasks a shortfall in masters’ productivity and a surplus in novices’ output. The contrast warrants an investigation. That investigation may well lead to significant changes in velocity expectations, work assignments, or even staffing.
The divergence related to differential rates affects more than the Burndown. It ripples through ES metrics. The table below shows how metrics for the example are affected. Thresholds are used to assess the status. The thresholds were described in earlier posts.
Figure 2
In spite of these advantages, differential rates have a downside. The tight mathematical connection between Agile and ES is severed. In the absence of a single, standard rate, ES Release Date no longer follows mathematically from Agile principles.
In the absence of mathematical entailment, the relevance of ES to Agile in these cases devolves to practical justification. I believe that the benefits of different perspectives on schedule performance are cogent grounds for continuing to use ES on these Agile projects.
Notes
* Sulaiman, et al., Section 4.3.
** See the INVESTMnemonic.
*** As Rate is essentially a weighting mechanism, rates other than Resource Rate are possible. For instance, if Product Backlog Items are prioritized, the Release Points associated with them might be weighted differentially based on priority, with High priority items assigned more weight than Low priority items.
References
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.
Wake, B. (August 17. 2003). INVEST in Good Stories, and SMART Tasks [Blog post]. Retrieved from http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/.
Addendum
As a result of applying AgileES to a recent project, I have identified an additional impact of differential rates. The Earned Schedule baseline is assumed to run at the rate of one earned Sprint for each elapsed Sprint. To maintain that pace, Backlog Items must be selected with more than Release Point velocity in mind. The Planned Value of the Items must also be factored into their selection. The Planned Value must be paced at the same level across Sprints. That ensures the baseline will run straight from the end of the first Sprint to the end of the last planned Sprint for both Earned Schedule and Release Points.
[01 May 2017] |
