# Estimating techniques

Lasse Koskela
author
Sheriff
Posts: 11962
5
I've seen a lot of people estimate in calendar days, full-time equivalents, etc. but all the time I've been reading about methods suggesting that estimates should be made using some weird point system.
I'd love to hear explained opinions about the pros/cons of using time versus using points. I know how well the time approach works. What I'm still wondering (without 1st hand experience) is how well the point stuff works?
I understand that there isn't (shouldn't be) much difference between fitting hours into a schedule and fitting points into a schedule. What I am worried about is whether this artificial abstraction (reality -> points -> reality) really helps improve the estimates or will it make them even more inaccurate?
Does XP suggest a particular method of producing estimates for stories etc.?
[ May 16, 2003: Message edited by: Lasse Koskela ]

Ilja Preuss
author
Sheriff
Posts: 14112
Vanilla XP suggests using an arbitrary, but proportional, point system and estimating user stories relative to each other. The advantage is that you "decouple" "how hard is this to implement" from "how much can we do in an iteration" - in fact, the latter is measured based on previous iterations.
On the other hand, that "decoupling" is also hiding some issues: if you can do stories worth 30 hours a week, what are you doing the other 10 hours?
What approach works better seems to mainly depend on
- how good your team is at estimating (IMO, using arbitrary points is easier to start with), and
- how willing is your customer to accept that you simply can't spend *all* of your time coding.
Did that help?

Mark Herschberg
Sheriff
Posts: 6037
I must've missed then in the XP books (or forgotten it). Can you explain it in more detail? How exactly do points differ from time?
If something takes me X hours to do, I can also define it as X/8 days, or X/40 weeks (just as an example, obviously there is overhead so the translation isn't linear). How do points differ? It sounds like points are just some arbitrary time scale.
--Mark

Lasse Koskela
author
Sheriff
Posts: 11962
5
Originally posted by Mark Herschberg:
How exactly do points differ from time?

This is exactly what I've been wondering. To me it seems that the points approach can only erode the estimates with the added complexity. On the other hand, using the abstract "point" could help communication by removing the classic "what do you mean by 1 day?" issues.

John Hembree
hired gun
Ranch Hand
Posts: 250
This sounds a lot like the Function Points days. Are there any similarities?

Lasse Koskela
author
Sheriff
Posts: 11962
5
Originally posted by John Hembree:
This sounds a lot like the Function Points days. Are there any similarities?

Yeah. Function Points have been the most common "term" for the points based estimation techniques I've read about. Probably there are a lot of similarities but I somehow suspect there are some important differences as well...?

Frank Carver
Sheriff
Posts: 6920
Mark wrote: How exactly do points differ from time?
If something takes me X hours to do, I can also define it as X/8 days, or X/40 weeks (just as an example, obviously there is overhead so the translation isn't linear). How do points differ? It sounds like points are just some arbitrary time scale.

The way I use abstract units in this case is to peg them to "ideal days" (or ideal hours, for very short tasks). This seems to work, especially for developers with a little experience working solo, but who haven't developed the cynical trick of overestimating to mask inefficiencies and risks.
This helps in several ways. First, it helps decouple the process of estimating the work from estimating what external factors might interfere with it. Second, it helps highlight the time spent on holdups and other interference. Third it allows estimates to be compared and reused even in quite different parts of the project lifecycle.
In some teams, this sort of estimation is only used within the team, out of fear of a "pointy-haired boss" using it to try and force 100% utilization. In other teams, it is a vital tool to inform team leaders and managers of the amount of stuff that gets in the way of producing solutions, and thus how much it is costing the business.
As with all estimating systems, the vital bit is to record and track both estimates and actuals, and learn as individuals and as a team to make the estimates more repeatable and useful.

Ilja Preuss
author
Sheriff
Posts: 14112
Originally posted by John Hembree:
This sounds a lot like the Function Points days. Are there any similarities?

Not many, from all I know about function points (which isn't that much).
The main differences seem to be to me:
- Function Points don't take the implementation side into account, whereas the Planning Game does
- FPs seem to be rather formally defined, whereas in the Planning Game points are used quite informally

Ilja Preuss
author
Sheriff
Posts: 14112
Originally posted by Mark Herschberg:
I must've missed then in the XP books (or forgotten it). Can you explain it in more detail?

Imagine you have already done some iterations. Now you need to estimate a story.
What you do is, compare it to some other already done stories. Does its complexity look like an earlier three point story? Give it a three. Does it look around twice as costly as a one point story? Give it a two.
So, how many stories can you do in the next iteration? Sum up the points of the stories you completed in the last iteration. Adjust for known differences like vacations etc.
If I remember correctly, this is also explained in a similar way in "Planning Extreme Programming".
How exactly do points differ from time?
If something takes me X hours to do, I can also define it as X/8 days, or X/40 weeks (just as an example, obviously there is overhead so the translation isn't linear). How do points differ? It sounds like points are just some arbitrary time scale.

Especially for inexperienced teams, points reduce pressure in two ways:
- pressure to estimate correctly. It seems to be much easier to simply compare two stories with one another (A seems to be twice as hard as B) than to estimate how much actual time it will take you
- pressure to work to the estimate. If you estimated a story to be worth two days of work, you are more likely to drop important practices like unit testing or refactoring just to make it happen - which will slow the project down significantly in the long term.