Sorry, an error occurred while loading the content.

## Re: [XP] Task Underestimation and Overestimation

Expand Messages
• ... 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.

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

________________________________
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!