RE: Managing Extreme Programming

Dan,

 

It's "earned" value not expected. And you only need to know the stories
for the iteration, which if you don't know at the beginning you're
hacking.

 

Glen B. Alleman 

 

-----Original Message-----
From: Dan Rawsthorne [mailto:[email protected]] 
Sent: Friday, January 10, 2003 6:08 PM
To: [email protected]
Subject: RE: [xpAdoption] Managing Extreme Programming

 

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
[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
..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! Terms of Service
<http://docs.yahoo.com/info/terms/> . 


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