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

Re: [XP] Task Underestimation and Overestimation

Expand Messages
  • Curt Coulter
    ... Absolutely, those points are lost because there is no partial completion . It s either a complete shippable unit of work, or missed. There is no error
    Message 1 of 135 , Feb 1, 2010
      On Mon, Feb 1, 2010 at 5:57 PM, Curtis Cooley <curtis.cooley@...> wrote:
      > On Mon, Feb 1, 2010 at 2:43 PM, Curt Coulter <curt@...> wrote:
      > > 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.

      Absolutely, those points are lost because there is no 'partial
      completion'. It's either a complete shippable unit of work, or
      missed. There is no error in velocity, IMO, because I only care about
      the true velocity of work getting Done-Done.

      > 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.

      Presupposing and/or ensuring that every story has the same amount of
      effort wouldn't be something that would work for me.

    • 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
        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
        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

        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.