Late to the party, but has anyone mentioned T-Shirt sizes? That's
almost always my preferred method as it's the most abstract and the
hardest to "game". Of course it's predicated on doing commitment based
planning rather than velocity based planning which some teams don't
like. In my view getting the team wrapped up in velocity numbers
(which we really only care about for long range planning of releases
and such) is high risk and low value. But that's just me. :)
--- In firstname.lastname@example.org
, Angela Druckman
> Yes, thanks -
> I have a technique that works well for my teams- we estimate only
with story points and don't use hours at all. My teams have
consistently estimated worse with hours than with a more relative
scale. I was more curious what others are doing and what they have
> ----- Original Message ----
> From: hmeftah <hmeftah@...>
> To: email@example.com
> Sent: Wednesday, September 3, 2008 2:52:43 AM
> Subject: [scrumdevelopment] Re: Estimating - with story points,
hours or both?
> Hi Angela,
> Use story points to estimate your backlog, apply your team velocity,
> translate in days or hours if you want to.
> Don't worry about tasks duration, some of them may be longer than
> expected, the aim is all should be done at the end of the Sprint.
> The best thing in Scrum is stories are time boxed, coupled with an
> iterative development to deal with the uncertainty of the requirements.
> Have a look to the good book, Agile Estimating and Planning.
> Don't forget the first Scrum quote: " Inspect and Adapt".
> Each project and team are unique, some concept may work with one
> team/project but fail with an other.
> H. Meftah