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

Re: [XP] Re: More Challenges - estimating, points, and Yesterday's Weather

Expand Messages
  • Lasse Koskela
    ... Just to nitpick a little, the conversion for a team of two is probably not much different from individual conversions. How big a team would it require for
    Message 1 of 8 , Sep 30, 2004
    • 0 Attachment
      On Thu, 30 Sep 2004 23:13:48 -0000, jhrothjr <yahoogroups@...> wrote:
      > Never try to convert points to time except on
      > a whole team basis.

      Just to nitpick a little, the conversion for a team of two is probably
      not much different from individual conversions. How big a team would
      it require for the "team point conversion" to produce usable
      approximations? I doubt we'll ever have a "correct" answer for that
      one...

      -Lasse-
    • jrb32002
      ... wrong & they ... were wrong. ... numbers ... So, in this case, fantasy/politics trumped reality, as often happens in software development projects.
      Message 2 of 8 , Oct 1, 2004
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, "Paul Jenkins"
        <pauljenkins714@m...> wrote:
        > Yes: exactly our point. Their gut 'told them' the estimate was
        wrong & they
        > had enough of a reputation to convince the PM that the estimates
        were wrong.
        > We had the numbers & we knew different. No one believed what the
        numbers
        > said, until we removed their influence and 'only' had the numbers.

        So, in this case, fantasy/politics trumped reality, as often happens
        in software development projects. Especially those where "estimates"
        are treated as commitments, and developers as interchangeable .... :-b


        > >You need to estimate in points, not days.
        >
        > but what does a point represent? how do I know when I've completed
        one ? I
        > know when I've written code for an hour; how many points is that?

        Dunno, I've not met your team, and they've not yet come to a decent
        agreement on what size stories they'll take. You'll know when you've
        completed one when the Customer accepts that one-point story you've
        been working on; if it were a two-point or 42-point story that got
        accepted, you'd have completed two or 42 respectively. The past
        hour's code gets you an hour closer to earning point(s) from the
        Customer accepting the story it satisfies.

        Honestly, I'm not sure what the problem is here. (Are you asking
        rhetorically, or in earnest, or reflecting others' expected
        questions?) A point is a point, an arbitrary (*not* random) rough
        measure of how much work your team can get done during a fixed-length
        iteration.

        The measure itself comes from the team agreeing: this story is 1
        point; this one's about three times as hard, so 3 points; this one
        would be a 2; these two together about 1; this would be a 4 so let's
        get it split; and this last one's, well, none of us want to generate
        a random number, so Fred's going to go off and explore for an hour to
        learn what we need to rate it.

        It's rough because it doesn't need to be precise, smooth, or
        polished -- in fact, any effort to make it not-rough doesn't improve
        accuracy and is normally better put to actually understanding and
        implementing the functionality. If velocity has stabilized at
        roughly 10 points per week for a three-developer team, then the team
        would expect to complete a single card rated "2 points" in a day.

        Joseph Beckenbach
        agilist
      Your message has been successfully submitted and would be delivered to recipients shortly.