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

Re: [XP] Estimation and load factor

Expand Messages
  • Nick Holt
    Keep track of original and current estimates. Compare the two when you ve finished and feedback what you ve learnt with a view to improving estimates in the
    Message 1 of 17 , Jun 26, 2003
    • 0 Attachment
      Keep track of original and current estimates. Compare the two when you've
      finished and feedback what you've learnt with a view to improving estimates
      in the future. Joel explains this in more detail here -
      http://www.joelonsoftware.com/articles/fog0000000245.html

      The other thing that's important is to record start and finish dates, so
      that you can calculate a velocity for each developer.


      ----- Original Message -----
      From: <haralds@...>
      To: <extremeprogramming@yahoogroups.com>
      Sent: Thursday, June 26, 2003 9:38 AM
      Subject: [XP] Estimation and load factor


      > Hello, I am wondering about time estimation and when to justify the value
      > of the load factor.
      > For instance, a developer estimates one task to be 6 ideal hours. Then
      > after finally finsihing the task, it took 12 ideal hours. However, he has
      > been undisturbed and his mind has been at peace, everything going for him.
      > In other words, he had underestimated the complexity of the task. In this
      > case, I guess that the load factor should not be adjusted or should it? Or
      > do you record 12 ideal hours (for your project velocity) and just accept
      > that it was a bad estimate? Hopefully you can guess what I am pointing at,
      > despite my maybe poor description.
      >
      > Regards
      > Harald
      >
      >
      >
      > 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/
      >
      >
    • Piergiuliano Bossi
      ... I think that I have to respectfully disagree with this, but maybe we mean different things. It has been already discussed in the past in this list, where
      Message 2 of 17 , Jun 27, 2003
      • 0 Attachment
        Pieter Nagel wrote:

        >On Thu, Jun 26, 2003 at 10:38:36AM +0200, haralds@... wrote:
        >
        >
        >
        >>For instance, a developer estimates one task to be 6 ideal hours. Then
        >>after finally finsihing the task, it took 12 ideal hours.
        >>
        >>
        >
        >Don't fall into the trap of trying to make the ideal and real hours match
        >up.
        >

        I think that I have to respectfully disagree with this, but maybe we
        mean different things. It has been already discussed in the past in this
        list, where the pomodori issue came out. You may want to reread
        http://groups.yahoo.com/group/extremeprogramming/message/52143 or
        http://groups.yahoo.com/group/extremeprogramming/message/65134

        There are teams that are working only with real hours (or actual time,
        if you prefer), they are happy and successful reasonably enough, they
        try to manage their estimation error, sometimes they get it but
        everytime they learn something new about their customers, technologies,
        complexities and so on. The choice between estimating by means of ideal
        time and actual time is mainly a matter of:
        *) company's culture
        *) organizational issues
        *) customer's expectations

        If you have access to XP2003 procedings you may want to take a look at
        my paper: "Using Actual Time: Learning How to Estimate"
        Abstract and slides are available online respectively at
        http://www.xp2003.org/abstract/53.txt and
        http://www.xp2003.org/slides/53.pdf

        Ciao, Giuliano



        [Non-text portions of this message have been removed]
      • Pieter Nagel
        ... I read what you said and decided to modify my position. Estimation has two goals: to predict the completion time of future tasks, and to assess the impact
        Message 3 of 17 , Jun 27, 2003
        • 0 Attachment
          On Fri, Jun 27, 2003 at 10:21:16AM +0200, Piergiuliano Bossi wrote:

          > I think that I have to respectfully disagree with this, but maybe we
          > mean different things.

          I read what you said and decided to modify my position. Estimation has two
          goals: to predict the completion time of future tasks, and to assess the
          impact of past changes in your environment. Your psoition, and mine, focus
          on different aspects of this.

          1) One can try to estimate in terms of objective "real hours". This serves
          the prediction goal. The assessment goal is achieved by subjectively
          noticing whether a "one hour task" is bigger nowadays than it used to be
          in the past.

          2) One can try and estimate in terms of subjective "units of equal
          effort". The prediction goal is served by tracking how many units of work
          one can do per iteration. The assessment goal is served by comparing your
          velocity to your past velocity.

          I can see that both could work. I think 1) would work best in a more stable
          environment (it is hard to converge one's estimated hours and real hours
          if team dynamics and the smellines of the codebase vary wildly from
          iteration to iteration, for example). 1) seems to value accurate
          prediction over assessment.

          I would think alternative 2) works better in environments with a lot of
          noise. If one anticipates a lot of interruptions and morale blows in the
          upcoming iteration, it is hard to know how to adjust one's estimates
          upfront; it is easier to cut through the cruft and just ask yourself: "Is
          this job one, twice, or three time as much effort as the other 1 point
          tasks we done up till now?" In alternative 2) one can point to
          dropping/climbing velocity as a way to prove to management whether their
          inspirational retrenchment speeches are a boost or a detriment to
          productivity, for example. Alternative 2) seems to value assessment over
          prediction.


          Whatever one chooses, one should be clear on that choice. If you go for
          1), I one should NOT talk about "task points", "story points", "ideal
          hours" "load factors" etc.; it just moddies the issue and introduces to
          many levels of indirection.

          If you for 2), one should be careful of the "ideal hour" red herring and
          try to keep modifying one's unit of measurement until gummybears always
          take 3 real hours to complete, for example.

          The whole "ideal hour" thing is only a bootstrapping issue. Initially, a
          team needs some or other verbal way of explaining what the heck a
          "gummybear" unit of work is; talking in terms of ideal hours is one way of
          achieving this.

          But one could just as well bootstrap using other notions, such as: "A
          gummybear is a job that requires 20 edit/test cycles to complete", or "A
          gummybear is a job that we can conceive explaining to the first-year
          students we tutored last year in one lecture".

          Thereafter future gummybears start becoming relative to past gummybears.

          --
          ,_
          /_) /| /
          / i e t e r / |/ a g e l
          http://www.nagel.co.za
        • Piergiuliano Bossi
          Peter, I think you are right when you say that 2) could work better in an environment with a lot of noise, but I d like to add that it s a lot better to work
          Message 4 of 17 , Jun 27, 2003
          • 0 Attachment
            Peter,

            I think you are right when you say that 2) could work better in an
            environment with a lot of noise, but I'd like to add that it's a lot
            better to work in a more established and productive environment. Of
            course, it is not always possible to change the environment since day 1,
            but remember Kent's advice at the end of chapter 19 ("Adopting XP") of
            the white book: "Don't underestimate the importance of the physical
            environment when adopting XP, even if you aren't aware of it as a
            problem. I often start with a screwdriver and an Allen wrench."
            I think that considerations on physical environment should be extended
            to "mental" environment and organization too. Moving towards using
            actual time and environmental conditions influence each other. The point
            is to make it a virtuous circle of positive influences.

            There is one thing left that I'm not sure to understand in your reply:
            why do you think that 1) value accurate prediction over assessment?

            Ciao, Giuliano


            Pieter Nagel wrote:

            >On Fri, Jun 27, 2003 at 10:21:16AM +0200, Piergiuliano Bossi wrote:
            >
            >
            >
            >>I think that I have to respectfully disagree with this, but maybe we
            >>mean different things.
            >>
            >>
            >
            >I read what you said and decided to modify my position. Estimation has two
            >goals: to predict the completion time of future tasks, and to assess the
            >impact of past changes in your environment. Your psoition, and mine, focus
            >on different aspects of this.
            >
            >1) One can try to estimate in terms of objective "real hours". This serves
            >the prediction goal. The assessment goal is achieved by subjectively
            >noticing whether a "one hour task" is bigger nowadays than it used to be
            >in the past.
            >
            >2) One can try and estimate in terms of subjective "units of equal
            >effort". The prediction goal is served by tracking how many units of work
            >one can do per iteration. The assessment goal is served by comparing your
            >velocity to your past velocity.
            >
            >I can see that both could work. I think 1) would work best in a more stable
            >environment (it is hard to converge one's estimated hours and real hours
            >if team dynamics and the smellines of the codebase vary wildly from
            >iteration to iteration, for example). 1) seems to value accurate
            >prediction over assessment.
            >
            >I would think alternative 2) works better in environments with a lot of
            >noise. If one anticipates a lot of interruptions and morale blows in the
            >upcoming iteration, it is hard to know how to adjust one's estimates
            >upfront; it is easier to cut through the cruft and just ask yourself: "Is
            >this job one, twice, or three time as much effort as the other 1 point
            >tasks we done up till now?" In alternative 2) one can point to
            >dropping/climbing velocity as a way to prove to management whether their
            >inspirational retrenchment speeches are a boost or a detriment to
            >productivity, for example. Alternative 2) seems to value assessment over
            >prediction.
            >
            >
            >Whatever one chooses, one should be clear on that choice. If you go for
            >1), I one should NOT talk about "task points", "story points", "ideal
            >hours" "load factors" etc.; it just moddies the issue and introduces to
            >many levels of indirection.
            >
            >If you for 2), one should be careful of the "ideal hour" red herring and
            >try to keep modifying one's unit of measurement until gummybears always
            >take 3 real hours to complete, for example.
            >
            >The whole "ideal hour" thing is only a bootstrapping issue. Initially, a
            >team needs some or other verbal way of explaining what the heck a
            >"gummybear" unit of work is; talking in terms of ideal hours is one way of
            >achieving this.
            >
            >But one could just as well bootstrap using other notions, such as: "A
            >gummybear is a job that requires 20 edit/test cycles to complete", or "A
            >gummybear is a job that we can conceive explaining to the first-year
            >students we tutored last year in one lecture".
            >
            >Thereafter future gummybears start becoming relative to past gummybears.
            >
            >
            >



            [Non-text portions of this message have been removed]
          • Pieter Nagel
            ... But that s sort-of my point. If one happens to be in a sub-optimal environment, and one has a long list of process smells to fix, I would opt for the
            Message 5 of 17 , Jun 27, 2003
            • 0 Attachment
              On Fri, Jun 27, 2003 at 06:01:24PM +0200, Piergiuliano Bossi wrote:

              > I think you are right when you say that 2) could work better in an
              > environment with a lot of noise, but I'd like to add that it's a lot
              > better to work in a more established and productive environment.

              But that's sort-of my point.

              If one happens to be in a sub-optimal environment, and one has a long list
              of process smells to fix, I would opt for the "gummybear estimation"
              scenario 2), choose the worst smell, fix it, watch the effect on velocity,
              repeat.

              Once one has converged on a more stable environment, the estimation style
              that /you/ propose may be more suitable.

              > There is one thing left that I'm not sure to understand in your reply:
              > why do you think that 1) value accurate prediction over assessment?

              I was trying to contrast 1) vs 2) in terms of their objective and
              subjective components.

              Style 1) objectively tracks estimation accuracy: you estimate 1 hour, it
              takes 2 hours, you know your estimates are *exactly* 50% out. But whether
              your 1 hour "build foowidget" task is more, or less, work than last months
              1 hour "frobnitz updates itself" task is a subjective judgement call.

              Style 2) objectively tracks velocity: you sum up the gummybears on each of
              the completed cards. It is more subjective in its estimates: whether the
              2-gummybear task that you are about to work in *really* is twice as much
              work as last months 1-gummybear task is a subejctive judgement call.

              My intuition is that whichever of prediction vs. assessment is the highest
              priority in your project should be tracked on the "objective" side, and
              one has to trust and make a best-effort that one judges the "subjective"
              quality well enough that the numbers are /meaningful/, even if not
              mathematically exact.

              But that is only an intuition I have. You have got me thinking about the
              interesting question of which types of subjective judgements are more
              valuable, in which contexts.

              --
              ,_
              /_) /| /
              / i e t e r / |/ a g e l
              http://www.nagel.co.za
            • Piergiuliano Bossi
              ... It s a possibility, I know, but let me highlight that a key point is learning how to estimate: I m sure that ideal time & yesterday s weather are effective
              Message 6 of 17 , Jun 29, 2003
              • 0 Attachment
                Pieter Nagel wrote:

                >On Fri, Jun 27, 2003 at 06:01:24PM +0200, Piergiuliano Bossi wrote:
                >
                >
                >
                >>I think you are right when you say that 2) could work better in an
                >>environment with a lot of noise, but I'd like to add that it's a lot
                >>better to work in a more established and productive environment.
                >>
                >>
                >
                >But that's sort-of my point.
                >
                >If one happens to be in a sub-optimal environment, and one has a long list
                >of process smells to fix, I would opt for the "gummybear estimation"
                >scenario 2), choose the worst smell, fix it, watch the effect on velocity,
                >repeat.
                >
                >Once one has converged on a more stable environment, the estimation style
                >that /you/ propose may be more suitable.
                >

                It's a possibility, I know, but let me highlight that a key point is
                learning how to estimate: I'm sure that ideal time & yesterday's weather
                are effective tools in terms of correction of estimation error, but they
                work unconsciously. Thereby, I'm not convinced that you really learn to
                estimate this way. YW may lead to a much broader volatility in
                estimation error corrections than using actual time. This is also one of
                the points that I have made in my paper.

                Anyway, if learning how to estimate is not your worst problem, you
                shouldn't address it in the first place. But sooner or later ...
                .

                >I was trying to contrast 1) vs 2) in terms of their objective and
                >subjective components.
                >
                >Style 1) objectively tracks estimation accuracy: you estimate 1 hour, it
                >takes 2 hours, you know your estimates are *exactly* 50% out. But whether
                >your 1 hour "build foowidget" task is more, or less, work than last months
                >1 hour "frobnitz updates itself" task is a subjective judgement call.
                >

                Really? 1 hour is 1 hour. Period. Do you know anything more objective
                than this?
                (Well, of course if you are running at approximately the speed of light,
                then things start becoming different. :-))
                Comparing task efforts in terms of actual time seems much more effective
                to me than doing it in terms of imaginative unity measures. Unless your
                time is so much messed up with interruptions (emails, phone calls,
                meetings, etc) to make it totally meaningless. I think this is one point
                in which we can agree, isn't it?

                >Style 2) objectively tracks velocity: you sum up the gummybears on each of
                >the completed cards. It is more subjective in its estimates: whether the
                >2-gummybear task that you are about to work in *really* is twice as much
                >work as last months 1-gummybear task is a subejctive judgement call.
                >

                Estimating in terms of actual time doesn't prevent nor dictate to track
                velocity and to get feedback from velocity variations.

                >My intuition is that whichever of prediction vs. assessment is the highest
                >priority in your project should be tracked on the "objective" side, and
                >one has to trust and make a best-effort that one judges the "subjective"
                >quality well enough that the numbers are /meaningful/, even if not
                >mathematically exact.
                >
                >But that is only an intuition I have. You have got me thinking about the
                >interesting question of which types of subjective judgements are more
                >valuable, in which contexts.
                >
                >

                Peter, maybe my problem is that I don't really see the contrast
                "prediction vs assessment" that you are outlining.

                Ciao, Giuliano




                [Non-text portions of this message have been removed]
              • Pieter Nagel
                ... That I agree with. My point is that if you spent an hour today to create a new widget, and you spent an hour last month to add view-only permissions on a
                Message 7 of 17 , Jun 30, 2003
                • 0 Attachment
                  On Sun, Jun 29, 2003 at 05:09:47PM +0200, Piergiuliano Bossi wrote:

                  > Really? 1 hour is 1 hour. Period. Do you know anything more objective
                  > than this?

                  That I agree with.

                  My point is that if you spent an hour today to create a new widget, and
                  you spent an hour last month to add view-only permissions on a bank
                  account, how do you know whether you were more productive than you were
                  last month? Should you be happy that you got as much as an entire new
                  widget done today, or should you be concerned that you could not do as
                  much as last month?

                  You decide, subjectively, whether the widget was more work than the
                  bank account.

                  > Estimating in terms of actual time doesn't prevent nor dictate to track
                  > velocity and to get feedback from velocity variations.

                  My concern is, if you have 50 pair-hours available per iteration, then, as
                  your estimation abilities improve, your velocity should converge towards
                  "we can do 50 hours worth of work per iteration". If you introduce a new
                  variable in the environment (faster developer boxes, say) there should be
                  a temporary spike or sag in your estimations - you discover that you can
                  actually do 55 hours worth of work now. But as you begin to take the new
                  boxes into account in your estimations, you again converge back to
                  estimating that you can do 50 hours worth of work per iteration.

                  That is great if you are most concerned about having a high degree of
                  confidence that what you estimate will take 2 iterations to complete,
                  will, in fact, be done after 2 iterations. But if you want to compare your
                  velocity of 50 to your the velocity of 50 you had a year ago - how do you
                  know your team and environment is improving or not?

                  > Peter, maybe my problem is that I don't really see the contrast
                  > "prediction vs assessment" that you are outlining.

                  What I mean by that is, there are two interrelated concerns:

                  Prediction - the ability to look to the future and say, with high
                  confidence, that the new widgets will be in the system by end of June, and
                  the new security model will be done end of August.

                  Assessment - the ability to look to the past, compare it to today, and
                  discover trends whether you are getting more, or less, done as a team; the
                  ability to know whether something you did to improve productivity did, in
                  fact, improve productivity.


                  The problem is that the notion of "amount of work/effort" is fundamentally
                  vague and is always going to imply some level of subjectivity.

                  The gummybear style assumes that if people start with some notion of
                  "work unit" (ideal day, whatever), and try to make the team's notion of
                  what that unit is agree amongs each other, that you have enough acuracy to
                  track your project. You have a feedback loop: if your velocity is 5, then
                  22, then 11, then 0, then 30; and there are no outside factors that can
                  account for that, you pretty much know your gummybears are bogus.

                  The "estimate real hours" style assumes that if you set up a feedback loop
                  that corrects peoples' gut-feel idea that "this will take 2 hours" with
                  how long it actually took, then people's gut-feel estimates of how long a
                  task is going to take will become increasingly more accurate. You have a
                  feedback loop: if the difference between actual and estimated time remains
                  wildly variable no matter what you do, you know your estimates are bogus.


                  Now, the interesting point for me is this: if a "estimate real hours" team
                  gets a task to estimate, then, whatever they do amongst themselves and in
                  the back of their heads when they estimate that task involves, to a large
                  extent, subjectively comparing "how much work is this, compared to how
                  much we could do in the past". But there is a feedback loop that tells
                  them how accurate their estimate was.

                  Why this is interesting to me can be seen by comparing two imaginary
                  teams:

                  Team A esitmates real hours. They have a velocity of 50 today and 50 six
                  months ago, but says: "oh, but we are twice as productive now because we
                  recon we were only doing half as much work then".

                  Team B estimates gummybears. They have a velocity of 20 gummybears today,
                  and 10 gummybears six months ago. So it is obvious that they are also
                  twice as productive.

                  The question is: is team B's notion that a gummybear today is as much work
                  as a gummybear used to be six months ago more or less accurate than team
                  A's notion that they are doing twice as much work?

                  It all boils down to fascinating questions like gummybear-drift and
                  whether you actually care what your productivity was six months ago or
                  not :-)

                  --
                  ,_
                  /_) /| /
                  / i e t e r / |/ a g e l
                  http://www.nagel.co.za
                • haralds@dsv.su.se
                  I am doing a study with XP at a company, and we are now in our first iteration. A problem that occurs is that every now and then panic tasks that must be
                  Message 8 of 17 , Jul 1 6:14 AM
                  • 0 Attachment
                    I am doing a study with XP at a company, and we are now in our first
                    iteration. A problem that occurs is that every now and then "panic tasks"
                    that must be solved come up, and some other tasks can not be done because
                    some engineer is waiting for some log files for instance. This affect our
                    planning. The solution now is that we assign "panic tasks" to some
                    engineer to solve them immediately. And if an engineer is waiting for some
                    input to complete a task, he is given another task to work on during the
                    time.
                    Does this seem like a good strategy? Anyone with a similar experience?


                    Regards
                    Harald
                  • Curtis Cooley
                    You can: a) estimate the panic task and negotiate with the customer to pull out the same amount of work. b) absorb the panic task into your velocity. I would
                    Message 9 of 17 , Jul 1 2:25 PM
                    • 0 Attachment
                      You can:

                      a) estimate the panic task and negotiate with the customer to pull out
                      the same amount of work.

                      b) absorb the panic task into your velocity.

                      I would have the blocked engineer either take the panic task or at least
                      pair on it since he has a stake in it's completion.

                      This is a kind of steering. Things come up that you won't be able to
                      predict. Get used to it. Embrace change. Once you realize this is
                      normal, you experience much less stress about change and how much you
                      are going to get done. One of my best XP experiences was when I realized
                      that I did not have to stress when the customer changed his mind. It was
                      very relieving and I could just get on with whatever the customer
                      wanted.

                      On Tue, 2003-07-01 at 06:14, haralds@... wrote:
                      > I am doing a study with XP at a company, and we are now in our first
                      > iteration. A problem that occurs is that every now and then "panic tasks"
                      > that must be solved come up, and some other tasks can not be done because
                      > some engineer is waiting for some log files for instance. This affect our
                      > planning. The solution now is that we assign "panic tasks" to some
                      > engineer to solve them immediately. And if an engineer is waiting for some
                      > input to complete a task, he is given another task to work on during the
                      > time.
                      > Does this seem like a good strategy? Anyone with a similar experience?
                      >
                      >
                      > Regards
                      > Harald
                      >
                      >
                      >
                      > 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/
                      >
                      --
                      ======================
                      Curtis R Cooley
                      RADSoft
                      Better software faster
                      curtis@...
                      ----------------------
                      Dr. Zoidberg: "Okay, so you're nonchalant, stop rubbing our noses in it.
                    • Piergiuliano Bossi
                      ... Right, but this is true whether you are using gummy bears, ideal time, actual time, etc. The real difference is that in terms of effort, actual time
                      Message 10 of 17 , Jul 1 11:47 PM
                      • 0 Attachment
                        Pieter Nagel wrote:

                        >On Sun, Jun 29, 2003 at 05:09:47PM +0200, Piergiuliano Bossi wrote:
                        >
                        >
                        >
                        >>Really? 1 hour is 1 hour. Period. Do you know anything more objective
                        >>than this?
                        >>
                        >>
                        >
                        >That I agree with.
                        >
                        >My point is that if you spent an hour today to create a new widget, and
                        >you spent an hour last month to add view-only permissions on a bank
                        >account, how do you know whether you were more productive than you were
                        >last month? Should you be happy that you got as much as an entire new
                        >widget done today, or should you be concerned that you could not do as
                        >much as last month?
                        >
                        >You decide, subjectively, whether the widget was more work than the
                        >bank account.
                        >

                        Right, but this is true whether you are using gummy bears, ideal time,
                        actual time, etc.
                        The real difference is that in terms of effort, actual time doesn't lie,
                        while ideal units are subjectives.

                        The not yet addressed challenge is to discover a way to measure
                        delivered value. Through ROI? SIP? Acceptance tests? Function points?
                        Something else?

                        >My concern is, if you have 50 pair-hours available per iteration, then, as
                        >your estimation abilities improve, your velocity should converge towards
                        >"we can do 50 hours worth of work per iteration". If you introduce a new
                        >variable in the environment (faster developer boxes, say) there should be
                        >a temporary spike or sag in your estimations - you discover that you can
                        >actually do 55 hours worth of work now. But as you begin to take the new
                        >boxes into account in your estimations, you again converge back to
                        >estimating that you can do 50 hours worth of work per iteration.
                        >
                        >That is great if you are most concerned about having a high degree of
                        >confidence that what you estimate will take 2 iterations to complete,
                        >will, in fact, be done after 2 iterations. But if you want to compare your
                        >velocity of 50 to your the velocity of 50 you had a year ago - how do you
                        >know your team and environment is improving or not?
                        >

                        I think that the same is true using ideal time, with the aggravation of
                        having to deal with a subjective and volatile measure.
                        Am I wrong?

                        >>Peter, maybe my problem is that I don't really see the contrast
                        >>"prediction vs assessment" that you are outlining.
                        >>
                        >>
                        >
                        >What I mean by that is, there are two interrelated concerns:
                        >
                        >Prediction - the ability to look to the future and say, with high
                        >confidence, that the new widgets will be in the system by end of June, and
                        >the new security model will be done end of August.
                        >
                        >Assessment - the ability to look to the past, compare it to today, and
                        >discover trends whether you are getting more, or less, done as a team; the
                        >ability to know whether something you did to improve productivity did, in
                        >fact, improve productivity.
                        >

                        Now I think that I understand your point and why I didn't understand you
                        before: looking to the past & comparing it to today has nothing to deal
                        with productivity. You have only one way to measure productivity:
                        compare value delivered vs effort required. This brings back to the
                        issue that I have outlined at the beginning of this reply: how do you
                        measure value delivered to customers? Gummy bears, ideal time, actual
                        time have nothing to deal with value, but only with effort. But of
                        course, when you want to measure productivity you are only interested in
                        considering actual time, aren't you?

                        >The problem is that the notion of "amount of work/effort" is fundamentally
                        >vague and is always going to imply some level of subjectivity.
                        >
                        >The gummybear style assumes that if people start with some notion of
                        >"work unit" (ideal day, whatever), and try to make the team's notion of
                        >what that unit is agree amongs each other, that you have enough acuracy to
                        >track your project. You have a feedback loop: if your velocity is 5, then
                        >22, then 11, then 0, then 30; and there are no outside factors that can
                        >account for that, you pretty much know your gummybears are bogus.
                        >
                        >The "estimate real hours" style assumes that if you set up a feedback loop
                        >that corrects peoples' gut-feel idea that "this will take 2 hours" with
                        >how long it actually took, then people's gut-feel estimates of how long a
                        >task is going to take will become increasingly more accurate. You have a
                        >feedback loop: if the difference between actual and estimated time remains
                        >wildly variable no matter what you do, you know your estimates are bogus.
                        >
                        >
                        >Now, the interesting point for me is this: if a "estimate real hours" team
                        >gets a task to estimate, then, whatever they do amongst themselves and in
                        >the back of their heads when they estimate that task involves, to a large
                        >extent, subjectively comparing "how much work is this, compared to how
                        >much we could do in the past". But there is a feedback loop that tells
                        >them how accurate their estimate was.
                        >
                        >Why this is interesting to me can be seen by comparing two imaginary
                        >teams:
                        >
                        >Team A esitmates real hours. They have a velocity of 50 today and 50 six
                        >months ago, but says: "oh, but we are twice as productive now because we
                        >recon we were only doing half as much work then".
                        >

                        I think you have misunderstood the velocity concept working with actual
                        time: you should consider only hours related to completed user stories,
                        not simply the overall sum. Therefore your velocity typically will vary,
                        often it will be less than expected, sometimes more. For example, if I
                        plan 5 stories with the following estimates / actuals (expressed in
                        pomodori, 1 pomodoro = 30' actual work of 1 pair) and status:

                        * WriteEmails 2 / 4 ==> completed
                        * FeedingCat 1 / 1 ==> completed
                        * PlayingWithKids 2 / 3 ==> completed
                        * WashingDishes 1 / 0
                        * Cooking 2 / 0

                        My velocity was 5, instead of 8 as I would hope from the planning game.
                        Is it understandable?

                        >Team B estimates gummybears. They have a velocity of 20 gummybears today,
                        >and 10 gummybears six months ago. So it is obvious that they are also
                        >twice as productive.
                        >

                        Not at all! And beware that doing statements like this may put you in a
                        dangerous situation. Productivity is a completely different beast.
                        You should ask yourself if your way to measure gummybears is the same as
                        6 months ago. It is really difficult to believe that it is the same.
                        Eventually you have never re-estimated stories in 6 months (shame on
                        you!): even in this case it only tells you that now it requires less
                        (ideal) effort to develop (ideally) comparable stories, which in turn
                        tells you nothing about the value you produce for your customer. Too
                        many ideal factors, too much bias.

                        >
                        >The question is: is team B's notion that a gummybear today is as much work
                        >as a gummybear used to be six months ago more or less accurate than team
                        >A's notion that they are doing twice as much work?
                        >
                        >It all boils down to fascinating questions like gummybear-drift and
                        >whether you actually care what your productivity was six months ago or
                        >not :-)
                        >

                        How can teams A & B really say: "we are twice as productive"? There is a
                        fundamental flaw in this assumption.
                        Again, productivity is a completely different issue and should be
                        addressed on the business value side.

                        Ciao, Giuliano




                        [Non-text portions of this message have been removed]
                      • haralds@dsv.su.se
                        yes, thank you for the advice. Harald
                        Message 11 of 17 , Jul 2 1:13 AM
                        • 0 Attachment
                          yes, thank you for the advice.

                          Harald

                          > You can:
                          >
                          > a) estimate the panic task and negotiate with the customer to pull out
                          > the same amount of work.
                          >
                          > b) absorb the panic task into your velocity.
                          >
                          > I would have the blocked engineer either take the panic task or at
                          > least pair on it since he has a stake in it's completion.
                          >
                          > This is a kind of steering. Things come up that you won't be able to
                          > predict. Get used to it. Embrace change. Once you realize this is
                          > normal, you experience much less stress about change and how much you
                          > are going to get done. One of my best XP experiences was when I
                          > realized that I did not have to stress when the customer changed his
                          > mind. It was very relieving and I could just get on with whatever the
                          > customer
                          > wanted.
                          >
                          > On Tue, 2003-07-01 at 06:14, haralds@... wrote:
                          >> I am doing a study with XP at a company, and we are now in our first
                          >> iteration. A problem that occurs is that every now and then "panic
                          >> tasks" that must be solved come up, and some other tasks can not be
                          >> done because some engineer is waiting for some log files for instance.
                          >> This affect our planning. The solution now is that we assign "panic
                          >> tasks" to some engineer to solve them immediately. And if an engineer
                          >> is waiting for some input to complete a task, he is given another task
                          >> to work on during the time.
                          >> Does this seem like a good strategy? Anyone with a similar experience?
                          >>
                          >>
                          >> Regards
                          >> Harald
                          >>
                          >>
                          >>
                          >> 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/
                          >>
                          > --
                          > ======================
                          > Curtis R Cooley
                          > RADSoft
                          > Better software faster
                          > curtis@...
                          > ----------------------
                          > Dr. Zoidberg: "Okay, so you're nonchalant, stop rubbing our noses in
                          > it.
                          >
                          >
                          > 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/
                        • haralds@dsv.su.se
                          How does one handle the fact that people are sick sometimes? My initial idea is to register the amount of time the person has been sick, then reschedule his or
                          Message 12 of 17 , Jul 2 2:42 AM
                          • 0 Attachment
                            How does one handle the fact that people are sick sometimes? My initial
                            idea is to register the amount of time the person has been sick, then
                            reschedule his or her tasks based on how much time is left for that person
                            of the iteration, and maybe allocate some of the tasks on other people?

                            Regards
                            Harald



                            > I am doing a study with XP at a company, and we are now in our first
                            > iteration. A problem that occurs is that every now and then "panic
                            > tasks" that must be solved come up, and some other tasks can not be
                            > done because some engineer is waiting for some log files for instance.
                            > This affect our planning. The solution now is that we assign "panic
                            > tasks" to some engineer to solve them immediately. And if an engineer
                            > is waiting for some input to complete a task, he is given another task
                            > to work on during the time.
                            > Does this seem like a good strategy? Anyone with a similar experience?
                            >
                            >
                            > Regards
                            > Harald
                            >
                            >
                            >
                            > 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
                            ... What would happen if you considered stories and tasks to be team responsibilities, not individual or manager responsibilities? Ron Jeffries
                            Message 13 of 17 , Jul 2 3:20 AM
                            • 0 Attachment
                              On Wednesday, July 2, 2003, at 5:42:06 AM, haralds@... wrote:

                              > How does one handle the fact that people are sick sometimes? My initial
                              > idea is to register the amount of time the person has been sick, then
                              > reschedule his or her tasks based on how much time is left for that person
                              > of the iteration, and maybe allocate some of the tasks on other people?

                              What would happen if you considered stories and tasks to be team
                              responsibilities, not individual or manager responsibilities?

                              Ron Jeffries
                              www.XProgramming.com
                              The Great and Powerful Oz has spoken.
                            • haralds@dsv.su.se
                              good point.... so I´ll let them handle it then. Regards Harald
                              Message 14 of 17 , Jul 2 3:43 AM
                              • 0 Attachment
                                good point.... so I´ll let them handle it then.

                                Regards
                                Harald

                                > On Wednesday, July 2, 2003, at 5:42:06 AM, haralds@... wrote:
                                >
                                >> How does one handle the fact that people are sick sometimes? My
                                >> initial idea is to register the amount of time the person has been
                                >> sick, then reschedule his or her tasks based on how much time is left
                                >> for that person of the iteration, and maybe allocate some of the tasks
                                >> on other people?
                                >
                                > What would happen if you considered stories and tasks to be team
                                > responsibilities, not individual or manager responsibilities?
                                >
                                > Ron Jeffries
                                > www.XProgramming.com
                                > The Great and Powerful Oz has spoken.
                                >
                                >
                                > 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
                                ... Not that you shouldn t keep an eye on it, coach, remind, etc. ... ... Ron Jeffries www.XProgramming.com In times of stress, I like to turn to the wisdom of
                                Message 15 of 17 , Jul 2 4:02 AM
                                • 0 Attachment
                                  On Wednesday, July 2, 2003, at 6:43:45 AM, haralds@... wrote:

                                  > good point.... so I´ll let them handle it then.

                                  Not that you shouldn't keep an eye on it, coach, remind, etc. ...

                                  > Regards
                                  > Harald

                                  >> On Wednesday, July 2, 2003, at 5:42:06 AM, haralds@... wrote:
                                  >>
                                  >>> How does one handle the fact that people are sick sometimes? My
                                  >>> initial idea is to register the amount of time the person has been
                                  >>> sick, then reschedule his or her tasks based on how much time is left
                                  >>> for that person of the iteration, and maybe allocate some of the tasks
                                  >>> on other people?
                                  >>
                                  >> What would happen if you considered stories and tasks to be team
                                  >> responsibilities, not individual or manager responsibilities?



                                  Ron Jeffries
                                  www.XProgramming.com
                                  In times of stress, I like to turn to the wisdom of my Portuguese waitress,
                                  who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
                                  -- after Mark Vaughn, Autoweek.
                                • Pieter Nagel
                                  ... That s my point. Since effort is a vaguely-defined concept, any attempt to measure it will have subjectivity lurking somewhere. If you think you got rid
                                  Message 16 of 17 , Jul 2 5:49 PM
                                  • 0 Attachment
                                    On Wed, Jul 02, 2003 at 08:47:40AM +0200, Piergiuliano Bossi wrote:
                                    > Pieter Nagel wrote:

                                    > >You decide, subjectively, whether the widget was more work than the
                                    > >bank account.
                                    > >
                                    >
                                    > Right, but this is true whether you are using gummy bears, ideal time,
                                    > actual time, etc.

                                    That's my point. Since "effort" is a vaguely-defined concept, any attempt
                                    to measure it will have subjectivity lurking somewhere. If you think you
                                    got rid of it, you just swept it under a rug somewhere.

                                    > The not yet addressed challenge is to discover a way to measure
                                    > delivered value. Through ROI? SIP? Acceptance tests? Function points?
                                    > Something else?

                                    Your point seems to be that if we ignore customer value, measuring "work"
                                    done per time is a bad time to measure productivity because a team that is
                                    coding rocket-science proppellerheadish frameworks that do not support any
                                    customer requirement is just wasting time, not being productive. If so, I
                                    agree.

                                    However, I also feel that given the choice between tracking *nothing* on
                                    the one hand, and tracking "gummybears completed per iteration" on the
                                    other hand (with the assumption that the team is, in good faith, trying
                                    to deliver value and that) - I feel that is a better measure of
                                    productivity than not measuring it at all. Not ideal, but maybe good
                                    enough for many purposes.

                                    If a better technique for estimating customer value comes along, I'll jump
                                    at it. I agree with you that finding such a measure is a fascinating,
                                    valuable question. A lightweight measure that does it's job good enough
                                    without requiring too much effort for the benefit, I mean.

                                    > But of
                                    > course, when you want to measure productivity you are only interested in
                                    > considering actual time, aren't you?

                                    I think we keep missing each other. For me, there is not much value in
                                    knowing it took 34.7615 minutes to write:

                                    class SimpleAndClean:
                                    def doSomethingWellDefined(self):
                                    return whatever

                                    one day, and then the next day knowing it took 12.0543 minutes to write:

                                    class StupidAndUseless(GratuitousBaseClass1, GratuitousBaseClass2):
                                    def lookMaICanWriteSomeRealHairyCodeIfIWantTo(self):
                                    # copy and paste duplication
                                    # copy and paste duplication
                                    # copy and paste duplication

                                    the next day. Sure, I got the actual times down pat, but what's the real
                                    value of one versus the other? As I said, in the end, you have to
                                    subjectively compare them.

                                    > * WriteEmails 2 / 4 ==> completed
                                    > * FeedingCat 1 / 1 ==> completed
                                    > * PlayingWithKids 2 / 3 ==> completed
                                    > * WashingDishes 1 / 0
                                    > * Cooking 2 / 0
                                    >
                                    > My velocity was 5, instead of 8 as I would hope from the planning game.
                                    > Is it understandable?

                                    So at the end of the iteration you some up the estimated value of each
                                    completed task to get velocity? That's how gummybears work, too.

                                    My concern is, suppose for the next iteration you get similar tasks again.
                                    Since the team tries to get their estimates to match reality, they say:
                                    "Ok, we know writing emails actually takes 4 pomodori, so lets estimate
                                    them as such next time round."

                                    * WriteOtherEmails 4 / 4 ==> completed
                                    * FeedingCatAgain 1 / 1 ==> completed
                                    * PlayingWithKids 3 / 3 ==> completed
                                    * WashingDishes 1 / 0
                                    * Cooking 2 / 0

                                    For a velocity of 8, but same amount of work in same time.

                                    Actually, you are convincing me that estimating in terms of real hours
                                    could work, at least just as well as gummybears, for many purposes; maybe
                                    better, for other purposes. I'm trying to wrap my head around how it would
                                    pan out in practice.

                                    > You should ask yourself if your way to measure gummybears is the same as
                                    > 6 months ago.

                                    Well, the deeper question is why the heck do I even *care* about 6 months
                                    ago? :-)

                                    If one always keeps improving, and if you are better than last month, or
                                    at least not worse than last month - is that not "good enough"? Within a
                                    short 1/2 month timespan, gummybears tend to be "the same enough". Within
                                    a 6 month window, sure, they drift.

                                    But the same applies to estimating in real time: surely a team can know
                                    the value of the hours they spent last month vs this month "good enough"?

                                    > Again, productivity is a completely different issue and should be
                                    > addressed on the business value side.

                                    I agree, in the ideal.

                                    But don't gummybears *rougly* correlate to customer value delivered? Much
                                    much more so than, say, using the humidity of the development room as a
                                    rough estimate of productivity?

                                    --
                                    ,_
                                    /_) /| /
                                    / i e t e r / |/ a g e l
                                    http://www.nagel.co.za
                                  • Piergiuliano Bossi
                                    ... Ok! ... Peter, if you really think that gummybears map in any way to customer value that s ok for me, but I have to disagree, that is to say that
                                    Message 17 of 17 , Jul 5 9:14 AM
                                    • 0 Attachment
                                      Pieter Nagel wrote:

                                      >Your point seems to be that if we ignore customer value, measuring "work"
                                      >done per time is a bad time to measure productivity because a team that is
                                      >coding rocket-science proppellerheadish frameworks that do not support any
                                      >customer requirement is just wasting time, not being productive. If so, I
                                      >agree.
                                      >

                                      Ok!

                                      >However, I also feel that given the choice between tracking *nothing* on
                                      >the one hand, and tracking "gummybears completed per iteration" on the
                                      >other hand (with the assumption that the team is, in good faith, trying
                                      >to deliver value and that) - I feel that is a better measure of
                                      >productivity than not measuring it at all. Not ideal, but maybe good
                                      >enough for many purposes.
                                      >

                                      Peter, if you really think that gummybears map in any way to customer
                                      value that's ok for me, but I have to disagree, that is to say that
                                      gummybears, like actual time, measure only effort. You may use it to
                                      check your estimation accuracy (my position is that in this sense actual
                                      time works better), you may use it to plan work for the next iteration
                                      ==> they are perfect for this! But you should avoid using them trying to
                                      evaluate productivity.

                                      In order to evaluate productivity you need an independent, objective
                                      measure of value such that: P = V / E, where P is Productivity, V is
                                      Value and E is Effort.
                                      Ok, I know, put it this way is a little bit simplistic but it gives an idea.

                                      [snip]

                                      >So at the end of the iteration you some up the estimated value of each
                                      >completed task to get velocity? That's how gummybears work, too.
                                      >

                                      Exactly!

                                      >My concern is, suppose for the next iteration you get similar tasks again.
                                      >Since the team tries to get their estimates to match reality, they say:
                                      >"Ok, we know writing emails actually takes 4 pomodori, so lets estimate
                                      >them as such next time round."
                                      >
                                      > * WriteOtherEmails 4 / 4 ==> completed
                                      > * FeedingCatAgain 1 / 1 ==> completed
                                      > * PlayingWithKids 3 / 3 ==> completed
                                      > * WashingDishes 1 / 0
                                      > * Cooking 2 / 0
                                      >
                                      >For a velocity of 8, but same amount of work in same time.
                                      >
                                      Wrong: according to Yesterday's Weather now you should plan 5 story
                                      points, nothing more, but if you were working with pomodori you would
                                      have planned 8 pomodori again. Ok, this is another story.

                                      That's the rule of the game, as I understand it. Velocity & Yesterday's
                                      Weather are not there to express productivity in some way, but only to
                                      let you plan effectively.

                                      [snip]

                                      >But don't gummybears *rougly* correlate to customer value delivered? Much
                                      >much more so than, say, using the humidity of the development room as a
                                      >rough estimate of productivity?
                                      >

                                      I don't know, I have never measured productivity in terms of humidity of
                                      the development room. I fear that in my office it would be a disaster. :-)
                                      I think that gummybears *ROUGHLY* correlate to complexity, that is to
                                      say to effort.

                                      Ciao, Giuliano



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