Comments on: Why You Should Not Estimate in Hours or Days

By: leon

leon — Tue, 26 Mar 2013 23:12:06 +0000

There are many good points made regarding involving the team from the beginning, adjusting the estimate accuracy as you go, and breaking stories down to detail tasks. But no matter how you spin it, or give a methodology a different, or even prettier name, an estimate is an estimate, and it is always going to be a key element in your planning. And what will you do without planning? It simply must be done, unless of course you live in a world where stakeholders will agree to anything you said without a commitment to dates.

By: Krishnakishore

Krishnakishore — Sat, 09 Feb 2013 18:00:31 +0000

An estimate is an estimate. May be a guestimate. But, it is not a lie! You cannot lie about wht you dont know!
I agree with using a size-based effort estimation, than directly jumping into time units.
Cheers,
kk

By: Peter Gfader

Peter Gfader — Fri, 08 Feb 2013 14:40:48 +0000

Nice article!

Story Points are not part of Scrum, but anyway a good abstraction from time.
The biggest advantage is that they force you to estimate relatively!

By: Dan Swain

Dan Swain — Tue, 16 Oct 2012 08:16:48 +0000

Kudos for getting whole teams in at the beginning. As a dev my big gripe is when project managers pick the most senior dev and QA and subsequently fail to deliver the problem or vision to the whole team. Which is frankly rude and disenfranchising for the members who are left out.

My question in these meetings is often what’s the business value. I’m hoping for a financial number or ball park thousands 10,000s or 100,000s. So rarely do I get an estimate, which is interesting. Our estimates have to be compared against something otherwise what’s the point of asking.

My real point is to question why we do the estimation dance, could we instead devise a simple experiment to see whether a feature’s worth it. For example instead of implementing a new product that would require automating various currently manual systems and processes to cope with demand.

What about if we simply put a button live advertising the product when clicked it would record the click and ask you to fill out a form or ring sales, This thinking is borrowed from the lean startup. The result is the number of clicks or intent to buy the product and the number who were so interested they contacted sales.

This could be USD to gauge demand and justify investment in the feature.

By: Five Blogs – 18 September 2012 « 5blogs

Five Blogs – 18 September 2012 « 5blogs — Tue, 18 Sep 2012 06:53:45 +0000

[…] Why You Should Not Estimate in Hours or Days Written by: Stephen Walther […]

By: Software Development Linkopedia September 2012

Software Development Linkopedia September 2012 — Wed, 12 Sep 2012 09:10:39 +0000

[…] Article: Why You Should Not Estimate in Hours or Days […]

By: Stephen Walther

Stephen Walther — Fri, 07 Sep 2012 22:03:15 +0000

@Tim – Agile teams make a commitment every sprint. The Development Team must commit to completing the work in a Sprint during the Sprint planning meeting. Because the team fully understands what they are committing themselves to, they are more likely to honor that commitment.

By: scrumxp

scrumxp — Fri, 07 Sep 2012 20:41:18 +0000

In reply to MrSuper. Thank you for your editing assistance MrSuper ;O)

By: MrSuper

MrSuper — Fri, 07 Sep 2012 20:20:58 +0000

Just a minor nitpick: “courser” should be spelled “coarser”.

By: Tim Goss

Tim Goss — Fri, 07 Sep 2012 20:07:47 +0000

“This desire is understandable but, according to Scrum, impossible to satisfy.”

Which is why the agile approach to software development is fundamentally flawed. It eliminates the need for developers or PMs to be accountable for anything but doing stuff. Goals aren’t as important as moving toward them, where ever they happen to be this week,