The simplest measure of value

Jack also brought back this very simple equation from PO Certification.

Business value = Business visibility

Pragmatic Webinar

Steve Johnson presented a webinar on the Pragmatic Marketing site. It was worth the watch for quotes like:

"The real role of an Agile Project Manager is to force the project to leave the building despite the company's best efforts to prevent it."

And "I don't accept the premise of your question."

And this interesting formula: "Evidence * Impact = Priority"

More thoughts on valuation

Somewhere on the Tyner Blain blog it says this:
"Financial benefit is what we have to base our decisions on - both hard ROI and soft ROI data. We can measure cost data, and even forecast it - taking into account both fixed and variable costs. But if we use the wrong cost allocation strategy, we will make suboptimal decisions. The success of a requirement is based upon the ratio of value to costs."

Many streams of thought here...one conclusion is this; bad numbers are worse than no numbers. Maybe during the retro we should look back at the predictions and see how accurate we were, then apply that same percentage of correctness to future considerations.

Getting value faster

Here Tyner Blain blog says this "...no one is promoting that we maximize value - they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest"

I think this is the perspective we need to adopt for project valuation and why we should attempt to compare effort to value.

The rest of this article is excellent explanation of "velocity points." Better than the nebulous explanations that are dished out thru most Agile training

The Most Valuable

This is the introduction of the "grid" concept of prioritization. I found it here and here is part 2. Both articles contain lot's of other useful links.

The article says "If you're in a situation where prioritisation is straightforward and you have a single decisive product owner, you probably need to read no further."

This is the problem...when prioritizing multiple opportunities between several departments and managing stakeholder interests there needs to be an objective system. My goal is to avoid arbitrary decisions.

This is the best method I've seen because it's simple and visual.

Thoughts on Kano

Kano appears useless for prioritization, but might be useful for evaluating user satisfaction once the product is completed. Could be useful in a retrospective.

Here's an flash tutorial

Prioritization concepts

Read this it's really good. The blog entry starts by saying "The less we know about our client’s business, the more the requirements appear to be equivalent." All the more reason to aggressively depose stakeholders for specific value.

Although this article is about prioritizing features, it holds a lot of truth about prioritizing for any project. Including validating ROI over preference (let's keep it objective).

Visual cues

For visual representation chart value items in color.

Red (hot) to blue (cold) depending on executive support.

Or increase size if it meets strategic goals.

Two soft concepts

This may be an interesting article on ROI. ROI is both hard and soft. For an automation hard costs could be a savings of man hours...very calculable and very predictable. Soft ROI numbers should be discounted 60% to 90% according to Tom Pisello.

I jacked this from the Tyner Blain blog: It's where another soft concept is introduced, the concept of utility:
"Agile software proponent Kent Beck argues that people don’t know what they want when you ask them. There may be some scientific support for his argument based on some research cited by Barry Schwartz in The Paradox of Choice: Why More is Less. Schwartz references psychologist Daniel Kahneman’s studies of how people remember events, in an explanation of how people measure and assess utility. To sum up, here’s the flow of events: A person has an experience, and recognizes some satisfaction from it. This is known as experienced utility. This is the function that economists reference when defining the indifference curve. When remembering the event later, a person will remember incorrectly. Their memory of their level of satisfaction is their remembered utility. The problem is that the remembered utility never precisely matches the experienced utility. This poses an interesting problem. Even if we find people who have experienced exactly what we’re trying to analyze, they will be unable to correctly tell us how much satisfaction they derived in the past."

Here's the Tyner Blain blog conclusion:
"The value of a requirement or feature is a function of user satisfaction and the financial benefit of having that requirement implemented. The user satisfaction can not be quantified in advance because we have no framework for reliably predicting satisfaction - even based on past experiences. "

That is very interesting, as much as user's demand certain features without being able to provide a cost justification for their demands.