Intro
Last week I established three good reasons to go with Story Points and why they're so popular. This week I want to talk about one more important aspect of story points and then provide tips on how to get started estimating in Story Points. I find this is a rather big challenge for teams just learning the ropes.
Lets talk
Scrum is a learning framework. It's been designed specifically with Inspect and Adapt points with a very specific purpose. Because estimating is a cross-functional team activity estimating the backlog is just another opportunity for the team to get together to discuss the task at hand, for the stakeholder or product owner to explain what is expected of the team. This discussion is a great way to build team morale, synchronize expectations and getting everyone singing to the same tune. Because Scrum projects are agile, it’s important that teams engage in discussion to ensure the team stays on the right track. And because the estimation is done in a team setting the estimate is generally more accurate as it represents a cross functional view of the task size, not just the developer view.
Difficulty
A couple weeks ago, I was helping a company understand how to estimate the backlog. This company is new to agile and I was introducing them to Planning Poker and Story Points. Firstly the idea of Planning Poker was some sort of a joke to them. Second getting them to understand Story Points, a seemingly meaningless measurement, seemed to be a non-starter for them.
Ideal hours first
This is where ideal hours came to the rescue. They were far more able to wrap their heads around ideal hours i.e. if you lock the developers and testers in a room with zero interruptions, how long would it take. I figured that once they got their initial stories estimated in ideal hours down, switching to Story points will be easy as they would have established a scale of reference to compare against. This approach worked really well. They're now into their 3rd Sprint and now that they have an existing scale, whether the number is in ideal hours or story points or dog points for that matter, it really doesn't matter any more. If you're new to agile estimating, and you're having trouble coming to terms with Story Points try this first and then make the switch later.
The real epiphany
Planning poker for them was a real epiphany. What started out as a joke soon turned out to be a really, really rich experience. For the first time in the companies history, there was actual dialog. The biggest benefit came from the discussion that ensued after the first round of cards were played. The two outliers (i.e. the folks that estimated low and high) were asked to explain why the big difference. The dialog and information exchange at that point was extremely valuable. I watched their faces after the first user story was done. It took only 5 minutes. And everyone was in sync. I saw the light bulbs go on in their heads. They have never looked back since.
Planning poker has to be the simplest most effective ceremony ever invented. I highly recommend it. There are also variations of planning poker, check out
James Grenning's blog for more details
Bookmark/Search this post with:
About the Author: As COO and Scrum Master, Jack Milunsky heads software development at Brightspark. Jack is an early adopter of Scrum and has a great passion for early stage startups. Jack is co-creator of Agilebuddy, a next generation Scrum Application SaaS. Jack combines over 18 years of experience managing software development teams both large and small. You can follow Jack for great tips on Agile at http://twitter.com/agilebuddy
Comments
Matches my experiences
March 27, 2009 by Ola Ellnestam (not verified), 2 years 45 weeks ago
Comment id: 2416
Hi,
Your observations matches my experiences.
The real benefit of planning poker are the discussions that arise around how stories are to be implemented. These discussions aren't half as productive or might not even pop up when everyone is defending an estimate in absolute numbers. I.e time.
Danger of getting too detailed
March 27, 2009 by Ted Young (not verified), 2 years 45 weeks ago
Comment id: 2417
One thing my team's been dealing with lately is getting too detailed in the discussion, when it's not necessary to give a reasonable estimate. Other issues we've had are where we can't bring the estimates to a consensus, e.g., half the people say 3 points and the other half say 5 points and neither one thinks the other estimate is correct.
Too detailed
March 27, 2009 by jackMilunsky, 2 years 45 weeks ago
Comment id: 2418
Hi Ted,
Thanks for your comments. I highly recommend a timer with an alarm. You set it for 2 mins a round. If you like you can make it a bit longer. And try to only have 2 maximum 3 rounds.
If you don't reach consensus, don't worry about it. Take the higher number. That perfectly alright. In the end the truth will surface i.e. how long it actually took. But the difference between a 3 and 5 pointer is not that significant in actual fact.
The important thing is that you understand what is required and you have a reasonable estimate of how long it's going to take.
I find, always take the practical approach
Jack
3 vs 5
March 28, 2009 by Janusz Gorycki, 2 years 45 weeks ago
Comment id: 2419
Ted,
The diference between 3 and 5 story points is insignificant. Pick either 3 or 5. Or 4 (yes, you are allowed to do that - it is YOUR project). If you picked 3, then next story that gets you in this sort of discussion - you pick 5 - so that you are statistically right.
Remember - this is statistical measurement, and you do not have to be 100% precise - you will be off with your estimations anyway, no matter how hard you try to be exact.
You WOULD be in trouble if half of the team said 1 and the other half said 13 - and nobody would be willing to budge. This means there is something wrong - most likely with the story definition.
Cheers
Janusz
some clarification please
April 9, 2009 by laszloS (not verified), 2 years 43 weeks ago
Comment id: 2452
Hi Jack,
In reading through this post, I have some concern. Can you clarify these points:
(a) Product Owner involvement in size estimation
"And because the estimation is done in a team setting the estimate is generally more accurate as it represents a cross functional view of the task size, not just the developer view."
Are you advocating that the Product Owner also do size estimations with the team? If not, what do you mean by, "not just the developer view"?
(b) Ideal Hours
Jack, I really hope you're joking here about Ideal hours. The idea in Scrum is to have two different scales of estimation - one PBI level and another @ the task level. Using the concept of 'ideal hours' can really confuse newbies and encourage them and lead them towards micro measurement.
For more on this topic, I would encourage your readers to jump over and read this article on estimation by Certified Scrum Trainer and Certified Scrum Coach Kane Mar instead: http://danube.com/system/files/Story+Points+as+Spiciness+blog.pdf
Supplemental readings on macro vs. micro measurement by Certified Scrum Trainer Michael James can be found here: http://danube.com/whitepaper/macro-measurements
Some clarifications
April 11, 2009 by jackMilunsky, 2 years 43 weeks ago
Comment id: 2453
It's always good to have the PO present if possible for elaboration purposes. i.e. if the team requires clarification in scope etc. The PO does not actullly participate in the estimation. By crossfunctional I mean, dev, test, tech writing, dba's etc i.e. any functional group that will be part of the development process
I am not joking at all. There are many teams that wrestle with getting to grips with story points. Ideal hours although not ideal is an option that one can consider. I have used it very successfully to transition teams. Mike Cohn discusses this in his book Agile Estimating and Planning as a viable option.
Thanks for your feedback
Jack
I don't profess to know
August 20, 2009 by Anonymous (not verified), 2 years 24 weeks ago
Comment id: 2991
I don't profess to know everything there is to know about scrum or product owners.
But aren't they supposed to be completely tactical? Of course, they need insight in to the business, and they need to put themselves in the customers shoes. But are they doing customer visits, gathering market research, constructing segmentation strategies, pricing models, responsible for P&Ls, positioning the product, writing requirements, etc...?
If not, the role should not be confused with a product manager.
My understanding, admittedly limited and not as extensive as Jack's, is that a PO represents the product manager and their priorities in an agile scenario - but they do not replace the PM.
My decoration blog
Post new comment