Since Scrum and XP are primarily used for production optimizationâI like to
say "Scrum is rhythmic experimentation to improve production"âwhy is it
surprising that the metrics we talk about in Scrum are cost metrics:
velocity, rework (aka bug count), communication (aka happiness)?
Scrum has abstracted away the very difficult task of feature valuation to
the Product Owner, so much so that most CSPO training focuses on "coping
with Scrum" and the mechanics of how to breakdown or refactor big stories
(such as story mapping).
Into this breach flew Lean Startup, thank goodness. And now we finally have
the value-based complex adaptive system converse of cost-based Scrum and
XP. "Occasional experimentation to improve value." I always wonder whether
rhythm would help Lean Startup.
Anyway, being solely focused on production cost, Scrum and XP are going to
continue dealing with cost improvements indefinitely. I think cognitively
it makes sense. Developers are ill-equipped to juggle questions of value,
and having them second guess Product Owner value choices is equivalent to a
Product Owner coming into a team and asserting that their estimates are
wrong. "Build it and they will come" is a constant danger for developers
trying to act like Product Owners (I have made my own stupid mistakes
building it for customers that didn't come).
We can, I think, demand that Product Owners do a better job, because most
are barely better than random developers (in fact, at least half the POs I
know are former developers) in estimating stakeholder value. But doing a
better job is a discipline in itself, a complex adaptive system of its own.
Finally (sorry for rambling), Ben Blanquera did some great work on
integrating value into backlogs at Progressive Medical. It wasn't exactly
what you are looking for: they didn't stick an NPV number on every PBI.
However, they did demand that POs name the source of value from a giant
revenue/expense taxonomy he and the CFO put together, for each PBI. This
forces the PO to think about value rather than "phone it in" as so many POs
do.
I think his work led me to start advocating "four part user stories", like
this:
As a (stakeholder),
I (can do something new or different),
So I (get some user value),
And so (sponsoring business) (gets some business value).
This fourth clause has the same effect: it forces the PO to think about and
assert a business value for the company paying to build the software. In
this modern services world, the user and the business sponsor are usually
different.
Hope this helps, or at least is interesting.
Dan
On Friday, May 8, 2015, Charles Bradley - Professional Scrum Trainer and
Post by Charles Bradley - Professional Scrum Trainer and Coach chuck-***@emailchuck.com [SCRUMDEVELOPMENT]I seem to remember quote similar to the following from a few years ago.
Anyone know who said it? (Maybe Agile 2012?)
(I already did several google searches myself -- to no avail)
(Speaking to the "business" I presume)
"If you're not going to estimate the value of features, then we're not
going to estimate the cost of features"
Anyone know who said it or where I can find the quote?
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com <http://www.scrumcrazy.com/>
--
Dan R. Greening â http://dan.greening.org http://linkedin.com/in/greening