New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Article: User Story Estimation Techniques
Posted by Floyd Marinescu on Jul 07, 2008
Read User Story Estimation Techniques, by Jay Fields. In the article, Jay covers:
- Powers of two
- Use four values
- No averages or numbers not on the scale
- Vote independently
- Take the largest estimate
- Large estimate gaps
- Required involvement
- Pigs and Chickens
- Estimation group size
- No laptops
- Required participation
- Stale estimations
- Bribes
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
SCM best practices for multiple processes, releases & distributed teams
Agility at scale, become as agile as you can be
A practical guide to choosing the right agile tools
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Related Sponsor
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Good job
by
Al Tenhundfeld
Posted
Spot On
by
dale moody
Posted
RE: vote independently
by
Arnon Rotem-Gal-Oz
Posted
Thanks for sharing, thought i would share our story estimation technique
by
keith gardner
Posted
Re: Thanks for sharing, thought i would share our story estimation techniqu
by
Rick Leandri
Posted
Voting on estimation
by
George White
Posted
Different values and gaps management
by
Andrea Maietta
Posted
Re: Different values and gaps management
by
Dave Rooney
Posted
Re: Different values and gaps management
by
Jay Fields
Posted
Re: Different values and gaps management
by
Dave Rooney
Posted
Re: Different values and gaps management
by
Vladimir POPOV
Posted
Delphi Technique
by
Maurice Hagar
Posted
Fibonacci & Faites vos jeux
by
Martien van Steenbergen
Posted
Re: Fibonacci & Faites vos jeux
by
Jay Fields
Posted
How do short estimation meetings relate to the Sprint Planning meeting?
by
Fred Scefi
Posted
Is there nothing about design?
by
Wang Hongtao
Posted
Should entire team be involved in Effort estimation?
by
Rupesh Dubey
Posted
-
Jay, thanks for the article. It's clear, pragmatic, experience-based, and most important, full of great tips for teams new to the user story world.
They're all good suggestions, but if you're trying to introduce this practice to a new team and are feeling overwhelmed by the list of things to remember, I recommend the first two and last suggestions: use 4 powers of 2 for estimates and bribe the team with treats. -
A section I would add - Limit the length of sessions. The quality of my estimates start to degrade around the 30 min mark. For me anything over an hour and I can't remember my name never mind the title of the story I'm supposed to be estimating.
Estimation fatigue results in people switching off. To hide this fact devs tend towards the middle estimate as it reduces the chance they will be forced into a conversation about the story.
If you see anyone wilting call a halt - they probably aren't the only person struggling. I find a short break only results in a short boost, best to come back tomorrow when everyone is fresh.
On the other hand - if estimation is taking too long perhaps you're estimating too far ahead or your domain expert/BA/PM hasn't properly prepared. -
What we do is use our cellphones. Everyone keys in their estimates and then we compare notes :)
Arnon -
I have recently changed jobs and came from position that had a co-located team to my new position where we are a distributed team. Also I am moving my new group from waterfall to scrum (it is a good fit due to changing priorities, seems like about every 2 -3 weeks. Changing priorities seem to be the norm in the organizations that I have worked for.).
I have done the poker planning at our estimation sessions with cards with some success, in my previous company, although we seemed to face the following challenges:
• Getting everyone to show their cards at the same time (showing cards, all at once, is a lot more challenging then one would think).
• Seeing all the cards to determine high/low.
• Making sure that everyone is focusing on the story at hand.
• When someone was remote (seems like there are always someone), trying to get them to be able to participate (let them say their number after everyone in the room is ready with card in hand, then show everyone else’s in the room. Making sure that they had all the details for the story and could hear the conversations, and follow where the team was)
I recently found a free poker planning tool that I really like:
• www.planningpoker.com/ (From Mountain Goat Software)
We also use Rally to manage our user stories:
• www.rallydev.com/
Our estimating sessions go like the following:
• In prep: A day or two before the planning session the product owner and scrum master get the user stories cleaned up (adding conditions of satisfaction, making sure there is enough detail, and prioritizing).
• In prep: A few hours before the planning session, scrum master exports the user stories from rally into the planning poker tool. I arrange by priority, because we time box our meeting to an hour and make it though as many stories as we can. We then have follow up meetings (if needed) to get through more. If we got through the higher priority ones (and any other expected to be picked up by the team) we can then go into a planning session and prioritize before next sprint.
• We use a conference call (meet me) and all have the planning poker session up and rally (we have also used web ex to allow everyone to see the same information but seems better to have everyone drive what they need to see to be effective).
• The tool facilitates and enforces showing of cards for everyone. This works great, removes a lot of the problems. (additionally the admin (scrum master), can enter in the final estimate)
• The tool also shows only the story at hand, along with the cards.
• As we flush out the user stories, questions and clarification for stories are brought someone on the team updates rally. An effective scrum master will make sure that everyone has a chance to add some clarity and keep people on there toes as discussion is facilitated.
• We do a few hands of cards until we are close to agreement, with discussion for outliers (usually high and low, but not always).
• The tool keeps track of all the estimations for the whole session.
• After: Then we plug the numbers back into rally.
I really like the way this works, and in my opinion is better then using cards in person. -
A tool that I've found helpful is planningpoker.com. It allows multiple team members to vote on a story. The estimations it produces are more fine-grained then the four point system advocated here (I do prefer Jay's suggest, since it keeps the focus on general levels of effort). Still this is an interesting tool for team estimation and voting.
-
Great article, I'd only like to share our slightly different technique.
We choose Fibonacci numbers for our estimates, as suggested by Mike Cohn, and we find them very useful. We also have 0 and 20 cards, but we seldom go 13 (that leaves us on a five values scale) and we practically never use them.
About the tool: we went agile, took a colored paper sheet and cut it in regular pieces, upon which we scribbled our numbers. There you go planning poker! Outdated visiting tickets can be effective too, and they also have the advantage that they spare you the cutting.
I think cutting the estimating of a story picking the greatest value can be really time effective, but for small teams I still think that a (brief) discussion about the chosen values (and the hidden risks) would improve the global understanding of the project. -
I think cutting the estimating of a story picking the greatest value can be really time effective, but for small teams I still think that a (brief) discussion about the chosen values (and the hidden risks) would improve the global understanding of the project.
When using Planning Poker with larger groups, I've observed that you have a couple of low estimates, a couple of high ones, and then a cluster of estimates somewhere in the middle. I generally ask the high & low estimate providers to explain their reasoning in case there is something that the other people didn't take into account. Most often, though, the estimate used isn't necessarily the highest but rather the one from the cluster.
Dave Rooney
Mayford Technologies -
Great article, thank you Jay.
I'd like to share an observation regarding power of 2 versus Fibonacci numbers. We have used power of 2 for our estimates, but found it to be a bit to "flat" at the project level. So we changed to the power of e. Interesting thing is that odd positions in Fibonacci sequence are very close to power of e. I.e. 1, 3, 8, 21, 55... In real life complexity level 1 to 5 is used. The last grade is used to filter stories which need to be re-estimated. -
Hi Dave,
Consistency is the most important thing. If you always take the middle of the road, that's almost as good, imo. Discussing it further might be helpful, but here's 2 things to think about. For one, you might get more information, but is it really valuable at that point? I've found that usually any discussion leads to going middle of road anyway, and the extra discussion usually brings out more info, but not info that the entire team actually needs. Not everyone needs every detail. Two, you don't want to discourage large estimates. Sometimes people just get a feeling that something is bigger, and that feeling is usually correct. If you force them to explain, they might give lower estimates, despite their feelings. Of course, if someone always over estimates, that's not a big deal, because we are back to consistency.
I think you're good either way truthfully, but I find taking the largest estimate to be the most efficient and participant friendly.
Cheers, Jay -
Hi Jay!
Consistency is the most important thing.
Absolutely - I couldn't agree more. As I said, when I encounter an estimate that's larger than those in the "cluster", I ask how the person arrived at the estimate. If the answer confirms that there is more to the story than people thought, then of course we go with the higher estimate.
However, I sometimes receive answers like, "I don't have experience with the technology" or "I don't really understand the requirement". For the former, it makes sense to go with a lower estimate. If the person who gave the high estimate works on that story, they can pair with someone who does know the technology. For the latter, it's strictly a case where the person didn't ask enough questions in order to gain the understanding required to provide an estimate.
So, in both of these cases, I would recommend going with a lower estimate from the "cluster", but I agree that generally the "highest estimate wins"!
Dave Rooney
Mayford Technologies -
I'm surprised the Delphi technique didn't get a mention for resolving estimate variation. You wouldn't want to use it on every story but it's a nice tool to have in your pocket.
-
Wonderful article. Thanks Jay.
While reading it, the wish to use Fibonacci numbers (a favourite I use a lot) came up. To my delight some others suggest this as well and Planning Poker uses Fib as well. Great! I'll stick to that than.
Regarding prioritizing stories by business: I use "faites vos jeux". Another poker-inspired practice.
Each business stakeholder (those who make decisions and have budget power and/or users) is given ten or twenty poker chips (fiches), say. All chips have the same value. Next, they distibute their chips over the available stories for the next two sprint as they see fit:- Does it feel good (in my heart)?
- Does it make sense (rationally)?
- Does it work (can it be implemented)?
Et voilà, all stories for the next two sprint are prioritized based on their VALUE.
Have the stories picked up by developers until you meet your team's velocity. -
Fred George, one of my favorite people to work with, prefers T-Shirt sizes. The nice thing about T-Shirt sizes is they can't be averaged. I have to give him that. But, the thing I've always disliked about T-Shirt sizes is you don't throw* M, you throw a 2. I prefer to throw 1, 2, 4, or 8 fingers. There's something about having to use 2 hands that makes people really think about an 8. That extra thought usually generates some new approaches to the story -- both technically and from a business perspective. I'm not opposed to the Fibonacci approach, but it does remove my ability to throw anything above a 10. You can use 1-5 (like Vladimir POPOV mentioned in a previous comment), but then I think you are back to thinking in terms of 1-5, and putting a different number on paper. It's not terrible, but I prefer thinking, throwing and tracking on the same scale. It's more natural, and I've had great results with it.
The fact that you are already using fibonacci tells me that you are on the right track, but you might want to try powers of 2 sometime. Or if you perfer to stick with fibonacci, do so exclusively -- if you use your cell phone (like Arnon Rotem-Gal-Oz recommended), you can throw any number you want.
* by throw I mean, show -- in rock, paper, scissors style.
Thanks for the comments, Jay -
We are about to start our second project using Scrum. On the first project, we held full-day planning meetings with the developers (5 developers) and the business owners ( 6 of them) but the discussions were at such high level, that the developers did not find it very useful. We then had to call that a business solution design meeting and arrange a real Sprint Planning meeting to do the estimates but doing the User Stories from scratch in the meeting seems to be too time consuming. If the User Stories are prepared in advance, who should be creating these? Is it the BA & the business owner? When does the developer first get exposure to the user story cards?
Too many questions I know, but I really want to make Scrum work better for us.
Regards
Fred -
Hi Keith -
How do you load the stories into the Planning Poker tool? We use Version One. I tried using the copy/paste method directly into the tool from Excel, but the data is jumbled. Is there some sort of template to map the data into the tool? I can't find any help on the Mountain Goat site.
Thanks,
Rick -
When you estimate how many story points for every story,is there nothing about design?What I mean is not about the detail thing(code framework,what functions...),at least about how many modules will be involved,how many work for each modues? BTW,the background is big complext embeded sysytem.
-
In the post you have mentioned in case of bigger teams estimation can be done by a smaller group rather than entire team getting involved, at the same time article says that everyone who is involved with these stories should be involved in estimation.Moreover as we rotate our pairs regularly isn't it important to have everyone's involvement? Or is it limited at estimation during inception as team can again re-estimate the effort during IPM meetings.
Regards
Rupesh
Thoughtworks,India
17 comments
Watch Thread Reply