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

Re: [XP] Estimation and load factor

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.