Skip to main content

“Show Me the Money” – Value-Driven Requirements!

Written by Robert Galen on . Posted in Articles.

For those of you who follow my posts you know that I’m incredibly passionate about the Agile Methods. I’m not some youngster who is blindly following the newest game in town. No, I have many scars related to other methods and approaches. However, I’ve discovered that they’re the best way to do software development and come away with a life.

I’ve been exposing some of the core practices or thinking models of agility here. Another that I’d like to share is the importance placed on business value when it comes to the Product Backlog (requirement lists).

Now trust me, I realize how hard it is to quantify true ROI on a per requirement basis. I think it’s virtually impossible to do that and it’s not what I’m implying. Instead though, what if we could get a group of key stakeholders together and have them analyze requirements or themes of requirements and assign some sort of relative business value? You could then use this valuation (priority in some sense) to guide your further refinement of the requirements, or to decide on UX efforts required, or to decide on where to invest more heavily in design and construction rigor. This sort of value-driven analysis might prove incredibly useful in guiding your work.

To be honest, the agile methods have surfaced just such a technique that I want to share. It’s called Planning Poker and here’s how it goes—

ShowMeTheMoney

Planning Poker

Mike Cohn originated the popular method that the agile methods use to estimate the size of user stories. (I’ve explained those in previous posts). Planning poker is a collaborative technique where team members get a series of cards marked with values that represent relative level of effort. A modified Fibonnaci series is normally used for the card values: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and infinity.

As each user story is examined and discussed, there comes a point where you want to “size it”. Each team member thinks about the size and then “votes” by selecting and throwing one of the cards down to represent the relative size.

Once thrown, the team discusses the high and low values and explores the why behind everyone’s selection. It’s a wonderful way to drive relevant discussion. The team continues to re-vote until they feel they have sufficiently narrowed the values into a uniform selection for level of effort. Then they move onto the next card and so on. So this works for estimates…

Value Poker

What if you use the base technique, but change up the cards? A very interesting and healthy extension to Planning Poker is Value Poker. While the basic technique remains the same, the setup is different. In this case, you place monetary values on each card, say: $500, $1,000, $5,000, $10,000, $20,000, $25,000, $50,000, $75,000, and $100,000. The list is really determined by your product and business domain and mapping relatively realistic cost/ROI amounts to the cards.

Once this is done, you view each user story (requirement) and try to apply a value to it. Again, team members throw their cards simultaneously and discuss the differences in value perspective. By recasting and further discussion, each story is assigned a value that relative to other stories and relative to the overall value that the product or project will deliver to the business.

In agile shops, this helps initially with prioritizing the work on the Product Backlog, in that business value drives prioritization and delivery flow.

However, I also find that these value discussions creep into all aspects of the project. From a BA perspective, it can help determine the true “Top 20%” of requirements that need your utmost care and attention. You might review these first, or use different tools and techniques to refine them, relative to the other requirements. You might review them with different sets of stakeholders, etc.

The point being, that valuation matters not only in the ordering of the work, but in all aspects of the project. For example, imagine you’re a tester and the top 10 of 100 requirements have a cumulative value of 67% of the overall project. Would that change how and what you tested? I suspect yes!

Value Poker Twists

There are several twists you can make to the technique.

One is to maintain different values based on the functional role of the team member. So you might have red cards for QA participants, blue cards for development participants, green cards for business facing participants, and yellow cards for BA participants.

This differentiation allows the entire team to quickly view distinctions in level of effort, or value in this case, from a constituency point of view. If, for example, the business values a user story at a very high level, but development does not, then some functional alignment discussion should occur.

Another twist is to give each valuation team member a fixed pool of funds to spend. This is my favorite approach, in that it encourages each member (project stakeholder) to not only consider relative value, but to spend their funds well (wisely) across the user story mix for the project.

It’s common to come out of sessions where the business has valued a small set of user stories quite highly. This information has then led to increased care, diligence, and quality on the part of the team when they get to defining and implementing that set of stories.

There something different about saying-

This is our #1 or highest priority feature and…..

versus

This is our #1 feature AND it provides 42% of our overall project valuation / ROI

Don’t you think?

Wrapping Up

I hope this discussion on value has perhaps opened you to another perspective when ordering and prioritizing your requirements…and work. Another positive side-effect of the technique is that it starts to skew our perspective more towards the business side. I think that’s a very healthy point of view.

So, poker anyone?

References:

Don’t forget to leave your comments below

Views: 30