Business Value:

Host: Joe Little

Participants: Evan Campbell, Pascal Grugenberger, Stefan Ahrensdorf, Bill Wake, Paul Hodgetts, Stacia Broderick, Bob Schatz, Jim York (silent), Mark Pushinsky, M. Gupta and others.

Premise: Doing the right thing is more important than doing it right. Thus, Business Value topic is important.

Initial Concerns:

1. How does it correspond to backlog items?

2. How relates to ROI?

3. How does these relate to Business Value: less time, less known, market share

4. What does it mean for different org’s?

5. Problem ID’ing value on specific features – just someone’s opinion

6. How do business folk come up with numbers?

7. How to look at it: Is business case stuff good enough?

8. Peace, justice, love -- how affect business value or bottomline

Business Value = value as defined by the customer. This concept is promoted by Lean and by others.

§ Peace, justice, love

§ Product (better), time, price, experience

§ Quality

§ Safety

§ Risk

Business Value to shareholders is represented well by the following:

§ ROI

§ NPV (net present value, of discounted inflows and outflows)

§ PV (present value)

§ IRR (internal rate of return)

§ P&L : how the change affects P&L (top line or bottom line). See Mary Poppendieck.

Can we learn about business value during the course of the project? YES!

And we can continue to learn at any time. Understanding the mind of the customer (or having better insights about what assumptions to use in an NPV calc) is always difficult. (Yes, dev team, the product owner has difficult work too.) We can always help each other learn.

KANO Analysis

3 types of features:

§ Mandatory

§ Linear

§ Exciters

Way to determine:

§ Functional Question: How do you feel if this thing is present?

§ Dysfunctional Question: How do you feel if this thing is not present?

Mandatory Features: Some people have the view that mandatory features must be done, so why bother to understand their relative value? The problem is, most "mandatory" features can be done in a "thick" way or a "thin" way, so that increasing clarity on the relative values enables to dev team to use the 80/20 rule.

As in many situations, doing "the simplest thing that could possibly work" first is probably good advice.

What is the best conversation for a project?

§ Focus on what is the cost? Is it meeting cost expectations?

§ If costs vary some, how important is that really?

§ Or, what is the value? How is it meeting value expectations?

§ Or, look at value delivered mostly, but also consider costs?

Evaluate all benefits and all negatives with frequency during the course of a project. Assume you will learn about them as the project progresses…or at least that they will change.

Re-Evaluate your project portfolio against business value (and other benefits) and costs (and other negatives) with frequency. Decide which projects provide the best payback (including cost / opportunity lost of stopping a project).

For the product backlog: evaluate NUVs (nebulous units of value) and NUTs (nebulous units of time or cost) for each product backlog item (eg, story). Or perhaps group of items (eg, a theme). Allow the team to see the value of the piece they are working on.

Best to think of this as relative value (units are always relative anyway). Not worth the time to insist on precision; get enough accuracy as you need quickly.

Who should do NUVs? Product Owner and maybe others on the team; good conversation for all on the team, and they maybe can contribute a bit.

NUVs should include value, risk, opportunity cost, etc.

NUTs should include all negative stuff (maybe not just explicit costs).

The clearer you can be, the clearer the message to the dev team members. Thus, consider using dollars, which all can understand.

MUST check back after releases and after project that estimated NUVs and NUTs were "accurate enough" for decision-making.

Purposes:

1. Puts a brake on doing estimates to loosely if you know you will be checked later.

2. To get feedback to enable future estimates to be more accurate (but never expect anything close to precision).

Not necessary to be precise, just accurate enough for fair decision making.

 Create your own business wiki!HelpPublic, not yet premium Privacy Policy RSS