The Artima Developer Community
Sponsored Link

Agile Buzz Forum
XPDAY2006: Experiments in Agile Estimation

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Simon Baker

Posts: 1022
Nickname: sjb140470
Registered: Jan, 2006

Simon Baker is an independent consultant, agile coach and scrum master
XPDAY2006: Experiments in Agile Estimation Posted: Dec 3, 2006 10:25 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by Simon Baker.
Original Post: XPDAY2006: Experiments in Agile Estimation
Feed Title: Agile In Action
Feed URL: http://feeds.feedburner.com/AgileInAction
Feed Description: Energized Work's blog.
Latest Agile Buzz Posts
Latest Agile Buzz Posts by Simon Baker
Latest Posts From Agile In Action

Advertisement
Experiments in Agile Estimation was a workshop, facilitated by Mike Hill, Nils Haugen and Stein Grimstad, that explored planning poker as a group estimation technique. For the first experiment we had to estimate user stories on our own. It looks like I have a tendency to be optimistic. Perhaps I'm too courageous? Or just stupid? Don't answer that! The second experiment explored how effective planning poker was with respect to individual estimation.

The statistical evidence collected to date (as part of the research conducted by Nils and Stein) was not presented very clearly (take a look at this pdf). But they observe a tendency to overestimate when using planning poker. Nils asked an insightful question: Is it actually a tendency to finish under the estimate? Looking at the results from an analysis of the code written on the projects used in the research sample, work estimated with planning had, on average, twice as many deleted control statements (perhaps indicating an effort to do the simplest thing) and twice as many deleted out-of-class references (perhaps indicating an effort to reduce coupling). So, does planning poker positively affect the quality of implementation? I'm not convinced.


Planning poker cards
Originally uploaded by sjb140470.
Planning poker is definitely fun, and lets face it, estimation is something we all hate doing. It gets everyone involved and talking face-to-face. And the group discussions draw knowledge from many sources, help to explore uncertainties and reveal more hidden detail before estimating. Planning poker incorporates participatory decision making and is effectively consensus-driven. Reaching an estimate as a group gives developers a sense of comfort as they collectively own the estimate and it also gives them more confidence in the estimate. The technique can feel cumbersome when you first start doing it. However, once people get used to it the actual overhead is very low. But be careful that discussions don't take too long.

One person at the session thought the use of cards was unnecessary. I disagree. Always use the cards. They make it clear that everyone is engaged and participating and it helps retain a structure to the proceedings. Without structure, group discussions can quickly become wasteful.

Originally, we used index cards with numbers written on them. Now we're using nice glossy cards that Conchango were handing out at the Agile Business Conference. We're using ideal pair days as estimation units (and not story points) so the only cards we use are 0, 1/2, 1, 2, 3 and ?. User stories that get a ? are split into smaller stories.

Here's how we do it:
  1. The product owner reads the user story aloud adding further details as necessary.
  2. The team asks questions about the user story.
  3. As the discussion tails off, the facilitator says "Ready" and asks "Do you have enough information to estimate this story?".
  4. When everyone responds "yes", the facilitator says "Steady. Select your estimate." Each person then selects their card and holds it out in front but does not reveal the number to the rest of the team.
  5. When everyone is holding a card out, the facilitator says "Go" and everyone reveals their estimate by turning their card around to face the team. (Simultaneous revealing of estimates might reduce an anchoring effect where people who reveal their estimates early influence estimates from others in the team.)
  6. The facilitator asks the people with the lowest and highest estimates to explain their selection.
  7. The facilitator says "Lets do another round". Go back to 4.
  8. Loop through points 4 to 7 until all the estimates converge at a single number.
Mike Cohn describes planning poker in the sample chapter, Techniques for Estimating, from his book Agile Estimating and Planning.

Read: XPDAY2006: Experiments in Agile Estimation

Topic: Technophobes unite Previous Topic   Next Topic Topic: Scrum and XP from the Trenches

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use