Stories, of course, are an XP idea, not a Scrum idea. Somehow, Scrum practitioners have adopted the idea. Even though the official Scrum Guide refers to backlog items, having backlog items be User Stories is a common Scrum practice.
We multiplied Ideal Days by a “load factor” to convert to actual implementation time. Load factor tended to be about three: three real days to get an Ideal Day’s work done.
think using them to predict “when we’ll be done” is at best a weak idea;
I think tracking how actuals compare with estimates is at best wasteful;
So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.
This makes me think that estimation, be it in points or time, is to be avoided.
It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible. Estimating, be it in story points or gummi bears or even time, gets in the way of this. Where possible, in my opinion, it’s best avoided.
slice stories down until they just need a single acceptance test.
But … isn’t there some legitimate need to know how long a product release will take, and aren’t estimates necessary for that? Well, perhaps, but perhaps not story estimates. You probably won’t even have your requirements down to the story level, and if you do, they are likely too bulky and largely waste.
We multiplied Ideal Days by a “load factor” to convert to actual implementation time. Load factor tended to be about three: three real days to get an Ideal Day’s work done.
think using them to predict “when we’ll be done” is at best a weak idea;
I think tracking how actuals compare with estimates is at best wasteful;
So if the existence of an estimate causes management to take their eye off the ball of value and instead focus on improving estimates, it takes attention from the central purpose, which is to deliver real value quickly.
This makes me think that estimation, be it in points or time, is to be avoided.
when we’re in the business of developing solutions for internal or external customers, we do best to provide small amounts of value frequently, not wait for Big Bang releases that seem often to recede indefinitely into the future.
It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible. Estimating, be it in story points or gummi bears or even time, gets in the way of this. Where possible, in my opinion, it’s best avoided.
slice stories down until they just need a single acceptance test.
But … isn’t there some legitimate need to know how long a product release will take, and aren’t estimates necessary for that? Well, perhaps, but perhaps not story estimates. You probably won’t even have your requirements down to the story level, and if you do, they are likely too bulky and largely waste.