RE: 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.
 
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.
 
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.
 
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.
 
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.
 
How did I do, Glen?
 
 - George
 
 
 Dan Rawsthorne  said: 

IMHO, Expected Value makes no sense relative to XP. In order to calculate EV
you need to have a measure of the total value to measure against. In our
terms, you would need to have all the stories already, so that we could
measure "how much" of the system we have done (or plan to do this
iteration). In other words, calculating EV requires that you be able to say
something like "we've completed xx% of the total functionality" and that is
an impossibility in a pure (no BAUF) XP project. Of course, you could have
the case where the PHB has a spreadsheet as a result of a BAUF, but only
hands them to the Developers a little at a time...

 

Dan  ;-)

Dan Rawsthorne, PhD, Sr. Consultant
www.netobjectives.com <http://www.netobjectives.com> 
[email protected]
office: 425-641-0814

Net Objectives' vision is effective software development without suffering.
Our mission is to assist software development teams in accomplishing this
through a combination of training and mentoring. 

-----Original Message-----
From: Dinwiddie, George [mailto:[email protected]] 
Sent: Friday, January 10, 2003 2:31 PM
To: '[email protected]'
Subject: RE: [xpAdoption] Managing Extreme Programming

 

Glen,
> > So Earned Value is the sum of the values of all user 
> stories for which
> the
> > acceptance tests pass?
> 
> [>] The cumulative cost incurred to produce the delivered 
> product as well as the incremental costs for each deliverable 
> milestone (inch pebbles for the XP style project), is held in 
> the BCWP.

Do you mean the accumulated cost for what has been delivered plus the
estimated cost for that yet to be delivered?  If not, please restate this
sentence as it's unclear to me.

> A key pillar of EV is that the PM knows at all times what 
> percentage of the physical work has been accomplished, the 
> percent complete, as related to the total job.
> 
> The emphasis is on "physical" percentage complete, not the 
> percent of hours, or percent of stories -- unless each storey 
> and each hour produces the same "value."

I can see that each story has a "value" (what it's worth to the customer)
and each story has a "cost" (what it takes to produce the system that
supports it), but what is this "physical" dimension?

> > That's reasonable, but we need a dictionary to translate between the
> two
> > languages--in both directions.
> 
> [>] For EV it is EIA 748B and Quentin Fleming's book Earned 
> Value Project Management, Second Edition.

No, I mean a translation dictionary, such as a French-English/English-French
dictionary you'd use in language school.

> > I still don't understand your meaning of "digitize."  Do you mean
> "convert
> > to numbers?"  Do you mean "convert to a set of booleans?"
> 
> [>] It's a metaphor. (ah s@#t I sound like Ron). The metaphor 
> is to take what is considered in traditional PM methods an 
> analog process -- time passes so progress must be taking 
> place. Change this metaphor to one of "inch pebbles," "fine 
> grained" deliverables, say on daily or 3 day boundaries, and 
> "sample" the continuous S-curve. Either the sample produces a 
> 100% booked value for the increment or a 0% earned value. 
> 100% if it passes the requirements test, 0% if it does not. 
> The S-Curve (see the EV on one page) then looks like a large 
> number of fine grained step functions == digitized.

So it's just the notion of measurable accomplishment.  Right?

> > Is it assumed that the cost of development is equal to the value of
> that
> > which is developed?
> 
> [>] Ah, now you're on to something - maybe not. In that is 
> the case the task is Level of Effort == cost equals value. In 
> other cases the value may not equal the cost - cost variance 
> or schedule variance. The code component is say worth $100 
> (1/10 of a $1,000 function point). But it took $110 to get 
> it, so we have a Cost Variance (CV) of ($10), but it came in 
> on time so the SV is 0.

So how is the value estimated?  Looking at the chart, it appears that the
"value" is considered to be the amount that was budgeted for production.  In
other words, that code component you mention is worth $100 to the customer
just because it was estimated up front that it would cost $100 to produce
it.  If that's true, the Cost Variance devolves into a synonym for
Estimation Inaccuracy.

This troubles me, as I prefer some independent measure of the value of the
thing produced.  I can see, however, that for many projects, particularly
DOD ones, it would be very difficult to produce a value figure any other
way.  But it still troubles me.  In business the value might be more
objective, such as the Present Value of a stream of cost savings over the
expected life of the product.

Am I on track here?

> > Can you express the dollar value of a completed User Story?  Or the
> dollar
> > value of a requirement in the Functional Specifications document?
> 
> [>] We've dollarized the individual story at the beginning of 
> the iteration. The same can be made for a specific 
> requirement or FP. Take a look at 
> http://www.testablerequirements.com/testablerequirements/index
<http://www.testablerequirements.com/testablerequirements/index> 
...htm for some background.

That's going to take more time than I have at the moment.  Can you suggest a
page in that matrix that contains the meat of the estimation of value for a
testable requirement (which I take to be roughly synonymous to a User
Story)?

- George




To unsubscribe from this group, send an email to:
[email protected]



Your use of Yahoo! Groups is subject to the Yahoo!
<http://docs.yahoo.com/info/terms/> Terms of Service. 





To unsubscribe from this group, send an email to:
[email protected]



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .