Loading ...
Sorry, an error occurred while loading the content.

52801Re: Story point estimating - ideal time vs relative scale

Expand Messages
  • brendabao321
    Oct 8, 2011
    • 0 Attachment
      Hi, Michael.

      I like your summery. I've struggled with story points and real hours too. But after trying both, I realized that the real trouble comes from the usage of the numbers. If some one else outside the team is trying to use this number for micromanagement, it would be a trouble in either ways. But if the number is just viewed as some facts based on which team can improve themselves, it would work in both ways.

      So, as a Scrum Master at that time, I tried to make the story points difficult to understand outside the team. For example, make a very complex explanation when someone try to map points to hours. And show them the release burndown instead, which is much simpler to understand. Some things I've done may not seem decent, but only in this way can the team be honest about the estimation.

      --- In scrumdevelopment@yahoogroups.com, Michael Jones <michaelhardwinjones@...> wrote:
      >
      > Hi all,
      >
      > Now this is getting interesting - the consensus I think until Reinert and
      > Joe's posts was that (summed up by Mark) "Fundamentally, it doesn't matter
      > what unit of measurement you use to estimate a PBI, as long as you apply it
      > consistently."
      >
      > I completely agree with that.
      >
      > I understand where relative scale story points (instead of ideal hours story
      > points) might have value on a psychological level, because they obfuscate
      > the fact that we're actually talking about time, allowing developers to
      > relax and give estimates free from the feeling that they're going to be tied
      > to some time measure. (even though they wouldn't be if we were using ideal
      > hours, because everyone should know ideal hours != real hours).
      >
      > My problem comes when people try to make claims for relative scale story
      > points that are bigger than that, because as you admit Joe an RSSP always
      > resolves to time - e.g. "this team can do about 20 story points per 2-week
      > sprint"; so if there are 120 person hours in the sprint, each story point is
      > 6 hours.
      >
      > When someone imagines the effort involved in building a registration form,
      > for example, they're doing it in terms of time (or if there's any other
      > variable, we're probably not interested in it). Whatever scale they decide
      > for 1 point resolves to some measure of time.
      >
      > So it's essentially the same thing, but with RSSP you're just not admitting
      > the underlying "exchange rate", which is there nonetheless. So there's no
      > advantage of RSSP except for that psychological mechanism (which only
      > prevails for those developers who don't get around to making the conversion
      > in their own heads).
      >
      > All the advantages and disadvantages of RSSP are the same with ideal hours -
      > e.g.:
      > - "people won't agree what an ideal hour really means" - people also won't
      > agree on "how long it takes to build x"
      > - from the rapidscrum slideshow: While Accuracy with Precision is desirable,
      > Accuracy is the more valuable of the two. - Ideal time story points can be
      > just as imprecise and accurate (especially if used on an exponential scale
      > for estimating the product backlog)
      >
      > I realise this is all a bit philosophical. I'm happy to try RSSPs out on the
      > basis that hiding the fact we're really talking in the end about ideal time,
      > is helpful for people's frame of mind when estimating, and perhaps when
      > working too ... I just don't like it when claims are made for them, that are
      > just as apt for ideal time, and when the fact that they're really the same
      > thing (except perhaps on that psychological level) isn't acknowledged.
      >
      > Cheers and have a great weekend... :)
      > Michael
      >
      > Footnotes:
      > Mike Cohn on ideal time story points:
      >
      > My preference is to treat a story point as an ideal day of work. We rarely
      > have these ideal days, but thinking
      > about stories in ideal time offers two advantages. First, it is easier than
      > estimating in elapsed time. Estimating
      > in elapsed time forces us to consider all other possible impacts on our
      > time, such as the all-company meeting
      > on Tuesday, my dentist appointment on Wednesday, a few hours a day for
      > answering email, and so on.
      > Second, estimating story points in ideal time gives our estimates a slightly
      > better foundation than when they
      > are estimated in entirely nebulous units.
      >
      > Henryk Kniberg:
      > We use man-days as a basis for all time estimates (although we
      > call it story points). Our lowest value is 0.5, i.e. any task that is
      > smaller
      > than 0.5 is either removed, combined with some other task, or just left
      > with a 0.5 estimate (no great harm in overestimating slightly). Nice and
      > simple.
      >
      >
      > On Fri, Oct 7, 2011 at 4:50 PM, Joe <jhlittle@...> wrote:
      >
      > > **
      > >
      > >
      > > Hi Michael,
      > >
      > > I would DEFINITELY do story points.
      > >
      > > Ideal hours do not actually communicate effort well (people won't agree
      > > what an ideal hour really means).
      > > People are terrible at estimating time. Relative size/complexity gets
      > > estimated much better, and is much less likely to be skewed (usually under
      > > or over estimated).
      > > Story points comes back to time as soon as you declare "this team can do
      > > about 20 story points per 2-week sprint".
      > > Only the output of the team is meaningful...THAT's what we need to know,
      > > and then we need to know how to fill (but not over-fill) that capacity of
      > > the team, each sprint.
      > > QED: Story points. (Well, the short version of the case.)
      > >
      > > Don't ask them to agree to do story points. They have no experience, their
      > > answer is not meaningful...at least until they have experience. Say, "we're
      > > gonna do this new well-established technique." And give it at least 4
      > > sprints. You can tell them it's an experiment and if is terrible after 4
      > > sprints, we'll change it. (It won't be if anyone is professional around
      > > there.)
      > >
      > > You might need a good coach to have the authority and the detailed
      > > experience to make it work better from Day 1. Seems expensive, but it is not
      > > compared to the alternative.
      > >
      > > Regards,
      > > Joe
      > >
      > > LeanAgileTraining.com
      > >
      > >
      > > --- In scrumdevelopment@yahoogroups.com, "Reinert" <rekahm@> wrote:
      > > >
      > > >
      > > >
      > > > Hi,
      > > >
      > > > There are a lot of advantages if you go for using only story points in
      > > your estimation of user stories. I.e. abondoning hours / time totally in all
      > > your estimates including (developer) tasks. If you are interested in more
      > > information, please check out www.rapidscrum.com. The link "AgileIndy
      > > Presentation: Hours are Dead" under "RESOURCES" gives you some more
      > > information. I've used many of the techniques he is describing and though
      > > they are quite unfamiliar, they are very powerful.
      > > >
      > > > Reinert
      > > >
      > > > --- In scrumdevelopment@yahoogroups.com, Michael Jones
      > > <michaelhardwinjones@> wrote:
      > > > >
      > > > > Hi,
      > > > >
      > > > > We're rolling out an agile process in my company, where waterfall
      > > processes
      > > > > have been used up to now.
      > > > >
      > > > > I've been involved in a couple of discussions/debates with various folk
      > > here
      > > > > (a product manager and a fellow PM) about the units developers should
      > > use to
      > > > > estimate user stories in the sprint planning meeting. Specifically
      > > whether
      > > > > to use ideal time (e.g. "1 ideal hour"), or relative scale (e.g. "about
      > > the
      > > > > same as that registration form we did").
      > > > >
      > > > > I have my own views, but what are your thoughts? Are there any
      > > stand-out
      > > > > benefits of either in your experience? Should we throw it as an open
      > > > > question to our developers?
      > > > >
      > > > > Thanks,
      > > > > Michael
      > > > >
      > > >
      > >
      > >
      > >
      >
    • Show all 25 messages in this topic