This post originated from an RSS feed registered with Agile Buzz by Martin Fowler. Original Post: Retreaded: ThrownEstimate Feed Title: Martin Fowler's Bliki Feed URL: http://martinfowler.com/feed.atom Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development Latest Agile Buzz Posts Latest Agile Buzz Posts by Martin Fowler Latest Posts From Martin Fowler's Bliki

Retread of post orginally made on 22 Jun 2004

If you're using XP style planning, you need to get rapid consensus estimates from developers. Throwing the estimates lets you quickly tell when developers have same similar views on an estimate (so you can note it and move on) or if there is disagreement (when you need to talk about the UserStory in more detail.

Here's the basic sequence. The customer puts together the list of stories that need to estimated. With each story:

• The customer briefly describes the stories to the developers
• Developers ask clarifying questions about the story. They shouldn't discuss technical issues about how to implement, just ask about scope from the customer's point of view.
• On the count of three, the developers show fingers to indicate their estimate of how many NUTs there are in the story. I call this a thrown estimate because you can use the same style of pacing throws that you use for Rock Paper Scissors..
• If most estimates are similar the scribe notes down the estimate. If you get a significant variation in estimate then you should discuss the story further - bringing in the technical issues of how to implement it.

You can use different conventions for how many fingers to use. One project I've seen uses 1 or 2 fingers to indicate 1 or 2 NUTs and three fingers to indicate the story is too big and needs splitting up. Another group uses fingers for 1-4 NUTs and five fingers to indicate it's too large. Notice that it's important to have a convention to say that a story has a problem and can't be estimated - most often because it's too big, but also if it can't be tested or there's some other problem.

Teams using this report that they are able to estimate stories at a very rapid rate, avoiding much discussion on stories that are straightforward to estimate and concentrating time on those that are more problematic. This keeps everyone engaged in the estimating process. It also helps that it's fun.

reposted on 26 Jun 2014