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

Re: [XP] sizing stories

Expand Messages
  • Omar Bernardi
    so, let me see if I ve learnt the lesson: Stories should be sized by the entire team, trying to reach to an agreement about how big/difficult is it. The
    Message 1 of 7 , Dec 28, 2002
    • 0 Attachment
      so, let me see if I've learnt the lesson:

      Stories should be sized by the entire team, trying to reach to an agreement
      about how big/difficult is it.
      The customer only choose which stories are being to be included in this
      iteration.
      All the stories that fits within this iteration are given to the programmers
      so they can sign for those they feel more comfortable/attracted to develop.
      All of them must use the same "units".
      The unclaimed stories must be developed by someone, so somebody should sign
      for that unpleasant stories.
      The programmer who sign for the story also makes his own estimation.
      and it could be different from the originally estimated by the team.
      The programmer estimation overcomes the team estimation.
      He must take into account that he will spend some time helping/pairing other
      developers,
      so his productivity should decrease.
      That's one of the reason to use ideal days as units, because they take into
      account this kind of situations.
      The programmer is responsible for the completion of that story,
      and the effort resulting of that development owns only to himself,
      no matter who and how many developers had paired with him to help doing it.
      He should use that estimation/results for better estimate future stories by
      himself,
      and to give better estimations when the team meets to size new stories.
      Personal velocity (units finished in the iteration) developed by each
      programmer builds up the team's velocity for the next iteration.

      pretty easy, doesn't it?

      Thank you mates.
      Omar.


      ----- Original Message -----
      From: "vidmas_k" <vidmas_k@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Wednesday, August 27, 2003 11:53 PM
      Subject: Re: [XP] sizing stories


      > In our practice of XP, during iteration meetings individuals take
      > cards (stories) that can be completed within the iteration (two weeks
      > for us). The cards are given a rating 1, 2, or 3. One being easy, two
      > being moderate, and three being hard. The person that takes the card
      > makes the difficulty assesment and pairs with someone, but not for
      > more than a couple of days. Only the person responsible for the card
      > should estimate. We have had too many customer/developers make the
      > decision (meaning a developer that is actually a manager or
      > customer). We switch between pairing on "our" cards and other peoples
      > cards throughout the iteration. That is one reason we dispensed with
      > letting management know about personal velocity. Personal velocity
      > creates an environment where developers feel they only need to work
      > on cards that they get points for. (If an individual takes this as an
      > opportunity to slack off, the best policy is to have the team kick
      > his or her ass rather then go through the cowardly management layer).
      > If at the end of the iteration, the developer still hasn't finished
      > his or her card (this reminds me of a dialog between the PFJ in Monty
      > Pythons "Life of Brian"), HE OR SHE IS NOT ALLOWED TO TAKE THE SAME
      > CARD! Code ownership on a team project is the source of all evil. To
      > answer your question, on our project the story estimation is done by
      > the developer taking the card. If two different pairs have a
      > different estimation, it is irrelavent. When another person takes the
      > card, they can make their own estimation. If the estimation is
      > greater than a 3 or if it takes more than one iteration, we break out
      > the story into more cards (sub stories). (Notice the way I employ the
      > word card and story interchangeably. Not that I want to create a
      > debate between the semantics between card and story but, if enough
      > people utilized this lingo because it was zeitgeist, then I guess it
      > would be like referring to test passing as "green bar"). The
      > aforementioned practice is something that has worked well on our
      > project and I consider it consistent with the XP practices.
      >
      > --- In extremeprogramming@yahoogroups.com, Ron Jeffries
      > <ronjeffries@X...> wrote:
      > > On Wednesday, August 27, 2003, at 4:44:07 PM, Omar Bernardi wrote:
      > >
      > > > The estimations for a given story, are issued by one programmer
      > or by a pair?
      > >
      > > For overall project estimation, whole team is best IMO.
      > >
      > > > Is the size of any given story dependent of the "programmer/pair"
      > who
      > > > estimates it? (no matter what metric he will use, ideal days,
      > points,
      > > > effort, etc).
      > >
      > > Generally no. The objective is for the whole team to use the
      > same "units",
      > > and to converge on uniform estimates. The ideal situation is that
      > any pair,
      > > or nearly any pair, can take any story.
      > >
      > > The reality is always somewhat short of this, of course. It's an
      > ideal.
      > >
      > > > So for a given iteration, can two different pairs make different
      > > > estimations for the same story?
      > >
      > > In practice, sure. In principle, I'd like them to reach agreement.
      > >
      > > > What size should I show to the customer, the smaller, the bigger,
      > both, an average, or none?
      > >
      > > If the team is learning to estimate in terms of the team's
      > capability, it's
      > > probably best to reach agreement, and to use the consensus number.
      > Some
      > > teams use the smaller number, which is a good way to get them to
      > negotiate
      > > agreement, since they'll all be "on the hook" for that estimate.
      > >
      > > Note, however, that the canonical way is to estimate difficulty
      > separate
      > > from actual time to completion, using the notion of velocity to
      > convert
      > > difficulty to time to complete. This means that the team needs to
      > agree on
      > > how hard the thing is compared to other things, not on the absolute
      > time to
      > > completion. This makes estimation easier, less stressful, and in my
      > > opinion, more accurate.
      > >
      > > > Could the customer decide to assign that story to the pair whose
      > > > estimation is lower, and therefore aquiring more free
      > points/idays to
      > > > allocate to other stories?
      > >
      > > That would not be canonical. Who does things is a technical
      > decision. It's
      > > one good reason not to have separate estimates. It will not serve
      > anyone
      > > well to have the customer deciding how technical things will be
      > done, in my
      > > opinion. I'm not aware of any teams that work this way -- it would
      > be
      > > interesting to hear from them if there are.
      > >
      > > > Should each "pair" take account of their estimations/results so
      > they can
      > > > better estimate in the next stories?
      > >
      > > Of course. And so should the whole team. The whole team should feel
      > > responsible for every story. It isn't just you and me, who happen
      > to have
      > > signed up for it, who are on the hook. We all are.
      > >
      > > > Could you use that estimations to better predict the size of the
      > similar
      > > > stories in other releases/projects?
      > >
      > > Yes. Highly recommended.
      > >
      > > > should you take in account what pairs of programmers are going to
      > be
      > > > involved in the project?
      > >
      > > You speak of pairs as if they were for life. Programmers do not
      > mate for
      > > life. Some mate for a day, some for only a few hours. Some, rarely,
      > for a
      > > whole iteration. Smaller is better in my estimation.
      > >
      > > In my opinion, we should have every project estimated by the
      > programmers
      > > who are going to do it, as a team. Anything else is fraught with
      > > difficulties which are simply avoided by getting estimates from
      > those who
      > > are most concerned and most knowledgeable.
      > >
      > >
      > > Ron Jeffries
      > > www.XProgramming.com
      > > Think! -- Aretha Franklin
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
    • Karsten, Paul
      Hi Omar, Typically when I do this the whole team estimates stories. It is thus not dependant on a single person but reflects the experience and thoughts of
      Message 2 of 7 , Aug 27, 2003
      • 0 Attachment
        Hi Omar,

        Typically when I do this the whole team estimates stories. It is thus not
        dependant on a single person but reflects the experience and thoughts of the
        whole team.

        Paul

        -----Original Message-----
        From: Omar Bernardi [mailto:o_bernardi@...]
        Sent: Wednesday, August 27, 2003 2:44 PM
        To: extremeprogramming@yahoogroups.com
        Subject: [XP] sizing stories


        Hi fellows,
        some easy questions about sizing stories...

        The estimations for a given story, are issued by one programmer or by a
        pair? Is the size of any given story dependent of the "programmer/pair" who
        estimates it? (no matter what metric he will use, ideal days, points,
        effort, etc). So for a given iteration, can two different pairs make
        different estimations for the same story? What size should I show to the
        customer, the smaller, the bigger, both, an average, or none? Could the
        customer decide to assign that story to the pair whose estimation is lower,
        and therefore aquiring more free points/idays to allocate to other stories?
        Should each "pair" take account of their estimations/results so they can
        better estimate in the next stories?
        Could you use that estimations to better predict the size of the similar
        stories in other releases/projects?
        should you take in account what pairs of programmers are going to be
        involved in the project?

        Thank you,
        Omar.


        [Non-text portions of this message have been removed]


        To Post a message, send it to: extremeprogramming@...

        To Unsubscribe, send a blank message to:
        extremeprogramming-unsubscribe@...

        ad-free courtesy of objectmentor.com

        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Shellman, Joel
        One thing that I have to keep reminding myself is that even though one pair could do something in 2 hours that would take a different pair 2 days, it still
        Message 3 of 7 , Aug 27, 2003
        • 0 Attachment
          One thing that I have to keep reminding myself is that even though one pair
          could do something in 2 hours that would take a different pair 2 days, it
          still should work out if you use arbitrary units for team velocity.

          It's still 4 units, say, regardless of whether it takes two hours or two
          days. It just happens that the fast pairing could accomplish 20 units per
          iteration whereas the other one could only do 4 (or whatever). What happens
          is that, even if you don't track it, different people/pairings have
          different velocities that add up together to make the team velocity.
          Generally speaking, that total velocity should be fairly stable, though.

          -joel


          -----Original Message-----
          From: Ron Jeffries [mailto:ronjeffries@...]
          Sent: Wednesday, August 27, 2003 4:21 PM
          To: extremeprogramming@yahoogroups.com
          Subject: Re: [XP] sizing stories


          On Wednesday, August 27, 2003, at 4:44:07 PM, Omar Bernardi wrote:

          > The estimations for a given story, are issued by one programmer or by
          > a pair?

          For overall project estimation, whole team is best IMO.

          > Is the size of any given story dependent of the "programmer/pair" who
          > estimates it? (no matter what metric he will use, ideal days, points,
          > effort, etc).

          Generally no. The objective is for the whole team to use the same "units",
          and to converge on uniform estimates. The ideal situation is that any pair,
          or nearly any pair, can take any story.

          The reality is always somewhat short of this, of course. It's an ideal.

          > So for a given iteration, can two different pairs make different
          > estimations for the same story?

          In practice, sure. In principle, I'd like them to reach agreement.

          > What size should I show to the customer, the smaller, the bigger,
          > both, an average, or none?

          If the team is learning to estimate in terms of the team's capability, it's
          probably best to reach agreement, and to use the consensus number. Some
          teams use the smaller number, which is a good way to get them to negotiate
          agreement, since they'll all be "on the hook" for that estimate.

          Note, however, that the canonical way is to estimate difficulty separate
          from actual time to completion, using the notion of velocity to convert
          difficulty to time to complete. This means that the team needs to agree on
          how hard the thing is compared to other things, not on the absolute time to
          completion. This makes estimation easier, less stressful, and in my opinion,
          more accurate.

          > Could the customer decide to assign that story to the pair whose
          > estimation is lower, and therefore aquiring more free points/idays to
          > allocate to other stories?

          That would not be canonical. Who does things is a technical decision. It's
          one good reason not to have separate estimates. It will not serve anyone
          well to have the customer deciding how technical things will be done, in my
          opinion. I'm not aware of any teams that work this way -- it would be
          interesting to hear from them if there are.

          > Should each "pair" take account of their estimations/results so they
          > can better estimate in the next stories?

          Of course. And so should the whole team. The whole team should feel
          responsible for every story. It isn't just you and me, who happen to have
          signed up for it, who are on the hook. We all are.

          > Could you use that estimations to better predict the size of the
          > similar stories in other releases/projects?

          Yes. Highly recommended.

          > should you take in account what pairs of programmers are going to be
          > involved in the project?

          You speak of pairs as if they were for life. Programmers do not mate for
          life. Some mate for a day, some for only a few hours. Some, rarely, for a
          whole iteration. Smaller is better in my estimation.

          In my opinion, we should have every project estimated by the programmers who
          are going to do it, as a team. Anything else is fraught with difficulties
          which are simply avoided by getting estimates from those who are most
          concerned and most knowledgeable.


          Ron Jeffries
          www.XProgramming.com
          Think! -- Aretha Franklin
        • Omar Bernardi
          so, let me see if I ve learnt the lesson: Stories should be sized by the entire team, trying to reach to an agreement about how big/difficult is it. The
          Message 4 of 7 , Aug 28, 2003
          • 0 Attachment
            so, let me see if I've learnt the lesson:

            Stories should be sized by the entire team, trying to reach to an agreement
            about how big/difficult is it.
            The customer only choose which stories are being to be included in this
            iteration.
            All the stories that fits within this iteration are given to the programmers
            so they can sign for those they feel more comfortable/attracted to develop.
            All of them must use the same "units".
            The unclaimed stories must be developed by someone, so somebody should sign
            for that unpleasant stories.
            The programmer who sign for the story also makes his own estimation.
            and it could be different from the originally estimated by the team.
            The programmer estimation overcomes the team estimation.
            He must take into account that he will spend some time helping/pairing other
            developers,
            so his productivity should decrease.
            That's one of the reason to use ideal days as units, because they take into
            account this kind of situations.
            The programmer is responsible for the completion of that story,
            and the effort resulting of that development owns only to himself,
            no matter who and how many developers had paired with him to help doing it.
            He should use that estimation/results for better estimate future stories by
            himself,
            and to give better estimations when the team meets to size new stories.
            Personal velocity (units finished in the iteration) developed by each
            programmer builds up the team's velocity for the next iteration.

            pretty easy, doesn't it?

            Thank you mates.
            Omar.

            ----- Original Message -----
            From: "vidmas_k" <vidmas_k@...>
            To: <extremeprogramming@yahoogroups.com>
            Sent: Wednesday, August 27, 2003 11:53 PM
            Subject: Re: [XP] sizing stories


            > In our practice of XP, during iteration meetings individuals take
            > cards (stories) that can be completed within the iteration (two weeks
            > for us). The cards are given a rating 1, 2, or 3. One being easy, two
            > being moderate, and three being hard. The person that takes the card
            > makes the difficulty assesment and pairs with someone, but not for
            > more than a couple of days. Only the person responsible for the card
            > should estimate. We have had too many customer/developers make the
            > decision (meaning a developer that is actually a manager or
            > customer). We switch between pairing on "our" cards and other peoples
            > cards throughout the iteration. That is one reason we dispensed with
            > letting management know about personal velocity. Personal velocity
            > creates an environment where developers feel they only need to work
            > on cards that they get points for. (If an individual takes this as an
            > opportunity to slack off, the best policy is to have the team kick
            > his or her ass rather then go through the cowardly management layer).
            > If at the end of the iteration, the developer still hasn't finished
            > his or her card (this reminds me of a dialog between the PFJ in Monty
            > Pythons "Life of Brian"), HE OR SHE IS NOT ALLOWED TO TAKE THE SAME
            > CARD! Code ownership on a team project is the source of all evil. To
            > answer your question, on our project the story estimation is done by
            > the developer taking the card. If two different pairs have a
            > different estimation, it is irrelavent. When another person takes the
            > card, they can make their own estimation. If the estimation is
            > greater than a 3 or if it takes more than one iteration, we break out
            > the story into more cards (sub stories). (Notice the way I employ the
            > word card and story interchangeably. Not that I want to create a
            > debate between the semantics between card and story but, if enough
            > people utilized this lingo because it was zeitgeist, then I guess it
            > would be like referring to test passing as "green bar"). The
            > aforementioned practice is something that has worked well on our
            > project and I consider it consistent with the XP practices.
            >
            > --- In extremeprogramming@yahoogroups.com, Ron Jeffries
            > <ronjeffries@X...> wrote:
            > > On Wednesday, August 27, 2003, at 4:44:07 PM, Omar Bernardi wrote:
            > >
            > > > The estimations for a given story, are issued by one programmer
            > or by a pair?
            > >
            > > For overall project estimation, whole team is best IMO.
            > >
            > > > Is the size of any given story dependent of the "programmer/pair"
            > who
            > > > estimates it? (no matter what metric he will use, ideal days,
            > points,
            > > > effort, etc).
            > >
            > > Generally no. The objective is for the whole team to use the
            > same "units",
            > > and to converge on uniform estimates. The ideal situation is that
            > any pair,
            > > or nearly any pair, can take any story.
            > >
            > > The reality is always somewhat short of this, of course. It's an
            > ideal.
            > >
            > > > So for a given iteration, can two different pairs make different
            > > > estimations for the same story?
            > >
            > > In practice, sure. In principle, I'd like them to reach agreement.
            > >
            > > > What size should I show to the customer, the smaller, the bigger,
            > both, an average, or none?
            > >
            > > If the team is learning to estimate in terms of the team's
            > capability, it's
            > > probably best to reach agreement, and to use the consensus number.
            > Some
            > > teams use the smaller number, which is a good way to get them to
            > negotiate
            > > agreement, since they'll all be "on the hook" for that estimate.
            > >
            > > Note, however, that the canonical way is to estimate difficulty
            > separate
            > > from actual time to completion, using the notion of velocity to
            > convert
            > > difficulty to time to complete. This means that the team needs to
            > agree on
            > > how hard the thing is compared to other things, not on the absolute
            > time to
            > > completion. This makes estimation easier, less stressful, and in my
            > > opinion, more accurate.
            > >
            > > > Could the customer decide to assign that story to the pair whose
            > > > estimation is lower, and therefore aquiring more free
            > points/idays to
            > > > allocate to other stories?
            > >
            > > That would not be canonical. Who does things is a technical
            > decision. It's
            > > one good reason not to have separate estimates. It will not serve
            > anyone
            > > well to have the customer deciding how technical things will be
            > done, in my
            > > opinion. I'm not aware of any teams that work this way -- it would
            > be
            > > interesting to hear from them if there are.
            > >
            > > > Should each "pair" take account of their estimations/results so
            > they can
            > > > better estimate in the next stories?
            > >
            > > Of course. And so should the whole team. The whole team should feel
            > > responsible for every story. It isn't just you and me, who happen
            > to have
            > > signed up for it, who are on the hook. We all are.
            > >
            > > > Could you use that estimations to better predict the size of the
            > similar
            > > > stories in other releases/projects?
            > >
            > > Yes. Highly recommended.
            > >
            > > > should you take in account what pairs of programmers are going to
            > be
            > > > involved in the project?
            > >
            > > You speak of pairs as if they were for life. Programmers do not
            > mate for
            > > life. Some mate for a day, some for only a few hours. Some, rarely,
            > for a
            > > whole iteration. Smaller is better in my estimation.
            > >
            > > In my opinion, we should have every project estimated by the
            > programmers
            > > who are going to do it, as a team. Anything else is fraught with
            > > difficulties which are simply avoided by getting estimates from
            > those who
            > > are most concerned and most knowledgeable.
            > >
            > >
            > > Ron Jeffries
            > > www.XProgramming.com
            > > Think! -- Aretha Franklin
            >
            >
            > To Post a message, send it to: extremeprogramming@...
            >
            > To Unsubscribe, send a blank message to:
            extremeprogramming-unsubscribe@...
            >
            > ad-free courtesy of objectmentor.com
            >
            > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            >
          • Ron Jeffries
            One man s opinion ... ... Yes, this is my recommendation. ... Customer also considers the whole release, using story estimates and team velocity, to make
            Message 5 of 7 , Aug 28, 2003
            • 0 Attachment
              One man's opinion ...

              On Thursday, August 28, 2003, at 12:03:27 PM, Omar Bernardi wrote:

              > so, let me see if I've learnt the lesson:

              > Stories should be sized by the entire team, trying to reach to an agreement
              > about how big/difficult is it.

              Yes, this is my recommendation.

              > The customer only choose which stories are being to be included in this
              > iteration.

              Customer also considers the whole release, using story estimates and team
              velocity, to make larger-scale decisions like whether to cancel the
              project, what kinds of predictions to make to stakeholders, whether to buy
              pizza for the team, and so on.

              > All the stories that fits within this iteration are given to the programmers
              > so they can sign for those they feel more comfortable/attracted to develop.

              That's my recommendation, yes.

              > All of them must use the same "units".

              This seems most efficacious, yes.

              > The unclaimed stories must be developed by someone, so somebody should sign
              > for that unpleasant stories.

              Yes.

              > The programmer who sign for the story also makes his own estimation.

              This is optional. Certainly if the programmer thinks his estimate is much
              higher or lower than the team one, some discussion should ensue.

              > and it could be different from the originally estimated by the team.
              > The programmer estimation overcomes the team estimation.

              If you mean that the programmer should not be held to a smaller estimate
              than he thinks he can accomplish, yes.

              > He must take into account that he will spend some time helping/pairing other
              > developers,
              > so his productivity should decrease.

              Productivity does not necessarily decrease as a function of pairing.
              Velocity handles it anyway.

              > That's one of the reason to use ideal days as units, because they take into
              > account this kind of situations.

              Yes. Although any arbitrary unit has this property. Only real time
              estimates conflate the effects.

              > The programmer is responsible for the completion of that story,
              > and the effort resulting of that development owns only to himself,
              > no matter who and how many developers had paired with him to help doing it.

              I'm not sure what you are getting at here. Some teams prefer having an
              individual responsible for a story. Some prefer a pair. The best thing is
              for the whole team to own responsibility for all stories, because if
              someone gets in trouble, everyone should pitch in to make things better.

              > He should use that estimation/results for better estimate future stories by
              > himself,
              > and to give better estimations when the team meets to size new stories.

              Sure ...

              > Personal velocity (units finished in the iteration) developed by each
              > programmer builds up the team's velocity for the next iteration.

              Velocity is the sum of the Team estimates, not the sum of the Personal
              estimates, at least in my opinion. It might work the other way but in fact
              I think the less time spent worrying about personal estimates the better.

              > pretty easy, doesn't it?

              In fact yes ...

              Ron Jeffries
              www.XProgramming.com
              Accroche toi a ton reve. --ELO
            • Omar Bernardi
              ... From: Ron Jeffries ... agreement ... programmers ... develop. ... sign ... other ... into ... I m not sure what are you
              Message 6 of 7 , Aug 28, 2003
              • 0 Attachment
                ----- Original Message -----
                From: "Ron Jeffries" <ronjeffries@...>
                > One man's opinion ...
                >
                > On Thursday, August 28, 2003, at 12:03:27 PM, Omar Bernardi wrote:
                >
                > > so, let me see if I've learnt the lesson:
                >
                > > Stories should be sized by the entire team, trying to reach to an
                agreement
                > > about how big/difficult is it.
                >
                > Yes, this is my recommendation.
                >
                > > The customer only choose which stories are being to be included in this
                > > iteration.
                >
                > Customer also considers the whole release, using story estimates and team
                > velocity, to make larger-scale decisions like whether to cancel the
                > project, what kinds of predictions to make to stakeholders, whether to buy
                > pizza for the team, and so on.
                >
                > > All the stories that fits within this iteration are given to the
                programmers
                > > so they can sign for those they feel more comfortable/attracted to
                develop.
                >
                > That's my recommendation, yes.
                >
                > > All of them must use the same "units".
                >
                > This seems most efficacious, yes.
                >
                > > The unclaimed stories must be developed by someone, so somebody should
                sign
                > > for that unpleasant stories.
                >
                > Yes.
                >
                > > The programmer who sign for the story also makes his own estimation.
                >
                > This is optional. Certainly if the programmer thinks his estimate is much
                > higher or lower than the team one, some discussion should ensue.
                >
                > > and it could be different from the originally estimated by the team.
                > > The programmer estimation overcomes the team estimation.
                >
                > If you mean that the programmer should not be held to a smaller estimate
                > than he thinks he can accomplish, yes.
                >
                > > He must take into account that he will spend some time helping/pairing
                other
                > > developers,
                > > so his productivity should decrease.
                >
                > Productivity does not necessarily decrease as a function of pairing.
                > Velocity handles it anyway.
                >
                > > That's one of the reason to use ideal days as units, because they take
                into
                > > account this kind of situations.
                >
                > Yes. Although any arbitrary unit has this property. Only real time
                > estimates conflate the effects.

                I'm not sure what are you meaning with "conflate the effects".
                Here I have a doubt. If for a given project you use, let's say, "points",
                should you use the same amount of "points" for a similar story on another
                project, or you can use a different scale of "points"?
                If you do that (use different scales of points), doesn't it invalidates your
                prior measures of stories?

                >
                > > The programmer is responsible for the completion of that story,
                > > and the effort resulting of that development owns only to himself,
                > > no matter who and how many developers had paired with him to help doing
                it.
                >
                > I'm not sure what you are getting at here. Some teams prefer having an
                > individual responsible for a story. Some prefer a pair. The best thing is
                > for the whole team to own responsibility for all stories, because if
                > someone gets in trouble, everyone should pitch in to make things better.
                >
                > > He should use that estimation/results for better estimate future stories
                by
                > > himself,
                > > and to give better estimations when the team meets to size new stories.
                >
                > Sure ...
                >
                > > Personal velocity (units finished in the iteration) developed by each
                > > programmer builds up the team's velocity for the next iteration.
                >
                > Velocity is the sum of the Team estimates, not the sum of the Personal
                > estimates, at least in my opinion. It might work the other way but in fact
                > I think the less time spent worrying about personal estimates the better.
                >
                Velocity is the sum of story "units" accomplished in the iteration, isn't
                it?
                What I was trying to say was that each programmer at the end of the
                iteration accomplished some amount of "units".
                the sum of all these "units" builds up the current velocity for the next
                iteration.
                but it is OK, I got the idea.

                > > pretty easy, doesn't it?
                >
                > In fact yes ...
                >
                > Ron Jeffries
                > www.XProgramming.com
                > Accroche toi a ton reve. --ELO
                >

                Thank you, Ron.
                Regards,
                Omar.
              • Ron Jeffries
                ... No more than weighing yourself in kilograms today and pounds tomorrow invalidates your knowledge of weight. Ron Jeffries www.XProgramming.com You don t
                Message 7 of 7 , Aug 28, 2003
                • 0 Attachment
                  On Thursday, August 28, 2003, at 7:21:32 PM, Omar Bernardi wrote:

                  >> Yes. Although any arbitrary unit has this property. Only real time
                  >> estimates conflate the effects.

                  > I'm not sure what are you meaning with "conflate the effects".
                  > Here I have a doubt. If for a given project you use, let's say, "points",
                  > should you use the same amount of "points" for a similar story on another
                  > project, or you can use a different scale of "points"?
                  > If you do that (use different scales of points), doesn't it invalidates your
                  > prior measures of stories?

                  No more than weighing yourself in kilograms today and pounds tomorrow
                  invalidates your knowledge of weight.

                  Ron Jeffries
                  www.XProgramming.com
                  You don't want to sell me waterfall.
                  You want to go home and rethink your life.
                Your message has been successfully submitted and would be delivered to recipients shortly.