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

Re: [XP] Re: Points are like money?

Expand Messages
  • Chris Wheeler
    ... Having used both time and points, I am a bit biased towards the former. Judging story size relative other stories, for the scope of a project of any
    Message 1 of 68 , Jan 11, 2006
    • 0 Attachment
      >
      > I have observed that when estimating in time-like units, people tend not
      > to compare stories to each other to estimate, but rather think in terms
      > of perceived personal velocity, which is much more open to fluctuation.
      > This is the nature of estimating in a time unit: we tend to compare to
      > the clock, rather than to other stories of similar size.



      Having used both time and points, I am a bit biased towards the former.
      Judging story size relative other stories, for the scope of a project of any
      length, gets tricky. Moving to hours, the team tends to negotiate simpler
      solutions because cost vs. business value is much more apparent - there are
      only so many hours in a week to work, and there is only so much time a
      customer will want to spend on a feature.

      Here's an example, based on a real conversation:

      Customer: We saw that users were not sure if the algorithm was taking a long
      time or if the system was hanging, so we need a progress bar to tell us
      what's going on.

      Programmer: We can do a progress bar, what should we measure?

      Customer - Let's measure each step of the algorithm, and provide a
      percentage complete and a countdown timer display on the bar itself.

      Programmer - Ok, we can measure stage C of the algorithm fairly easily, but
      stage A is pretty fast, and stage B is really tough because we'll need to
      refactor the code to add a bunch of notifications.

      Customer - How much?

      Programmer - Well, to put the bar on the UI, about an hour, and then to
      measure stage C, let's say about 6.5 hours. But to do B, we'll need a day
      to refactor, because it's going to affect the existing performance stories,
      and then another day to do blah blah blah....

      Customer - Well, we need a progress bar, but this story is getting costly,
      what can we do to get it done in less time... what if we....

      Programmer - Ya, that would be much simpler. Then A and B would only cost
      about an hour. We could wrap the whole story up in a day or so.

      Now, I'm not saying that the fact that we use hours to estimate is the only
      thing that plays a role here. My opinion is that the whole team has gotten
      good at:

      a) breaking stories into tiny chunks of incremental business value
      b) discovering what they really want and negotiating towards a simple
      solution (buying a Ford instead of Mercedes)
      c) knowing when a story is done (and not tweaking without real feedback)

      Hours, I believe, helped to get us here, more than points did, because the
      association between time and cost is much stronger than the association
      between points and cost. Ultimately, I think the three points above are
      more important to success than the unit of measure.

      They pretended to be estimating by comparing stories for similar
      > size, but instead they were estimating by perceived personal velocity.
      > Ca marche pas.



      When I estimate, and when other programmers I work with estimate, we take a
      lot of factors into consideration very quickly. Comparing stories is one of
      those things, but not the only thing. We also take our confidence, mood,
      knowledge of the feature, weather, who's bringing snacks, distractions,
      etc... All of that rolls into the estimate, not just comparison of similar
      stories. We also go very fast through our estimates. Start to finish, we
      can, as a team, present a weeks' worth of stories, and provide estimates in
      around 45 minutes. But I guess that's another story :)


      Chris.

      --
      Chris Wheeler
      www.agilelectric.com
      coach, programmer & practitioner


      [Non-text portions of this message have been removed]
    • Chris Wheeler
      ... Having used both time and points, I am a bit biased towards the former. Judging story size relative other stories, for the scope of a project of any
      Message 68 of 68 , Jan 11, 2006
      • 0 Attachment
        >
        > I have observed that when estimating in time-like units, people tend not
        > to compare stories to each other to estimate, but rather think in terms
        > of perceived personal velocity, which is much more open to fluctuation.
        > This is the nature of estimating in a time unit: we tend to compare to
        > the clock, rather than to other stories of similar size.



        Having used both time and points, I am a bit biased towards the former.
        Judging story size relative other stories, for the scope of a project of any
        length, gets tricky. Moving to hours, the team tends to negotiate simpler
        solutions because cost vs. business value is much more apparent - there are
        only so many hours in a week to work, and there is only so much time a
        customer will want to spend on a feature.

        Here's an example, based on a real conversation:

        Customer: We saw that users were not sure if the algorithm was taking a long
        time or if the system was hanging, so we need a progress bar to tell us
        what's going on.

        Programmer: We can do a progress bar, what should we measure?

        Customer - Let's measure each step of the algorithm, and provide a
        percentage complete and a countdown timer display on the bar itself.

        Programmer - Ok, we can measure stage C of the algorithm fairly easily, but
        stage A is pretty fast, and stage B is really tough because we'll need to
        refactor the code to add a bunch of notifications.

        Customer - How much?

        Programmer - Well, to put the bar on the UI, about an hour, and then to
        measure stage C, let's say about 6.5 hours. But to do B, we'll need a day
        to refactor, because it's going to affect the existing performance stories,
        and then another day to do blah blah blah....

        Customer - Well, we need a progress bar, but this story is getting costly,
        what can we do to get it done in less time... what if we....

        Programmer - Ya, that would be much simpler. Then A and B would only cost
        about an hour. We could wrap the whole story up in a day or so.

        Now, I'm not saying that the fact that we use hours to estimate is the only
        thing that plays a role here. My opinion is that the whole team has gotten
        good at:

        a) breaking stories into tiny chunks of incremental business value
        b) discovering what they really want and negotiating towards a simple
        solution (buying a Ford instead of Mercedes)
        c) knowing when a story is done (and not tweaking without real feedback)

        Hours, I believe, helped to get us here, more than points did, because the
        association between time and cost is much stronger than the association
        between points and cost. Ultimately, I think the three points above are
        more important to success than the unit of measure.

        They pretended to be estimating by comparing stories for similar
        > size, but instead they were estimating by perceived personal velocity.
        > Ca marche pas.



        When I estimate, and when other programmers I work with estimate, we take a
        lot of factors into consideration very quickly. Comparing stories is one of
        those things, but not the only thing. We also take our confidence, mood,
        knowledge of the feature, weather, who's bringing snacks, distractions,
        etc... All of that rolls into the estimate, not just comparison of similar
        stories. We also go very fast through our estimates. Start to finish, we
        can, as a team, present a weeks' worth of stories, and provide estimates in
        around 45 minutes. But I guess that's another story :)


        Chris.

        --
        Chris Wheeler
        www.agilelectric.com
        coach, programmer & practitioner


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.