One of the most common questions we get is whether to estimate in time or points. It seems like points are used only “to avoid thinking about time” and they are essentially the same. Wrong.
Let us give you the travel metaphor to give you an idea about how we are thinking.
The Travel Metaphor
“Mom, dad, are we there yet?” Recognize that expression? Having problems answering it? Well, you have the same problem giving an answer to your kids as well as to your project manager.
Both will hold you accountable for your answer! And even though you have taken the trip to the grandparents a hundred times, you cannot be sure on how long it will take this time.
You know the distance quite well, but there are a multitude of things that can happen along the way. It may start to rain so you have to lower speed. Someone needs to pee an extra time. You forgot to fill up gas. There’s an accident and you are forced to take a detour.
So you answer “if nothing happens it will take about half an hour, kids.” If something happens, do they care? You said half an hour, didn’t you?
Your travelled distance per hour will be the same every time only if your speed is constant, which it is not. It depends on a number of things like weather, traffic or vehicle.
Compare story estimation with travelling. Your sprint velocity compares to your travelling speed, your story points to the distance and time will be of course the same.
Story points describes the complexity of the problem and that will be fairly constant over time, while time is a function of that complexity and your sprint velocity.
In the same manner, the distance between two cities will remain fairly constant over time but the time it takes to travel between them will vary.
But is not sprint velocity constant? We hope not. We hope that you will increase your velocity over time as you trim down all waste, increase team play and other improvements.
Relative estimation and reference stories
It is hard to estimate in absolute terms, such as out of the blue tell the distance between two cities. But you are surely able to tell if that distance is longer or shorter than the distance between two other cities. E.g. if you know the distances from London to Rome, you can estimate roughly the distance to Paris. This is how we work as humans. We can estimate in relative terms quite well but are not good at absolute estimation.
That is why we have reference stories on the wall when we estimate. A reference story is an example of a story that we can fairly well relate to. A new story can be compared to the reference stories and we can tell whether it is larger or smaller than each one of them.
You should have at least three reference stories. One small, one medium and one that is the largest you would allow in a sprint. Stories bigger than that gets sliced.
You use the reference stories to reason about your estimation with your teammates whenever your estimates diverge.
Also, your estimations will be more consistent over time with reference stories. If you estimate without them, you tend to lower your estimations as you go faster. Like if the distance travelled would shrink as your speed increased.
Remember, we are comparing complexity, which is expected to be stable. Not the time a story takes to reach done. That is different thing which depends on your current sprint velocity.
Why estimate time?
With what has been said, why should anyone consider time estimation at all? Well, it is often time that matters the most. But with relative estimation, if you know the velocity, you can derive the time. For instance, if the velocity varies between 10 and 12, and each sprint is 2 weeks, you know that in 4 weeks the team have delivered between 20 and 24 points.
Returning to the metaphor, people don’t care how far you have to go, they just want to know when you will be there.
Summary
- Estimation in points is estimation of complexity and you can compare it with estimation of travelling distance. Time is depending on sprint velocity and traveling speed, respectively.
- Estimate in points is easier to get accurate. If you estimate consistently, you may be able to measure process improvements in the form of increased velocity.
- To estimate consistently, you should have reference stories at hand to compare with during estimation.
At the end of the day, however, you will need to answer the question on your time of arrival.
Thanks for the article. Good stuff.
I always struggle with whether complexity or “approximate time taken to complete a story” should be represented by a story point estimate. As an extreme example, if the “story” is to write your name a billion times I would call this low complexity but I am pretty sure it would take a long time. At the other end I am sure there are examples of highly complex “stories” that are quick to complete (maybe in the case where the people working on the story are extremely familiar/skilled with what they are working).
As I understand the general concept of complexity, if you were truly to use this as a basis for a story point estimate (and completely ignore the concept of “time taken to complete” in the story point estimate) I would think the velocity would have quite a large variance from iteration to iteration (since two equally complex stories could have huge variance in time take to complete). I am taking team/velocity improvement out of the equation in this case.
“A new story can be compared to the reference stories and we can tell whether it is larger or smaller than each one of them.” -> same idea here I feel. Will it really work if you are truly comparing based on complexity only and not time taken to complete? With some content management system projects I have worked on recently there are often many non-complex stories that take a lot of time and we have gone towards story points representing size of a story (which is really a representation of time I feel, except we don’t get bogged down in hours) and not complexity. That has given us a little better predictability in knowing “when you will be there”.
Quite open for the possibility that there are things I am missing here.
Thanks for the feedback, Fredrik.
We are using the word complexity without explaining which complexity we are referring to. Our bad. The complexity we are thinking of is not of the solution, it is more the complexity of the tasks needed to accomplish the goal of the user story. For instance, a lot of tasks increases the complexity of the story, even though each task is simple in itself.
Whatever we mean by it, we wish to put things like team staff out of the picture to get a stable estimation. You do need to have a similar reference story to come up with that. If you are to write your name lots of times or translate a website, you need a reference story similar enough to relate to. Else you have not much of an idea.
We have not talked about precision but as a rule of thumb, you don’t get more than 80% accuracy so I wouldn’t worry too much about the variance in velocity.
Cheers from Per and Mike!
Thanks for the post Per and Mikael. A really useful companion technique I have used is James Grenning’s “planning poker party”. http://www.renaissancesoftware.net/blog/archives/36
Veldig, veldig bra skrevet! Tusen takk!
Nice post.
I love the metaphor of the travelling to story points.
I like the idea of the reference stories.
Thanks, Kevin!
“With what has been said, why should anyone consider time estimation at all? Well, it is often time that matters the most. But with relative estimation, if you know the velocity, you can derive the time.”
Because i am the investor and i ask you for the time so i can compute a feasibility study.