|Story Point Estimating vs Hourly Estimating||Chris Gratigny||8/11/12 12:26 AM|
My team has just recently started SCRUM in the beginning if July of this year after I (Product Owner) and my ScrumMaster attended Mike Cohn's training on our respective roles.
One thing we've ran into is that we used to do hourly estimates for the team, but now I'm shifting our estimates to points... and the team is having a difficult time understanding the points. They understand hours better and in the Sprint Planning meeting break down their work and estimate hours. I want to stick with story points (that don't equal hours) because my lead developer is going to give much smaller estimates on hours than my brand new junior developer.
How can I explain the value of estimating using story points to the team? They've been stuck on the idea of "difficulty" being what they are estimating, but difficulty does not equal time. I've tried to explain a few times that we are estimating the size of one story compared to the size of another story, but they just want to estimate in hours.
It's a lose-lose right now because sticking with points means they throw out random numbers, and going back to hours they will never agree because of the experience level dynamic.
I'd love input on how you might have explained this, or have you gone back to hourly estimates for stories?
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Ron Jeffries||8/11/12 3:58 AM|
I have nothing but questions, at least so far.
1. Why are you estimating at all? What are these estimates good for? Who is paying attention to them, and what are they doing with them?
2. What is your role in Scrum that allows you to unilaterally shift these estimates (what are they good for?) from hours to points? I am not aware of a Scrum role that has that authority.
3. If there is some need for estimates (see #1), why not have the team figure out how to produce estimates that meet that need?
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Dan Rawsthorne||8/11/12 7:21 AM|
Why do you want the Team to estimate in Points? It looks like you are looking for some sort of "Ideal Effort" estimate, is that right? If that's so, then use T-shirt sizing and assign points to the sizes, like Small = 2, Medium = 4. Large = 8. In any case, do the sizing with an Estimation Game, by comparing the Story to be sized (call it StoryABC) to some exemplars representing the canonical Small, Medium, and Large stories. Use a question like "Which of thise exemplars is StoryABC most like, with respect to Ideal Effort, assuming the code is perfect, your team is perfect, your Organization is treating you right, SMEs are available, and so on?" By leaving the Environmental Variables (Team Ability, Technical Debt, Organizational Noise, etc) out of the equation, your Velocity will act the way you want, going down when you increase Technical Debt, going up if the Team gets better, and so on. I have a discussion of this in chapter 3.7 - go take a look.
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Kurt Häusler||8/11/12 8:17 AM|
check out "affinity estimation".
Basically place the story cards on a table or a wall according to their size. e.g. Left is small, right is large or the other way around. Group similar sized ones together.
Once they are on the wall, then apply story point column headings (e.g. Fibonacci numbers) above the cards. Draw virtual lines between the columns, and whatever column a card ends up in is its story point value.
It might be necessary to remind people that a 2 is twice as big as a large, and a 5 is five times as big as a 1 etc, and then go over them again to see if everything is in the right column. But it should be a good enough start. After doing affinity estimation a couple of times the team should develop an idea about what a 1 is, and what a 5 is etc, and you can switch to planning poker if you like.
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Chris Gratigny||8/11/12 4:47 PM|
1. We need estimates for release planning. So I know how much the team can do in a week for the sprint planning meeting as well as in six months what might be done.
2. having started scrum we are trying to do it by the book, or as close to the training as possible.
3. our team wouldn't estimate of given a choice so it is hard to leave it up to them. It just wouldn't happen if I didn't push for it.
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Ron Jeffries||8/11/12 5:17 PM|
As for what is to be done in a Sprint, in Scrum the TEAM decides how much to take on. It sounds like you are deciding. If so, I'd strongly advise against that.
As for how much is done over the longer term, in Scrum the point is WHAT is done, not how much. A focus on how much is often unhealthy, because what is supposed to happen is that the Product Owner chooses things by value, the team delivers them in a single Sprint, ready to ship.
Release planning is not a core element of Scrum.
It doesn't sound to me as if you are doing Scrum by the book and I hope you're not doing it according to official Scrum Alliance training. Estimates are not a core element of Scrum. Forecasting how much can be done in the current Sprint and committing to doing it under all reasonable circumstances is part of Scrum.
Product burn down used to be a core element but isn't any more. To do it you need very gross estimates on the backlog items. If you do a little work to get them about the same size, counting them works just fine.
I think your team is probably right. I'm not sure why they don't want to estimate but I know why most teams who don't want to estimate resist it. They believe -- quite rightly -- that someone is going to try to hold them to their estimates despite the fact that the estimates were made at the moment when the absolute least was known about what needs to be done.
Have you thought about getting some coaching?
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||John Miller - Agile Schools||8/11/12 5:43 PM|
Can you elaborate more on :
How do you do this practically without spending too much time breaking each item down to about the same size . Isn't the benefit espoused in Scrum trainings and many books that the the items should be appropriately sized; big and vague on the bottom, small and granular at the top? Is it waste to get them all the same size, especially if those items are removed?
This is where I have struggled in Commitment Driven Planning. I get how it works just before or during the Sprint planning, but, before that, I still can not get around performing relative estimates on backlog items that are not probable to deliver in the next 2 Sprints or later.
Sent from my iPad
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Ron Jeffries||8/11/12 5:54 PM|
You could break them down to "about four weeks" and burn down would work. I believe that most estimation is waste and that it is more common to use estimation as a replacement for proper steering, and to use it as a whip on the developers, than it is to use it for its only valid purpose in Release Planning, which is more like "decide whether to do this project" than "decide just how long this thing we just thought of is going to take, according to people who don't as yet understand it or know how they'll do it".
Why do you want to do these estimates for things you are not doing?
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||John Miller - Agile Schools||8/11/12 6:06 PM|
Ron, my desire is not to have estimates, but, to not to have wasteful planning.
Relative estimates have been the only method I have found that helps with this.
Perhaps the root of the problem is my assumptions of the purpose of Release Planning.
I hate to keep you on the subject, but could you kindly point me to an article describing what this approach to Release Planning looks like, all the way through to Committment Driven Planning by the team. Or, if you are inclinded, describe it for us.
Sent from my iPad
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Ron Jeffries||8/11/12 7:19 PM|
I think I have not learned, or have forgotten, what your role on this team is. What is it?
What is the purpose of Release Planning for you? And then ...
I'll try to say something about Release Planning after I find out what you think it is, and what you think it is for. Until then, it seems likely that my answer will continue to miss your ears.
Commitment Driven Planning //does not use estimates//. It is used to plan a Sprint by adding stories until the team says "enough". It is explicitly not about estimates, not about points, not about velocity. I can't think of any good way to mesh the notion of Release Planning via estimates with Commitment Driven Planning. There seems to be no point of connection.
It appears to me that your question for Release Planning is something like "how long will it take to get all this stuff done". That is not the Scrum question. The Scrum questions are "What shall we have in shippable condition at the end of the next Sprint?" and "How can I, the Product Owner, choose Product Backlog Items so as to have the best possible product by the date?"
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||John Miller - Agile Schools||8/11/12 7:33 PM|
I think there is some miscommunication here.
I am seeking understanding to learn the method you espoused , which seems to me a great option, and maybe even a better option than what I have done in the past.
If you do not wish to elaborate on how it is done and share more on your views on the purpose of release planning, I respect that and will not ask again. My questions were merely to learn from a master with a beginner's mind.
Many of the questions you ask of me seem to be bundled with implied assumptions behind them that seems to be about my desire or attachment to estimates. That is not the case, as, I find estimating a dirty and flawed business. Relative estimates have been the only workaround I have discovered until your post on this thread.
Sent from my iPhone. It likes to sabotage my grammar.
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Ron Jeffries||8/12/12 3:13 AM|
I need to understand your position and experience before I can give useful advice.
|Re: [Scrum] Story Point Estimating vs Hourly Estimating||Chris Gratigny||8/12/12 4:21 PM|
Thanks Dan, that's super helpful. I like the idea of t-shirt sizes.