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

Re: [XP] Task Underestimation and Overestimation

Expand Messages
  • Curtis Cooley
    ... This is where you can get bogged down in accounting, but if I understand you correctly, your way has working getting done, but not accounted for. For
    Message 1 of 135 , Feb 1, 2010
    • 0 Attachment
      On Mon, Feb 1, 2010 at 2:43 PM, Curt Coulter <curt@...> wrote:

      >
      >
      > On Mon, Feb 1, 2010 at 5:27 PM, Steve Ropa <theropas@...<theropas%40q.com>>
      > wrote:
      >
      > >
      > >
      > > Honestly, I read it the same way Michael did. I have experienced the same
      > > discussion many times. "It's done, it just isn't tested. Should we just
      > call
      > > it done and catch it with the testers in the next iteration?" or some
      > > variant thereof.
      > >
      > It happens to us as well. If it's 'done', but not 'done-done', for any
      > reason, it's simply a failure to achieve that story. None of the points are
      > counted for the current sprint, and when it gets put on another sprint we
      > re-point it based on the size of the remaining work to get it to done-done.
      >

      This is where you can get bogged down in accounting, but if I understand you
      correctly, your way has working getting done, but not accounted for.

      For example:
      A 5 point story didn't get done-done, so no credit in the current iteration.
      Your velocity is the planned points, n, minus the 5 that didn't get
      done-done, so n-5.

      Next iteration you estimate what is left and come up with 1 point, so you
      schedule that. This means 4 points of work got done but not accounted for.
      An error in estimation has now caused an error in your velocity.

      I handle this by not estimating stories at all. Then, when a story doesn't
      get done, it is placed in the next iteration as a whole story. The error is
      now only 1.

      > --
      >
      Curtis Cooley
      curtis.cooley@...
      home:http://curtiscooley.com
      blog:http://ponderingobjectorienteddesign.blogspot.com
      ===============
      Leadership is a potent combination of strategy and character. But if you
      must be without one, be without the strategy.
      -- H. Norman Schwarzkopf


      [Non-text portions of this message have been removed]
    • Andrew Wall
      Not on a breadboard, but a previous boss of mine developed RF designs (approx 100-400MHz) in a christmas tree fashion over a copper board, which meant the
      Message 135 of 135 , Feb 27, 2010
      • 0 Attachment
        Not on a breadboard, but a previous boss of mine developed RF designs
        (approx 100-400MHz) in a 'christmas tree' fashion over a copper board, which
        meant the circuit designs were quite malleable. But, I agree, some RF
        technologies in the GHz and above range, I'm guessing, need 'final' hardware
        to be built to see if they work, which then gets thrown away once the next
        version has been tested, and so on.

        When I was designing analogue and digital circuits, I often wished for all
        components to be variable so I could tweak the values while the circuit was
        'running' and when it was right, write down all the numbers, rather than
        powering down, replacing one or more components, powering up, attaching
        probes again etc.

        Andrew Wall (aka quamrana)
        Still not doing XP


        "CHRIS BROWN" <knightstreet@...> wrote in message
        news:858825.11878.qm@......
        No RF (Radio) design that I know of can be developed on a breadboard.
        Technology has advanced a long way and maybe a spike would be carried out on
        a breadbord for a concept but some circuits just will not work on a
        breadboard.




        ________________________________
        From: George Dinwiddie <lists@...>
        To: extremeprogramming@yahoogroups.com
        Sent: Fri, February 5, 2010 7:59:19 PM
        Subject: Re: [XP] Task Underestimation and Overestimation


        Ron Jeffries wrote:
        > Hello, CHRIS. On Friday, February 5, 2010, at 9:36:15 AM, you
        > wrote:
        >
        >> What if you are designing hardware along with software as with
        >> many consumer products in the market? You can't design the
        >> hardware in an agile method as well, you can apply some of the
        >> practices but ultimately the circuit board has to be specified and
        >> created based on a set specification which is detailed early on in
        >> a project and in that way you have to 'look ahead'. The software
        >> that works in the hardware (the firmware) can be delivered in an
        >> agile manner but the hardware remains fixed thus constraining the
        >> software by the hardwares limitations.
        >
        > That's one way. It's no longer the only way.

        Actually, it never was. When I was doing hardware development, we used
        breadboards to develop hardware iteratively. Even PC boards were
        designed iteratively, as the first layout was unlikely to be shipped.

        - George

        --
        ------------ --------- --------- --------- --------- --------- -
        * George Dinwiddie * http://blog. gdinwiddie. com
        Software Development http://www.idiacomp uting.com
        Consultant and Coach http://www.agilemar yland.org
        ------------ --------- --------- --------- --------- --------- -





        __________________________________________________________________
        The new Internet Explorer´┐Ż 8 - Faster, safer, easier. Optimized for Yahoo!
        Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

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