How do I explain Story Point Estimates to newbies
416 views
Skip to first unread message
Andre Nelson
Sep 5, 2008, 2:47:23 PM9/5/08
to versiono...@googlegroups.com
Hey,
I'm having some major trouble explaining how story points are
beneficial, rather than using detailed hourly estimates. Any tidbits to
pass on would be great. I know this may not be the best forum, but it
is in relation to how people are using V1 at our company. Some people
do not want to use Estimate, but instead want to rely on Detail
Estimate. Again, any help coming up with an better explanation is
appreciated. Everything I've tried doesn't seem to make sense to them.
(Note: The people that are having the hardest time understanding are the
programmers.) Thanks in advance!!
I'm having some major trouble explaining how story points are
beneficial, rather than using detailed hourly estimates. Any tidbits to
pass on would be great. I know this may not be the best forum, but it
is in relation to how people are using V1 at our company. Some people
do not want to use Estimate, but instead want to rely on Detail
Estimate. Again, any help coming up with an better explanation is
appreciated. Everything I've tried doesn't seem to make sense to them.
(Note: The people that are having the hardest time understanding are the
programmers.) Thanks in advance!!
- Andre L. N.
Lee Henson
Sep 5, 2008, 6:28:23 PM9/5/08
to versiono...@googlegroups.com
As a Certified Scrum Trainer, I would be happy to answer this question for you and provide a helpful link with even more information to support the use of story points when estimating. Story points are VERY different than detailed hour estimates. One is an estimate of relative complexity, the other is a measure of time.
If I took a group of programmers and placed them in a conference room and told them that for the day I wanted them to be painters. If I proceeded to ask them how long it would take each one of them to paint the room, I may get answers all over the charts. Everything from one hour to multiple days.
If I took the same group of programmers and asked those that had any prior experience painting to compare the complexity of painting this room to the complexity of any other room they may have painted. On a scale of 1-10 with 1 being VERY simple and 10 being EXTREMELY difficult, how complex might it be for any of us to take on the project. The level of complexity efforts will be much closer (everyone will mostly be on the same page making it easier to come to a consensus), than the amount of time estimates.
It is easier for us to agree that the level of complexity is a 3 or 5 than it is for us all to agree it will take 10 hours or 3 hours. Many times the amount of time it takes depends specifically on which resource is doing the task. The relative complexity remains the same regardless of who is doing the work. The advantage of tracking the relative complexity is that over time a team will be able to say during any given iteration the team completes 18 points of work. This number will remain consistent regardless of the time estimates or who takes on which tasks. This is called an established velocity per iteration.
The fact is, anytime we give a detailed estimate, chances are we either forgot to mention something or open the item and go Oh crap, I did not realize this touched XYZ so I have just underestimated. Even worse, many teams say I believe it will take me four hours so to be safe I will pad and say it will take six. This skews the actuals and forces teams to feel like they are accountable for the number of hours of effort they put in instead of the quality of the work they produce at the end of a cycle.
Another way to look at it is trying to measure miles per gallon for a cross country road trip. Depending on the terrain, weather conditions, speed limits, and surface streets vs highways, each tank may be a little different in the number of miles per gallon, but as long as we do not switch vehicles, similar routes on multiple tanks will look and feel the same. Keeping in mind I may be driving a hybrid vehicle and you may be driving a Hummer H1, we may not have the same level of efficiency, but we will still consistently be able to calculate MPG.
Mike Cohn is the World's Best Resource on Agile Estimating and Planning http://www.mountaingoatsoftware.com
I hope this tidbit of information was helpful and I look forward to speaking with you further if need be.
Regards,
V. Lee Henson CST
If I took a group of programmers and placed them in a conference room and told them that for the day I wanted them to be painters. If I proceeded to ask them how long it would take each one of them to paint the room, I may get answers all over the charts. Everything from one hour to multiple days.
If I took the same group of programmers and asked those that had any prior experience painting to compare the complexity of painting this room to the complexity of any other room they may have painted. On a scale of 1-10 with 1 being VERY simple and 10 being EXTREMELY difficult, how complex might it be for any of us to take on the project. The level of complexity efforts will be much closer (everyone will mostly be on the same page making it easier to come to a consensus), than the amount of time estimates.
It is easier for us to agree that the level of complexity is a 3 or 5 than it is for us all to agree it will take 10 hours or 3 hours. Many times the amount of time it takes depends specifically on which resource is doing the task. The relative complexity remains the same regardless of who is doing the work. The advantage of tracking the relative complexity is that over time a team will be able to say during any given iteration the team completes 18 points of work. This number will remain consistent regardless of the time estimates or who takes on which tasks. This is called an established velocity per iteration.
The fact is, anytime we give a detailed estimate, chances are we either forgot to mention something or open the item and go Oh crap, I did not realize this touched XYZ so I have just underestimated. Even worse, many teams say I believe it will take me four hours so to be safe I will pad and say it will take six. This skews the actuals and forces teams to feel like they are accountable for the number of hours of effort they put in instead of the quality of the work they produce at the end of a cycle.
Another way to look at it is trying to measure miles per gallon for a cross country road trip. Depending on the terrain, weather conditions, speed limits, and surface streets vs highways, each tank may be a little different in the number of miles per gallon, but as long as we do not switch vehicles, similar routes on multiple tanks will look and feel the same. Keeping in mind I may be driving a hybrid vehicle and you may be driving a Hummer H1, we may not have the same level of efficiency, but we will still consistently be able to calculate MPG.
Mike Cohn is the World's Best Resource on Agile Estimating and Planning http://www.mountaingoatsoftware.com
I hope this tidbit of information was helpful and I look forward to speaking with you further if need be.
Regards,
V. Lee Henson CST
Emmanuel Szabados
Sep 8, 2008, 10:43:25 AM9/8/08
to versiono...@googlegroups.com
I agree with Lee and would like to add:
- we use story points. I always introduce it in a very very light way with very small definition which trigger the team(s) to define those points themselves: they have a better understanding of how it may work in their own context.
- # of hrs estimation:
Beside this, trying to represent team and individual efforts with # of hrs to Management doesn't make any sens to development team and is an impediment for the Bus/Tech shake hand process. This is also why I am using:
- story point velocities
- # of stories / iteration/team
- # of stories planned and added
- # of stories done done and not done
Plus, my best metrics are the human level of interaction, I call it the noise:
- when Management comes to dailies and we go from story to story to understand where we are
- when everyone are on board for the Strategical planning
Also, like everyday is a different day with a different light..., nothing is fixed - things (teams...) are keep changing all the time and or evolves, or need to be redefined or....
Emmanuel
- we use story points. I always introduce it in a very very light way with very small definition which trigger the team(s) to define those points themselves: they have a better understanding of how it may work in their own context.
- I have trouble sometimes to explain what is Story Points when some people have trouble to understand and ask if it is related to implementation complexity or # of hrs.
- I am not trying too hard to create a Story Point definition for the all Corporate. I generally let each team to define it.
- we use it in the V1 Estimation field because there are reports related to it
- I am not trying too hard to create a Story Point definition for the all Corporate. I generally let each team to define it.
- we use it in the V1 Estimation field because there are reports related to it
- # of hrs estimation:
- is used in planinng2 (tasks) to compare Team Capacity and # of hrs by resources/stories
- is used only for the team and team member to manage their tasks during the iteration.
- is used in V1 at tasks level only to help check where we are....
- is used only for the team and team member to manage their tasks during the iteration.
- is used in V1 at tasks level only to help check where we are....
Beside this, trying to represent team and individual efforts with # of hrs to Management doesn't make any sens to development team and is an impediment for the Bus/Tech shake hand process. This is also why I am using:
- story point velocities
- # of stories / iteration/team
- # of stories planned and added
- # of stories done done and not done
Plus, my best metrics are the human level of interaction, I call it the noise:
- when Management comes to dailies and we go from story to story to understand where we are
- when everyone are on board for the Strategical planning
Also, like everyday is a different day with a different light..., nothing is fixed - things (teams...) are keep changing all the time and or evolves, or need to be redefined or....
Emmanuel
Kevin S.
Sep 8, 2008, 12:28:07 PM9/8/08
to VersionOne-users
Andre-
Lee & Emmanuel gave some great responses, so I'll limit myself to the
programmer focus.
I like the term, "yesterday's weather is the greatest indicator of
today's". This can be used to help management or the team understand
that if they have produced 20 points (or 200 hours) of stuff for the
last 3 sprints, then it is unwise to keep planning 30 points. Wishing
you can go faster won't make it happen.
Lee touched on the velocity point and that is a big part of what story
points are about. By abstracting to a complexity unit of measurement,
human error is reduced. Also, this abstracted unit of measure isn't
as hard to recalibrate as the team matures or adds people (meaning the
product backlog won't need full re-estimation workshops). There is a
lot less arguing over the actual number when it is smaller (product
owners don't care as much about the difference between 19 and 20 story
points, but will care about the difference between 140 and 160 hours
since that "is more than 2 man days!").
So... to help your programmers down this path, ask them if they want
to be held accountable for every hour and every estimate they make?
Or do they want a higher level language that they can negotiate with
the customer and management with? That might be your selling point
for story points.
Another tidbit... think about your story point scale. You don't want
people arguing over 6 vs. 7 story points. Lee's reference of Mike
Cohn will provide insight to that also. (Many people use the 0, 1,
2, 3, 5, 8, 13, 20, 50, 100, ?, infiniti scale)
Good luck!
(Note: I think this is a great forum to ask agile process questions in
since we are all trying to practice agile by supporting it with V1.)
Lee & Emmanuel gave some great responses, so I'll limit myself to the
programmer focus.
I like the term, "yesterday's weather is the greatest indicator of
today's". This can be used to help management or the team understand
that if they have produced 20 points (or 200 hours) of stuff for the
last 3 sprints, then it is unwise to keep planning 30 points. Wishing
you can go faster won't make it happen.
Lee touched on the velocity point and that is a big part of what story
points are about. By abstracting to a complexity unit of measurement,
human error is reduced. Also, this abstracted unit of measure isn't
as hard to recalibrate as the team matures or adds people (meaning the
product backlog won't need full re-estimation workshops). There is a
lot less arguing over the actual number when it is smaller (product
owners don't care as much about the difference between 19 and 20 story
points, but will care about the difference between 140 and 160 hours
since that "is more than 2 man days!").
So... to help your programmers down this path, ask them if they want
to be held accountable for every hour and every estimate they make?
Or do they want a higher level language that they can negotiate with
the customer and management with? That might be your selling point
for story points.
Another tidbit... think about your story point scale. You don't want
people arguing over 6 vs. 7 story points. Lee's reference of Mike
Cohn will provide insight to that also. (Many people use the 0, 1,
2, 3, 5, 8, 13, 20, 50, 100, ?, infiniti scale)
Good luck!
(Note: I think this is a great forum to ask agile process questions in
since we are all trying to practice agile by supporting it with V1.)
Reply all
Reply to author
Forward
0 new messages