Some people prefer to use hours/days to estimate a story’s effort complexity. Some prefer to use points. Which one is better? Which one do you prefer?
Netflix has newly released a movie titled “The Dawn Wall”. It’s about two people trying to climb the “Dawn Wall” face of El Capitan.
They have mapped out their route. To understand the difficulty of that route, you have to understand the climbing grades. Climbers use numerical system to rate the difficulty of each pitch. the higher the number the harder the pitch:
- Novice is from grade 5.0 to 5.6
- Intermediate is from 5.7 to 5.9
- Advanced is from 5.10A to 5.11B
- Expert is from 5.11C to 5.12B
- Elite is from 5.12C to 5.13B
- World class is from 5.13C to 5.15A
- Virtuoso is 5.15B and above
Climbers don’t use “hours” to rate the difficulty of each pitch. In fact, climbers will complete a pitch in their own unique way and time/duration of completion. Variations in “hours” of completion — the duration — is more volatile (wild variations) than the numerical system to rate the difficulty of the pitch. Over time, a grade – say a grade between 5.12C and 5.13B (an elite level) — is accepted and becomes a norm to measure an “elite level” type of a pitch; likewise for a grade between 5.0 and 5.6 (a novice level)… over time, it is accepted and becomes a norm to measure a “novice level” type of a pitch. The numerical system is stable; “hours”/”duration” is volatile.
Sequencing: the climbers also were mindful of the series of pitches they took on. They mapped out the sequence of pitches. Since the climbers can only do so many pitches in a given span of time, and there is an almost unlimited way to climbed the wall, it is therefore paramount for them to find the right sequence of pitches.
The lesser the volatility of anything is, the more stable it is… the more predictable it is… and hence you can plan better with it… just like how these two climbers planned — they used the numerical system, and not hours — their climbed to success!
Correlate that to Agile: we also use a numerical system (not “hours”) to rate the complexity of each story. And that numerical system is the Fibonacci sequence. Complexity increases not in a linear fashion (i.e. 0, 1, 2, 3, 4, 5, 6 ,7 ,8 9, 10, etc). Instead, complexity increases exponentially (i.e. 0, 1, 2, 3, 5, 8, 13, 21, etc — hence the Fibonacci sequence is very appropriate to represent this increasing complexity of things)! In fact, the modified Fibonacci sequence is favored by SAFe: 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity and “?”.
So, for new agile teams, how would they establish their own starting velocity? SAFe has prescribed this normalized approach for all new teams: in each team’s pool of work, find something that the team can code and unit test in a day and make that the team’s “1” point. This “1” point, from the get go, is based on the team’s perceived collective abilities, environment, experiences, etc. It is unique to them. A team’s “1” point effort is not the same as the other team’s “1” point effort. Example: I could easily lift 40 pounds and call it “1” point; however, my 12 year old daughter’s “1” point is 10 pounds only. This is the reason why we cannot compare one team’s velocity (the actual points delivered over a span of time) versus another team’s. Use the “1” point as an anchor to relatively estimate the effort complexity of the other work items. Example: if a work item is perceived to be three times more complex relative to the “1” point work item, then assigned a value of “3” points to that work item. If it is more complex than a “3”, then it becomes exponentially more complex… it is not a “4” (since complexity grows not in a linear way)… instead it could be a “5”, “8”, “13”, “20”, “40”, “100” points (since complexity grows exponentially)! Of course, there are other facets of effort other than complexity… we could look at the effort in terms “volume”, “how much we know”, and “how much we don’t know”. Just the same, we use the Fibonacci sequence — a numerical system to rate the effort/difficulty of each work.
With a less volatile way of measuring complexity, and over time (say a year), the team will have had further normalized the way they estimate stories — they are more predictive and are spot on with their effort estimates: they can quickly assess and estimate the complexity of a story based on or relative to the complexity of stories that they have had worked on in the past. By the same token, over time, the team will have had established their average velocity — how many points, on average, they can deliver, with high probability, within a span of time.
So, why use points? To summarize:
Planning: With less volatility — normalized estimation of effort complexity using points and normalized velocity — one can plan better with it. The business can plan better given a certain capacity.
Predictability: The lesser the volatility of anything is, the more stable it is… the more predictable it is… and hence you can plan better with it… just like how those two climbers planned — they used the numerical system, and not hours — their climbed to success!
Sequencing: since teams can only do so many points in a given span of time, and there is an almost unlimited work to do, it is therefore paramount to sequence and prioritize the work accordingly. The business can prioritize accordingly given a certain capacity.
Complexity: some people prefer to use hours/days to estimate a story’s effort complexity. Some prefer to use points. Which one do you prefer now?
Probability of Delivery: with known “number of points delivered over a span of time” (the velocity), we can plan for the number of prioritized stories (in points) that we can take on over a span of time vis-a-vis the team’s capacity (in points) over that span of time. With historical velocity known, we can predict with high probability as to how long (the Delivery of) a certain body of work in part and in whole .
Cost Calculation: sunk cost over a span of time divided by the velocity (in points) over the same span of time will give you the cost per story point. Example: $1,000,000 sunk cost for the year DIVIDED BY 10,000 points velocity for the year … yields a $100/point cost.
Buy the ‘factory’: with known historical cost and historical velocity (in points), the business can plan on how much money that is needed to fund the teams and train that sustain and grow the development value stream — the business buys the ‘factory’ and not the ‘cars’! Meaning they don’t fund projects; instead, they fund the development value stream… they fund the teams and train supporting the development value stream; the ‘factory’ continuously deliver value — ‘forever’ or until the business ceases — to customers/marketplace in reasonable time.
P.S. There is another climber story released by Netflix titled “Free Solo”… also an interesting story… but that is for another upcoming blog post.