Comments on: Estimation: Time or Size?

By: Spgv

Spgv — Fri, 06 Feb 2009 09:08:58 +0000

Hi, Can someone provide me steps to use story point size estimation.
From Product Backlog, to sprint backlog to burn downs.
Would need to be story points?
What about the availability of the team in terms of man hours? Where would that be accounted?
Finally when we say velocity is points per iteration, should it also factor in the team availability per sprint?

By: Lee Cunningham

Lee Cunningham — Sat, 21 Jun 2008 22:33:03 +0000

It is truly amazing to see how we have become so religious about the estimation techniques we use. The estimation debate is nearing the ridiculous pitch of the language and platform feuds that grew so wearisome a decade ago. There’s even a small band of rebellious bloggers now who claim that their agile teams are so “mature” that they need not waste time estimating or planning sprints. I guess that’s one way to quiet the discussion.

The objective of a sprint is to deliver a potentially-shippable increment of functionality that (a) consists of as much of what was most valuable to the business at the time of sprint planning as possible, and that (b) the team can commit to. The fundamental idea then, is that the team will deliver as much business value as it can every sprint, and by extension, every release. It is assumed that teams are self-motivated, and that they will strive to conscientiously commit user stories into the sprint backlog and then to deliver them (in other words, no sandbagging and no “self-management” cop outs).

If a team is consistently delivering what is the “next most important” functionality to the business, does it really matter what units are used for estimation? If something works for the team within the context of its particular organizational environment, then it is the right thing to do.

I would, however, insist that your team doesn’t use a “toy” language like VB, and make sure it uses a “real” Oracle database…

By: Gareth Powell

Gareth Powell — Wed, 30 Apr 2008 14:54:23 +0000

I claim that part of the inspiration for this post was a series of conversations I had with Tobias in the first half of last year. I was, and remain, a big believer that only real things are real. Story Points are an illusion. At the time he directed me to this post, but in spite of his urging that I write my thoughts down and post them here, I didn't have time to organize that. I'm now on a gig at Aggiorno, and I was involved in a similar discussion, which led to the conclusion that the time had come to be more precise about why I believe that the process of estimating is simultaneously completely broken and useless, and of foremost importance. The article I wrote attempts to describe the two things that I find most egregious about story points: firstly, the huge amount of reality that they ignore (complexity is so much just one dimension) and the fact that they have no meaning to the most important people on the project: the customers and users.

By: Sean

Sean — Tue, 15 Apr 2008 14:09:09 +0000

I’ve become a believer in the story points school of thought as well. The point Tobias makes that there are a finite number of hours in a sprint is a compelling argument.

Point-based story estimation is relatively stable. Sure, as teams get better at estimating, a “medium” story may be a “small” one if it were estimated after 5-6 sprints. It’s still a pretty stable measuring stick. Contrast to hour-based estimation, which is constantly a moving target. As team skill and productivity grows, estimates for comparable stories will shrink. There’s no way you can measure project velocity that way. It’s like trying to figure out how well your diet is going by weighing yourself on a different scale every week.

By: Shailesh Chaphekar

Shailesh Chaphekar — Mon, 03 Mar 2008 05:59:46 +0000

For my first 2 sprints, I used ideal hours and never thought it was a problem doing so.
However at the end of Sprint 2, I wanted to compare work delivered in Sprint 1 vis-a-vis Sprint 2 and then realised that I could not baseline them on hours estimated because the complexity of work delivered was different and hours don;t talk complexity because they include the capability of the resource (or the pair) who worked on the story.

Estimation in hours should be done as a pair, but you don’t know what mix of resources you will have. One resource in the pair may be better than the other.

I have started believing that Story points will be a better approach as you move to a level where your capacity to deliver is estimated at a team level and not on the type of resource you will deploy, which is the case with estimation in hours.
It is more like estimating project work in Function Points/Use Case points.

The question however is how do we define story points and since the technique is not known most of us go with time estimation. Any dope on defining Story Points?

By: Lars Salomonsson

Lars Salomonsson — Sat, 12 Jan 2008 20:34:59 +0000

I have always worked with days, i.e. ideal days. Not hours. I have not yet tried story points because I feel it’s difficult to describe and understand. Why do you work with hours instead of days? I mean it is better to be roughly right than exactly wrong in time estimations.

By: Ralph Miner

Ralph Miner — Mon, 17 Sep 2007 13:36:25 +0000

I personally like story points – because estimates in hours can set the wrong expectation. However the argument that I have heard in favor of estimating in hours is that it would make it easier to roll up status when the organization is running multiple agile projects. There tends to be more variation about what a story point is compared to what 16 hours is.

By: Preetam Reddy

Preetam Reddy — Thu, 26 Jul 2007 06:06:40 +0000

I believe estimation, weather based on time / effort or size or anything else, remains an estimation. The only way to plan ahead is to use velocity (historical, if available, or assumed – as a part of bootstrapping the project). Velocity – the actual number of estimation units achieved in the past iteration(s), irrespective of the nature of units – will enable you to plan the amount of work for the next iteration. The key is to understand that estimates and estimates – and not actuals / real – and to ensure that the estimation is consistent across stories (can be ensured by triangulation or other methods).

By: Ahsen Jaffer

Ahsen Jaffer — Fri, 29 Jun 2007 14:58:46 +0000

In the Scrum Master training, my team was exposed to the planning poker technique, but we could not take the leap of faith, and got stuck with estimating in hours.

I agree to the benefits of story points, as a better way to measure ‘value’ being generated, but this point seems (to me) the crux of the whole argument:

“A measure of size allows a team to show they are creating more value for money. … A measure of time will never show this, because there are always a fixed number of working hours in an iteration.”

By: Michael James

Michael James — Fri, 29 Jun 2007 09:02:46 +0000

I became a believer in story points + velocity after being a programmer on a team that switched from hours to story points. Apart from the initial paradigm shift it’s simpler, easier, and gives the Product Owner better feedback about how to adjust scope to hit a delivery date.

We could argue about theory all day, but my experience has convinced me story points are better for most situations.
–mj