Relative Estimation - Change Your Viewpoint!
/
Fibonacci Sequence
Relative estimation seems such a simple concept. Given a list of things, can I arrange them in the order of a chosen attribute? Given my backlog can I put the items in order of “size”?
But, I guess we should take a clue from Newton and Leibnitz. Newton framed his theory of motion in terms of absolute space and absolute time. In contrast, Leibnitz argued for an understanding of motion in relative terms. Newton’s view was easier to understand and manipulate, so won out for a long time. It took until Einstein in the early 20th Century to realise that Leibnitz’ view is more correct than Newton’s.
Our minds seem to find it easy to think in terms of an absolute scale, but much more challenging to think about a relative scale. Can we find a way to estimate centred on the relative size of different backlog items rather than trying to establish an absolute size for each backlog item?
Transitioning from Absolute Estimation
My experience working with teams is that the move from absolute to relative estimation can be really problematic. We are inhibited for many reasons, including:
Need for safety - absolute estimates give us at least the illusion of precision, when we use relative estimation we need to be comfortable with the ambiguity that remains.
Need for objectivity - many teams use some formality in the way they try to create absolute estimates, some even use very complex approaches such as Function Points. With relative estimation we need to be content with a consensus of opinion.
Need for justifiability - what happens when estimates go wrong? In organisations that don’t feel safe there will often be “the hunt for the guilty”. Teams suffering in these organisations feel the need to justify their estimates.
But we don’t help ourselves, either, because we talk about the move to relative estimation in confusing and, possibly, contradictory ways.
Confusing Messages
We introduce the idea of relative estimation. We emphasise that we are dealing with highly uncertain data. We emphasise that there is probably still a lot we don’t know about the requirements we will be delivering. We talk about the need for simplicity of approach so that the effort we spend estimating (and planning) doesn’t consume all of the effort available for work…
…Then we ask the team to assign a number drawn from the fibonacci sequence (you can google it).
Not surprisingly, the team is confused. What is the meaning of the number? If their most recent experience is an absolute form of estimation they are probably thinking of effort or duration. But then, why a number from the fibonacci sequence? Is that just magic? If an item can have a “5” then why not a “6” or a “7”? Why do we have to jump to “8”?
Forget The Magic, Gamify
Let’s go back to first principles. The essence of what we are trying to achieve is a sequence of items arranged in order of “size”.
One of the first agile games I learned (many years ago) was the relative estimation game. This addresses the idea of size sequence directly (size sequence is, of course, different from priority sequence). The game proceeds like this:
1. First team member pulls an item from the backlog and places it on the board
2. Next team member pulls another item and places it above (bigger), alongside (same), or below (smaller) the first item and explains their choice
3. Next team member either moves the item just placed or pulls another item and positions it above, alongside or below and explains their choice
4. Repeat step 3 until there are no changes to the sequence
For simplicity, we can choose to flatten the sequence by choosing an order for items currently alongside each other. We can further elaborate the game with discussion amongst the team and rules to stop “deadly embrace”.
No hint of numbers drawn from some arbitrarily chosen mathematical sequence.
No hint of numbers.
But this is not yet “estimation”. So how do we move from size sequence to estimates?
Motivation
Back to first principles, again. What is our motivation for undertaking relative estimation? In the agile world we are not seeking estimates of effort or duration - that’s absolute estimation. Rather we are seeking confidence that the work we will commit to doing in our next planning horizon is likely to get completed.
Actually that’s all we can achieve with absolute estimation, too. For all our formalism, for all our talk of time and effort, for all our work to achieve precision, the doubt and uncertainty in our requirements means that we can only achieve a degree of confidence that what we plan will be delivered.
So how can we achieve better results with “less certainty” in the agile world? First, our planning horizon is short - certainly very much shorter than a typical project or phase - we can reset expectations on a more frequent basis. Second, because we repeat our processes over time, we can practise our relative estimation and genuinely get better over time.
Estimation Categories
Now we have reminded ourselves of our motivation, we can take the step from size sequence to estimate. Remember, these are estimates to give us confidence that we will achieve our commitment. They are not estimates of effort or duration.
We choose a small number of categories that we want to use. Ideally we use only 3 or 4 categories. We split the sequence of items we created earlier into these categories. We can follow the same rules that we used to establish the sequence in the first place:
1. First team member positions the first category divide between any two items in the sequence and offers an explanation of their choice.
2. Next team member either moves an existing category divide or positions the next available category divide and offers an explanation of their choice.
3. Repeat step 2 until there are no changes in the positioning of the category divides.
Still no numbers - or any other labels come to that! But we can introduce them now, if we want - if they are going to help us. We choose to label our categories. Notice that phraseology, we are labelling categories, not estimating individual items. The labels can be whatever we want:
Fibonacci labels - perhaps 3, 5, 8 and 13 - the team can choose suitable start and end points
T-shirt size labels - “S”, “M”, “L” and “XL”
Animal labels - “Mouse”, “Cat”, “Dog” and “Horse”
Solar System labels - “Asteroid”, “Moon”, “Planet” and “Star”
Relative Estimation Process - with thanks to Damian Harries
The final step is for the team to look in more detail at the category containing the “largest” items. We challenge the quality, understandability, achievability and implementability (are those words?) of the items in that category.
Very often teams will reach the conclusion that the items in the “13”, “XL”, “Horse” or “Star” category are not actually ready for work, but need to be further refined.
You can click the thumbnail image to see the process full size.
Card, Conversation, Confirmation
Here’s one of the keys to successful preparation for planning. At every stage that we have gone through we encourage discussion across the team about the different items. As we build the sequence, each item and its relative position is discussed across the team. As we position the boundaries of the categories there is discussion amongst the team. As we assess the validity of the largest items there is discussion amongst the team. The picture we end up with is the consensus view of the whole team.
Using The Estimates
We have our size sequence, our categories and, consequently, our estimates. When it comes to planning our next delivery horizon we use our experience to assess which items will fit within our available capacity. This may be expressed in terms of a total number of story points - we choose items such that the total number does not exceed our historical achievement. Or it can be expressed in terms of patterns - previously we managed to deliver 3 Mice, 1 Cat and 2 Dogs or 2 Asteroids, 2 Moons and 1 Planet.
This is where we re-focus our attention on priorities - the “default” sequence of our backlog. The whole process so far has been focused only on the highest-priority items. These are the only items that are likely ready for work and therefore capable of being sequenced and sized. As we plan, we focus on the highest priority items and we add these to our plan until our available capacity is consumed (don’t forget slack).
A Different View of The World
What have we achieved? We have changed our viewpoint. We no longer consider items from our backlog in isolation. We are always considering a backlog item in the context of one or more other items - we are always truly considering a relative value.
Many agile estimating techniques - even well recognised ones such as planning poker - place the estimate first. The estimate is the starting point - the “first-class attribute” - and the size sequence is derived from values of the individual estimates. These techniques do not make a clean break with our prior experience. Consequently we are anchored by our prior experience, plagued by irrelevant questions and find it challenging to adopt a radical new view of how to estimate.
Our radically different view is to make the size sequence the starting point - our new “first-class object”. Then we derive the estimates from the size sequence simply by partitioning it into fairly broad categories. The concept of estimation as a process is removed from our thinking - rather we think of establishing the size sequence and its categories as the process. Now, the meaning of the estimated value no longer confuses us because it’s just a conveniently labelled category within the size sequence.
Clarity at last.
“A sequence works in the way a collection never can”