Estimates or no estimates?

At the end of all my Scrum classes I tell participants that I offer life time support of my classes. I encourage people to stay in touch and ask questions also after the classes. Today a participant took me up on my offer. I received the following:

”Our team has been asked to change from time estimates to point estimate. This is something we don’t want. Thus our enthusiasm for the decision is rather low. We have a hard time figuring out what will become better when estimating in points. We have not heard any convincing arguments. Maybe you have some?

We also want to know how to deal with points over time. If an item is estimated will it always keep this estimate? In other words, shall we always give the same estimate to similar items?”

My answer

Thanks for asking. I’ll be happy to elaborate on estimation. First of all, I assume that when you write “estimate in points” you are referring to relative estimation. Before getting into a lot of details I would like to raise another question first: Why are you estimating in the first place?
The answer to that question may be quite obvious. Nevertheless I find it of value to fully understand the purpose of doing different activities. A second question to ask is: Why was it decided to change from estimating in time (absolute estimation) to estimation in points (relative estimation)? It will be easier to advice you when I better understand your context. Feel free to update me on these two questions.

Without knowing the exact details behind your situations i can offer some general thoughts.

Relative estimation should be applied at the product backlog level. It is the items of the product backlog (PBIs) that we estimate relative to each other. The parts of the Sprint backlog can be estimated in time, if estimated at all.

I see clear benefits from using relative estimation (points) compared to absolute estimation (time). The major benefits are:

It takes less time
It is more accurate
It gets better the longer we use it
It requires less re-estimation
We don’t have to discuss my hours compared to your hours and thus spend less time arguing
We get the opportunity to use velocity as a measure of the productivity of the team
It gets even better when we include all team members in the estimation

Here is some food for thought

What if I didn’t know how long time it will take to travel from Malmö to Göteborg? I might ask some people to help me create an estimate. There is good chance that they will reply: ”It depends.” And they would be correct. It depends on my choice of transportation. Train, car or bicycle to give some examples.
If a team is asked how long time it will take to implement a feature it is quite possible that they will give the same answer. ”It depends.” In the case of the team it will depend upon which team member or team members are involved in working on the tasks need to implement the feature. Therefor it is not likely that an estimate of 120 hopurs will actually turn out to be correct. Maybe Charlie and Lucy started to work on the feature and after a week Charlie got sick. If Lucy had to continue by her self the amount of hours spent may be different or the same, and the time between start and finish would definitely be longer. If it was decided to ask Brian to replace Charlie we may have to consider getting Brian familiar with the feature before getting up to speed, and that can take longer time than what it would have done if Charlie was not sick. And so on.

My take on estimation is the following: You should spend as little time on creating estimates as possible. I prefer to leave it to the team to figure out how to estimate as long as they strive for spending less and less time on estimation. I also argue that rough estimates serve us well. Often it is good enough to say ”It will take us 2-4 weeks” or similar. Usually we don’t need to spend vey much time coming up with such a rough estimate. If we can afford the cost of working four weeks on a PBI then we have a go-decision. If we cannot afford to work even two weeks on this site, the we have a no-go-.decision. If we can afford more than two weeks but not a full four weeks we may need to spend some more time understanding the nature of the item before making a decision.

Unfortunately it is not always as straight forward as my example above. I’ve seen a lot of different situations. What I’ve also seen is that teams benefit from understanding their velocity, breaking PBIs down to small manageable pieces and to work on PBIs of similar size. When estimating relative, size is of essence. We are asked to estimate the size of the effort for implementing a PBI relative to the size of the effort for a PBI we are familiar with. By comparing we can determine if PBI B is bigger than A, similar size or smaller. We can then use the estimates to make a calculation and derive how long time it will take us to do something.

Let’s say the we have 20 PBIs, we estimate them relative. some PBIs will be estimated to 1 point, some to 2 points, 3 points, 5 points, etc. Let’s say that the sum of the estimates are 120 points. Now it is good to understand how much work the team can finish per iteration. Maybe that the team finish something between 15 and 20 points each iteration. We say that the team has a velocity of 15-20. By dividing 120 by 20 and 15 respectively, we can state with some certainty that it will take the team 6-8 iterations to finish implementation of the 20 PBIs. If 8 iterations is acceptable from a time and cost perspective then we start implementation. If 6 iterations is not acceptable we might decide to not implement or to negotiate things to cut from the scope.

The most successful teams when it comes to putting less time on estimates are those who are able to keep the team constant over time, are able to capture historical data of their velocity and those who are able to break down PBIs to similar size before starting implementation. IMO this means that the longer a team has worked together on the same product the better they get at estimation independent on what type of estimation technique they are using.

If your team is using relative estimation and it becomes obvious that the estimate of PBI X was too large or too small, then the team will most likely take that under consideration when estimating PBIs similar to X in the future. If we look at a product containing three parts (client, middle ware and back-end) it will be wise of the team to revise their estimates for the back-end if the back-end PBIs constantly takes longer time to implement than expected. The estimates for the client and the middle ware parts do not need to change.

The last year a movement called no estimates have gained traction. The argument is that if we create well understood, well broken down requirements of similar size we do not need to spend very much time estimating. We will get more time to implement and we will still be able to answer questions like ”When will you be finished?” and ”How much will it cost?” Some consider this movement very radical.

Finally

I would consider changing my way of estimation only if our current way is not helping us, and i would use relative estimation when I want to get more accurate estimates faster.