Tracking change and innovation in the enterprise software development community
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Free Book Offer
SOA Demystified
$40 Value
Posted by Floyd Marinescu on Jul 07, 2008
One of the great things about working as a consultant is the ability to try out many different ideas and adapting your personal favorite process to include things that work. This article, published on InfoQ last week, gives the details about user story estimation techniques that Jay Fields, has found effective.Agile Development: A Manager's Roadmap for Success
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
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:
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
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
15 comments
Watch Thread Reply