Estimating business value: adding Value poker and Dragons Den to the Agile toolkit

A common piece of advice heard in Agile circles is: “Prioritise by value. Do the highest value first.”
Sound advice, easy to say but perhaps harder to do.

And if you know me - or just read this blog regularly - you may have heard me say something like: “Estimate the benefit/value expected, measure what is actually delivered and feed this back to your decision making process: calibrate you benefit estimates, do more work where benefit is missing or change direction when it is not possible.”

I’m sure I could find more examples but I’m sure you know what I’m talking about: understand the benefit/value you expect to get - and possibly check it afterwards.

Easy really.

But there is a problem: How do you know what benefit/value is expected?

A good product manager or business analyst might be able to come up with some numbers. Good, but if you dig deep enough you’ll find assumptions or models in these figures which could be questionable. The better your analyst the deeper you will need to dig before any assumptions come to light.

As for teams who don’t have a product manager or business analyst, well, they aren’t even going to get that far before they find questionable assumptions.

Very often the expected benefit/value is a matter of conjecture and opinion.

So let me make a suggestion: Value poker.

This is a technique I’ve been using for a while and always teach it in my Agile for BAs courses. Whenever I mention it people get interested. To make it work I adapt a game-show format, specifically: Dragons Den, Sharks’ Tank if you are in the US.

Here is how you play…

Two teams.

One drawn from the people who are planning to build a product. This could be the entire development team, it could be just the product manager or business analyst with the product sponsor/champion. This team play the Entrepreneurs.

If need be this could be just one person (a product owner/business analysts/product manager) but it helps if there are two of them and if there is a whole team then bring them along too.

The second team is the Dragons/Sharks/Investors Team.

This team is probably a bigger. In a training session I usually use two teams from an earlier exercise where they have created user stories but in real life it is business managers from elsewhere in the business, perhaps product managers, analysts, sponsors and champions of other products. It could even be a high level committee - CEO, CFO, CTO, Sales, etc.

The Entrepreneurs come armed with a set of story cards - these could be in user story format, use case format or some other format, they could be epics or smaller. Whatever, the team need to believe each of these has business value.

Preferably I’d rather these cards did NOT have any effort estimates on them at this stage.
Then we set up a Dragons Den setting.

Next I ask the Entrepreneurs to pitch their product - the whole thing - to the Dragons. Usually one of the team who is a bit more entrepreneurial steps up. When the pitch is finished the dragons get to ask questions.

And we have a discussion back and forth.

Then, as moderator, I ask the Entrepreneurs for the lowest value item them have in their deck.
I take it from them and I invent a currency. This is usually named after the town I’m in, so I’ve invented Newcastle Shillings, Houston Dollars, Bath Spa Pounds or some such. Its imaginary, lets pretend I’m using London Dollars, L$.

I read out the card the Entrepreneurs gave me and make sure everyone understands what it is. If necessary the Dragons can ask some questions.

Then I write on the card L$10,000 - ten thousand London Dollars. I tell everyone about the imaginary currency and about London Dollars.

I then place the card in full view - on a magnetic whiteboard or blu-tacked to the wall, or somewhere.

I hand out the planning poker cards to the Dragons only and tell them the cards are now denominated in thousands of London Dollars. So a 1 card is worth L$1,000 and a 8 card is worth L$8,000, a 21 card is worth L$21,000 and so on.

And I ask the Entrepreneurs for the next card.

I take it, I read it out. I ask the Entrepreneurs if they want to add anything to what is written.

Then we take questions from the Dragons, and the discussion rolls.

After a while - sometimes a few minutes, sometimes a lot longer - I move to the vote, planning poker style.

I read the card out again and ask choose a card that indicates how many London Dollars this story is worth - relative to the L$10,000 card we already have.

I count down, 3, 2, 1 - show me!

And the Dragons hold up the cards. I average the answer and write the number on the story card. So, if I have a vote of 11, 21, 65 and 40 the value would be: 137/4 = L$34,000.

I usually don’t bother doing any discussion or re-voting, I just average - and I don’t care if the average is a number not on any planning poker card.

And we repeat - as a value estimate is assigned to one card we move to the next. Not every story needs to be estimated, the Entrepreneurs may decide to skip some once they see the results of previous rounds.

Entrepreneurs may write some new ones as conversations with Dragons reveals new ideas or prompts a rethink. Indeed one of the reasons I like to have more than one entrepreneur in the game is so that one can write new cards while the other is pitching and talking to the Dragons.

As each card is estimated it goes on the board with the others relative to the value assigned so everyone can see how the stories stack up.

People can really get into their role play, you can see some entrepreneurs really fighting for their product as the Dragons poke holes in the idea.

Sometimes - perhaps even most time - the conversations that occur as the game plays out are the most interesting bit. New features and functionality are brought to light. Sometimes the value the entrepreneurs see is not what the dragons see. Sometimes critical pieces of requirement or specification are discovered.

During the summer I played this game with a class in Louisiana, the entrepreneurs had created a set of stories around a food-truck locator app. Some of the stories related to the food-truck owner and some to a Hungry Jo. The entrepreneurs saw the value being on the food-truck owner side, so they emphasized this in their pitch and kept offering up stories abut the owner.

The dragons kept low-balling these stories, the entrepreneurs got frustrated and argued more, how the dragons didn’t realise what they saw.

At my promoting the entrepreneurs offered up a story about the Hungry Jo. To their surprise the dragons went high. This was the story the dragons saw value in.

Now you could say that it would be better to test the market - research or lean start-up - and I wouldn’t disagree but even if you do that it can be hard to put value behind stories. Plus, faced with 20 stories which one should you research or try first?

This approach applies wisdom of crowds. It gives you a starting point.

And as I just said, its just possible that the real value of the technique is not in the value it assigns to the cards - although that is useful - but in the conversation you have in the process.

Sure you end up with a fantasy valuation but you do have an idea of relative values, you do let stakeholders have their say, and you have some initial priorities. Much better than Must, Should, Could, etc. Potentially even better than 1, 2, 3, …

Maybe, just maybe, one day you might be able to see the value one story actually delivered - a jump in eyeballs, sales, donations or something. And with that you might be able to calculate what L$1 is worth.

Two final points before I end.

I try to keep effort estimates out of this. It is my (unproven) belief that if the dragons know the effort estimate on a card this will anchor their value estimate. I want value estimates to be made without reference to cost.

Second, a twist on this would be to revisit the story cards with a cost of delay dimension. So: value estimate the cards on the basis of “If you had this next month” then revisit then say “Now lets assume the cards aren’t ready for three months” and revote.

I haven’t had a chance to do that yet but I think it would be interesting.

Finally: if you get a chance to try this technique - or if you have done something similar already - please share, I’d love to heard what other people think of the technique and how it plays out elsewhere.