RE: Managing Extreme Programming

IMHO, We have some serious mixing of apples and oranges here. Comments
imbedded below.

 

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: Monday, January 13, 2003 8: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.

 

Of course, having a BCWS means that you know what work you have
scheduled. It requires a scope. So, you have fixed budget and a fixed
scope up front in order to have a BCWS and do this kind of calculation.
Right away we know that this won't apply to XP, as XP assumes scope and
cost are independent variables, and the existence of a BCWS makes them
dependent on each other.

 

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.

 

This works if we have all the estimation points done up front, and we
have a stable velocity. There are two things that are being asumed:

*         you know how many estimation points there are in your project

*         you know how much time it "should" take to develop an
estimation point 

Neither is true. The first requires a BDUF, and the second requires
up-front knowledge of the velocity. Now you could tune your velocity so
that you know the second one, but that would (of necessity) change the
total number of points in your scope. Basically, you're trying to fix
all the variables at once. At least in XP, where the quality metric
isn't allowed to move.

 

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.

 

BTW, you are calculating XP's velocity here. That is, BCWP/(number of
iterations) = Velocity. Now by doing the division BCWP/ACWP we are
calculating (estimation points)/(work hour), and comparing it to some
constant (in this case, 1). This is a bad thing, as it assumes knowledge
of velocity up front.

 

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?

 

Actually, the BCWS is about money, not stories. What will change is your
story count and how much you want to spend. In other words, your
"required" velocity. If this changes to match your observed velocity,
you win. If your observed velocity is not fast enough, you cancel the
project. That's all it's really about here, IMHO.

 

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






Yahoo! Groups Sponsor



ADVERTISEMENT
 
<http://rd.yahoo.com/M=219695.2850578.4203976.1925585/D=egroupweb/S=1705
007207:HM/A=1400463/R=2/id=noscript/*http:/ad.doubleclick.net/clk;504627
9;7790548;y?http://www.ameritrade.com/o.cgi?a=cjx&o=roc&p=/offer/25.html
> 

 
<http://us.a1.yimg.com/us.yimg.com/a/am/ameritrade/120402_am_ban_off_x82
_x_300x250_6.gif> 


 
<http://us.adserver.yahoo.com/l?M=219695.2850578.4203976.1925585/D=egrou
pmail/S=:HM/A=1400463/rand=552943005> 


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.