RE: Managing Extreme Programming

George,

 

-----Original Message-----
From: Dinwiddie, George [mailto:[email protected]] 
Sent: Monday, January 13, 2003 9:30 AM
To: [email protected]
Subject: RE: [xpAdoption] Managing Extreme Programming

 

Dan, I don't agree.  I think I'm beginning to see how this works.
(Glen, please correct any mistakes in this description.  I know that I'm
over-simplifying, but I don't want to be incorrect.)

 

At the start of the project, you have a bunch of user stories, or some
other description of what the project intends to build.  You have some
idea of the value of this work.  Because the value of this work is
likely to be very difficult to determine via objective means, you're
very likely to use the simplifying assumption that it's worth what it
takes to produce it--else we wouldn't be doing it.  So, Budgeted Cost of
Work Scheduled (BCWS) is assumed to be the value of the completed work.

[>] using the "testable requirements" approach the value of the work is
the BCWS for entire iteration. The goal is to partition this accumulated
value into fine grained "values" for each testable requirement. The
"trick" is not to focus on the absolute value, but the relative value of
each deliverable increment (within the iteration) ahead of time to
measure progress to plan

In order to measure progress, you have to break the work up into smaller
pieces and distribute the value over these pieces.  Let's say for easy
visualization that you do this down to the level of the User Stories.
We take the total BCWS and divide it by the sum of all the "estimation
points" for the user stories to get a $/point value.  Then we can figure
the value of any User Story by simple multiplication.  I'd guess that
we'd want to do some other calculations to validate this $/point value
and make sure it's reasonable when look at from different angles.  There
may be other variations that don't assume that each point has the same
value, perhaps using the Business Value (showstopper, need,
nice-to-have) assigned to each story.

 

As development proceeds, User Stories are completed.  The value of these
completed stories ($/point * story points) are summed to give the
Budgeted Cost of Work Performed (BCWP).  Since we've made the
simplifying assumption that Budged Cost is equal to Value, this is also
our Earned Value.  We can also measure the Actual Cost of Work Performed
by adding up all the Pair Hours for the tasks to accomplish this story.
If Actual Cost > Budgeted Cost, that's a Bad Thing (negative Cost
Variance) and could trigger an investigation by somebody not involved in
the day-to-day activities of the project.

 

[>] The added value of EV in the XP world is to add to the "velocity"
metric the accrued value. That is use the BCWS as the target value
rather than yesterday's weather. Adding or deleting stories in EV means
scope changes so we are careful not to allow this except in special
circumstances. Our world here is not discovery design so this is rare.

If stories are added and deleted, or if estimations are changed, this
may change the BCWS.  If the change is of significant size, I'd expect
it to trigger a review of what's going on.  Is the project growing?  If
so, should other stories be deleted to keep the cost under control?
Were the initial estimates wrong and the original BCWS a fiction?  If
so, should the entire project charter be reexamined to ensure it's worth
the updated costs?

 

Adding or deleting stories should not change the ACWP or the BCWP.
Changing the estimations might change BCWP, e.g., if the fully-loaded $
cost per pair hour were changed to account for unexpected overhead
costs.

[>] but is does skew CPI/SPI so this should be avoided

I can see the value of using EV to manage from a distance, from the
upper levels.  It provides a concise and consistent view of the projects
and gives early warning when the project is headed into the weeds.  The
enabling technology are the simplifying assumptions and estimates that
are made to reduce a project to these simple figures.  The difficulty is
in ensuring that these assumptions and estimates to not produce
fictional figures that obscure instead of illuminate.

[>] we use it at the lowest level in the project as well. Portfolios of
projects are rolled up as well using another tool and a "bull's eye"
chart. 

One way that figures are traditionally manipulated to obscure the real
conditions is in the "percent complete" estimation of a single "chunk of
work."  Glen is avoiding this by adapting the XP rule that a story is
either done or it isn't.  This, in turn, drives a need for using smaller
"chunks of work" than might be traditional.  XP User Stories are pretty
small chunks, and going to them increases the work of estimating cost
and value for each chunk.  It probably also increases the accuracy, for
the same reason it increases the accuracy of the programmer estimates.
It's easier to estimate small things.  Each estimation error is also
smaller, and the errors tend to cancel out when there are more of them.

[>] This is the purpose of "physical percent complete" computed by
EV...not more cooking the numbers - either the code meets the testable
requirements (100% value) or it doesn't (0% value).

 

How did I do, Glen?

[>] Ya wan'a join in our paper to DOE CIO conference and the SLC Agile
conference???

 

 - George

 

 .