Re: [Scrum] Story Point Estimating vs Hourly Estimating

[RonJeffries]

Hi Chris,

On Aug 11, 2012, at 3:26 AM, Chris Gratigny <chr...@ibethel.org> wrote:

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? 

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?

Ron Jeffries

www.XProgramming.com

I have two cats, and a big house full of cat stuff. The cats fight and divide up the house, messing up their own lives. Nice work cats. Meow.

[Dan Rawsthorne]

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.

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

On 8/11/2012 12:26 AM, Chris Gratigny wrote:

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? 

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/1UWaXQ27vGAJ.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[Kurt Häusler]

Hi,

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.

Cheers,

Kurt

[Chris Gratigny]

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.

[RonJeffries]

On Aug 11, 2012, at 7:47 PM, Chris Gratigny <chr...@ibethel.org> wrote:

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.

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.

2. having started scrum we are trying to do it by the book, or as close to the training as possible.  

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.

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.

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?

Ron Jeffries

www.XProgramming.com

Everything that needs to be said has already been said.

But since no one was listening, everything must be said again. -- Andre Gide

[John Miller]

Ron,

Can you elaborate more on :

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.

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

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.

[RonJeffries]

On Aug 11, 2012, at 8:43 PM, John Miller <agiles...@gmail.com> wrote:

Can you elaborate more on :

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.

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?

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".

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. 

Why do you want to do these estimates for things you are not doing?

Ron Jeffrieswww.XProgramming.com

I try to Zen through it and keep my voice very mellow and low.

Inside I am screaming and have a machine gun.

Yin and Yang I figure.

  -- Tom Jeffries

[John Miller]

Why do you want to do these estimates for things you are not doing?

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

[RonJeffries]

On Aug 11, 2012, at 9:06 PM, John Miller <agiles...@gmail.com> wrote:

Why do you want to do these estimates for things you are not doing?

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 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 ...

• How does that purpose require that everyone estimate everything the same, since clearly everyone can't DO everything the same?
• What does the fact that everyone can't do everything the same tell you about the value of the estimates?
• What estimate is more likely to match what really happens, that of the expert who will presumably not do most the work, or of the non-experts, who will do most of the work?
• What evidence have you that the estimates by either the expert or the beginners are any good at all? How much data have you collected on how well the individual estimates match reality? If they do not match reality, or you do not have the data, why are you so anxious to get the estimates?
• Have you used estimates on projects before? Did these projects come in on time, on budget, with all the planned functionality working with very few defects?
• Why are your people resisting estimation? Really.
• Does this project already have a budget? Does it already have a deadline? If so, what's your purpose for Release Planning again?

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.

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?"

Ron Jeffries

www.XProgramming.com

I'm not bad, I'm just drawn that way.  -- Jessica Rabbit

[John Miller]

Ron,

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. 

Thank You,

John 

Sent from my iPhone. It likes to sabotage my grammar. 

[RonJeffries]

On Aug 11, 2012, at 10:33 PM, John Miller <agiles...@gmail.com> wrote:

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. 

I need to understand your position and experience before I can give useful advice.

Ron Jeffries

www.XProgramming.com

Impossible is not a fact. It is an opinion.  -- Muhammad Ali

[Chris Gratigny]

Thanks Dan, that's super helpful. I like the idea of t-shirt sizes.