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

Re: [XP] Estimation and load factor

Expand Messages
  • 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 1 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 2 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 3 of 17 , Jul 1, 2003
        • 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 4 of 17 , Jul 1, 2003
          • 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 5 of 17 , Jul 1, 2003
            • 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 6 of 17 , Jul 2, 2003
              • 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 7 of 17 , Jul 2, 2003
                • 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 8 of 17 , Jul 2, 2003
                  • 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 9 of 17 , Jul 2, 2003
                    • 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 10 of 17 , Jul 2, 2003
                      • 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 11 of 17 , Jul 2, 2003
                        • 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 12 of 17 , Jul 5, 2003
                          • 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.