Concept: My posts on AgileES have thus far focused on “what” and “why”. That is, I’ve described the concepts behind AgileES and the benefits of using ES on Agile projects. It’s now time to shift the focus to “how to”. The next posts describe how to apply ES to Agile projects. There are several steps. Some of the steps, especially the initial ones, are controversial. In explaining each step, I will identify and address the issues and then describe the actions to be taken.
Practice: To apply AgileES, an estimate for velocity is essential. The first issue to be addressed is Agile’s challenge to estimates of any sort.
1. Estimate velocity.
For plan-driven projects, estimates are (or should be) a given. For Agile projects, estimates are considered, at best, questionable and, at worst, downright objectionable. The difference is evident in the charters of the two approaches.
On one hand, the PMI states that “Estimating is a critical part of project planning.”*[1] On the other hand, both the Agile Manifesto and the Principles omit reference to estimates altogether.*[2] The #NoEstimates movement takes the omission a step further: “Estimates are a waste of valuable time.”*[3]
The different perspectives seem to be rooted in disparate objectives. Canonical Agile projects seek the early and continuous delivery of the Product Vision, whereas orthodox plan-driven projects seek on-time and on-budget delivery of the Product Vision.
Schedule and cost constraints make a crucial difference. To deliver on-time and on-budget, you need credible targets for timeline and funding. Estimates set the targets.
Whether or not projects are ever free of time and budget constraints is a matter of debate.*[4] AgileES does not strive to resolve the dispute. It focuses on those projects that use the Agile framework but are bound by time and cost constraints. Still, in the details about execution, AgileES must acknowledge and respond to its variances from chartered views.
For projects in the AgileES scope, an estimate of velocity is necessary. Velocity is the expected number of Release Points to be completed during a Sprint. How is an estimate of velocity developed? Again, there are challenges from the Agile view.
In the Agile canon, velocity is taken to be a measurement, something done after the fact. It is not a target that is set for the future. As the Agile Alliance states, “phrases such as ‘setting the velocity’ reveal a basic misunderstanding.”* The Alliance goes on to suggest that there can be no meaningful comparison of velocity between projects. Finally, the Alliance associates velocity with units of value, not effort.* [5]
AgileES takes a different approach. It starts with a practice from the Scrum version of Agile: T-shirt sizing (or a comparable relative estimating technique). T-shirt sizes represent the relative sizes of Product Backlog Items (PBI). The ordinal measures are then calibrated.
Why calibrate the relative measures? The calibration quantifies the size of PBIs, facilitating calculations that would otherwise not be feasible.
Sometimes, ordinal values are quantified by an arbitrary number of Release Points. For instance, Small = p Release Points, Medium = q Release Points, and Large = r Release Points. Values of the variables are based on a geometric series or the Fibonacci sequence. [6]
Other times, the calibration is based on Work Breakdown Structure (WBS). The WBSs identify the tasks required to produce Product Backlog Items. Work Hours are assigned to the tasks, and the tasks are subsumed into Sprint plans along with the associated PBIs. The total of Work Hours represents the number of Release Points for the Product Backlog Item.* [7]
In either case, the PBIs and the tasks (if any) must have an unequivocal definition of “Done”. That is, they must be demonstrably either done or not done. In the plan-driven tradition, such measures are termed “Physical Percent Complete”. In the Agile framework, such measures are called “Ready to Ship”.
Contrary to the view of the Agile Alliance, there seem to be similarities in work across projects.* [8] Where relevant data is available, Work Hours are estimated for tasks based on comparable situations. As the project proceeds, the results obtained are used to update tasks and times. It can take as much as 25% of the timeline for velocity estimates to stabilize. Once stable, the estimates are reliable indicators of future schedule performance.
Finally, in AgileES, velocity is a measure of value, but the AgileES view of value is different from the typical Agile view.
In the Agile view, value is related to effectiveness: the Business Value of a project’s work reflects the effectiveness of the results in realizing the Business Vision.*[9] Measures of effectiveness require techniques such as Balanced Scorecard.*[10]
In the AgileES view, value is related to efficiency: the Earned Value of a project’s work reflects the efficiency of the process in completing the planned work. Measures of efficiency are calculated as, simply, Release Point * Rate.*[11]
Both senses of value are used in managing projects, but it is Earned Value that drives AgileES.
References and Notes
[7] The WBS, tasks, and Work Hours are based on experience with the delivery of similar Work Products in similar circumstances. In other words, the WBS, tasks, and Work Hours are normalized to the relevant context. This is neither trivial nor impossible to do. It is part of the hard work of estimation.
[8] See Reference Class Estimating in Alleman, G.B. Performance-Based Project Management. New York: Amacon. 2014, p 83.
[11] If the Release Points are related to Work Hours, Rate is usually understood as Resource Rate. If the Release Points are associated with a different calibration scheme such as Small-Medium-Large, Rate is usually understood as a Budget allocation.
|
