**Why estimate at all?**

In Scrum, the goal of estimation is not to reliably predict the future. It is about achieving clarity of what the Product Owner wants. It is about collaboration and information. So the estimates as such are a by-product. Yes, it is possible to forecast release date and content with agile estimates if you have a stable team with a known velocity. However, the far greater value lies in the fact that the team understands the wishes of the Product Owner and is now able to make decisions that conform with these wishes.

**Why relative estimates?**

Scrum does not force you to use relative estimation techniques. Scrum is just a framework and allows you to use any estimation method you want. This includes absolute numbers like man-hours or days as well. However, there are three main reasons for using relative sizes.

- People are bad at absolute estimates but good at relative ones. See the two stones below and tell me: How big is the first one and how big is the second (absolute estimate)? Now answer how much bigger the second stone is compared to the first one (relative estimate). Usually, people are quicker and better with the second question. So it is quicker and therefore cheaper to use relative estimation techniques.

- People don't argue over relative sizes as much as they argue over absolute ones. Ever heard two people fighting over who will do it because that influences the estimate? There you go.
- You do not have to re-estimate relative sizes with every change. If you estimated your items in days and something changes (e.g. you lose a programmer or get a new framework) you generally have to re-estimate the whole backlog. Let's say you need five minutes to estimate one item, your backlog consists of 100 items, and five people are involved in the estimation process: This means five person-days per estimation. With absolute numbers, you will need to re-invest five days whenever something changes. With relative estimation, you just need to invest this time once. Whenever something changes, the estimates remain the same and the only thing that changes is the velocity. This velocity is measured and not estimated, so you don't need to spend a buck on getting it.

**What unit are we estimating in?**

There is always some arguing about what unit we are estimating in when using relative estimates. Some people will tell you "complexity", some will tell you "effort", some will tell you something different. You can haggle over these terms for hours, if you feel like it. This doesn't get you closer to your goal though. All opinions are equally correct here. Actually, it doesn't matter what unit you use as long as the whole team agrees on it. This is usually difficult when choosing effort, since effort varies depending on many factors and actually is a kind of absolute estimation technique. You spare yourself many useless discussions by using "size" instead. Size is neutral, not directly connected to effort, and loosely connected to complexity. Even better: Everybody has an understanding of this term.

**Why use Fibonacci numbers?**

Most Scrum teams use some kind of altered Fibonacci scale to do relative estimates. Fibonacci found an interesting sequence of numbers: Whenever you sum up the two previous numbers you get the next one in the sequence. So standard Fibonacci goes 1-1-2-3-5-8-13-21-34-55-89 and so on. Most teams use a sequence similar to 1-2-3-5-8-13-21-40-100. The reasons are simple:

- If you ask a developer how much bigger something is compared to something else, she most often will tell you "twice as big". In Fibonacci there is no "twice as much" and thus people have to make a decision. Some will go for the higher number, some will go for the lower value. The important thing is the resulting discussion: Suddenly, people need to state a reason for why they chose their number. Comparing the reasons leads to a discussion that clarifies many different aspects for the developers. This discussion constitutes the true value of the estimation process.
- Many teams do not cling to true Fibonacci because in the upper regions "34", "55", and "89" imply a certainty that simply doesn't exist. Stating "40" instead of 34 or "100" instead of 55 transports a coarse-grained granularity that reflects the uncertainty in these regions. Simply speaking, the team tells their Product Owner by showing "40" that "this item is too big and has to be refined" while "100" basically means "this will never fit into a Sprint, more refinement is needed".
- The biggers the numbers, the greater the gap between them. This helps to illustrate that estimates become less reliable with growing size.

So Fibonacci numbers are excellent to facilitate discussions in the context of estimation.

**Can I use different types of estimates as well?**

Sure thing. What I have used (besides story points) so far are t-shirt sizes (XXS to XXXL) and animals (ant, frog, ... , giraffe, elephant). T-shirt sizes and animals help to foster understanding that we are estimating in size, not in effort. What is the effort of an elephant? What's its complexity? I can't tell. But I can estimate its size!

**How does relative estimation work?**

I like to explain estimation with a picture of some stones. Imagine you have three piles of stones:

Let's say a single stone from the first pile gets the number "2" assigned (well, it is the smallest stone we see NOW, but who knows if there will be a smaller one at some point in the future...?). Now we ask the team how big a stone from the second pile is compared to a stone from the first pile. They will discuss it and come up with a number. Probably "5" in our example. The same procedure follows for a stone from the third pile, which will probably result in a 13. Note that we didn't ask what we will do with the stones, yet. We are just discussing their sizes. We also didn't discuss who will deal with these stones. It doesn't matter when doing relative estimation.

As you can see, we have ten stones in the first pile, three stones in the second pile and two stones in the third pile. These constitute our "backlog": 10*2 + 3*5 + 2*13 = 51

So our total backlog has a size of 51. That was easy, but we didn't do anything with the stones yet.

Imagine my boss to be a nasty person. He tells me that he wants me to carry all the stones from one end of town to the other with my bare hands and without any tools. He also tells me to carry them back once I moved all the stones, so we have an infinite backlog. We agree on a Sprint length of one week.

I have no idea how long it will take to relocate all the stones. So there is no connection to time, yet. When I start carrying the stones around, it will take me the whole week to move all stones from one end of town to the other. So I moved ten small stones, three medium stones, and two big stones within one Sprint. This results in a velocity of 51 (the sum of all sizes completely moved within the Sprint) for the first Sprint.

Velocity1 = 51

My boss then forces me to move the stones back and forth every week. I start to grow some muscles. This does not only look great but also increases my velocity since I manage to move the stones back AND forth within one week. So I moved twenty small stones, six medium stones, and four big stones within one Sprint. The new velocity is 102.

Velocity2 = 102

The size of the stones did not change by me having muscles. What changed was the speed by which I moved them.

Now imagine my boss having a good day and allowing me to use public transportation. I now manage to move all stones back and forth twice within a Sprint, which results in a velocity of 204.

Velocity 3 = 204

The size of the stones did not change by me using the new framework "public transportation" or by me having carried so many stones within the past Sprints. What changed is my speed doing it.

As you can see, I do not have to re-estimate the stone size. I also did not estimate a single time value, e.g. how long it takes to carry a small stone from A to B. The time aspect comes into play when combining size estimates with velocity and Sprint length. So my boss is able to judge the amount of time it will take me to move any amount of stones as soon as he knows my current velocity.

This is true in the software development domain as well. When estimating in relative sizes, it does not matter if you have done this type of work a thousand times before, if you have fancy new tools, if the experienced or the inexperienced person will do the job. The estimate as such will stay the same. What changes is the velocity. That's it.

**How can we make sure that people know the estimation baseline?**

Some teams always estimate against last Sprint. This usually leads to a sizecreep: With growing experience, the size of new backlog items is reduced because the developers implicitly think in effort ("I have done that before so this is easier, which means it's not a five but a three now"). This leads to a stalling velocity instead of a slowly growing one. While this is not necessarily bad, it can be easily prevented. The key is a common estimation reference sheet. Just take a sheet of flip-chart paper and note all estimate categories down (e.g. 1, 2, 3, 5, 8, 13, 21). Whenever a Sprint is finished, ask your team if one or several of the backlog items completed was well estimated. Usually the team will come up with some items. These are then put (as sticky notes, for example) onto the flip-chart next to the numbers. Whenever the team estimates new Product Backlog items, they are compared to this reference sheet instead of last Sprint's estimates. This way the estimates remain constant over time but velocity changes. That's how it should be.

I hope this helps you when trying to use relative estimation techniques. Scrum on!

everythingand change the thinking of Scrum for you completely. A while ago I planned a sprint with my 5 person Scrum team and I used this motivation method to increase the velocity by 70%! The only things I needed for that was some Euros and the imperturbable believe in the power of the "hang a carrot in front of a bunny" effect. So I transferred this effect to my team and made a genius change...I replaced the carrot with a Döner andpowthe velocity increased by 70%. Promising my team to get a Döner if they beat the hell out of the story points was a big success. At the end I had costs of 18€ and an nearly empty backlog plus a good feeling going into holiday.At the end as some of you may have noticed I am just joking. Yes the story is true, but it was more a funny competition and should not stand for any serious method motivating your team with food or other stuff. The consensus of this comment is that in my opinion also for Scrum the fun at work, to enjoy what you are doing is one of the most important things. What in detail that is for your team you have to find out by yourself.