value poker

Benefits of Value Poker (2 of 2)

Last time I described how to estimate value on story cards. Now, lets talk benefits. Ultimately, the real value of this game is the conversations it creates. But along the way there are plenty of other benefits. The licensed dissent the game allows creates many insights and ideas.

The most obvious benefit of Value Poker is simply: at the end of the game you have a value based priority order. A team could, simply, take the highest value story and start work on it, deliver it and move on to the second highest. What could be better?

But actually, having value on the cards brings many other benefits and creates many options. For a start, having thought about the value of individual pieces ones perspective on the work to be done changes. What looked like a large chunk of work, a single monolithic product, might look like a stream of valuable features.

Value beats how-long

Moving the conversation away from “how long will it take” to “what value will it create” provides a whole new perspective. One which many have never appreciated before.

Rather than simply start at the highest value and work down conversations about the order of work become more than just technical “A depends on B.” One can think of value dependencies: customers can only get high value A they also have low value D. In which case, is D really a distinct thing, or is it part of A?

Both technical and business dependencies are exposed. All sides get to see why doing the most obvious thing might not be the right thing to do. The team might consider how else they may unlock the high value story without the need for the low value story. Maybe a subset of low-value D should be included in A. And maybe the rest of D isn’t worth doing.

Sometimes these insights only appear because teams are able to be adversarial. In most work environments people show respect. If a Product Leader ask for something few would openly say “That is pointless” or “Why would you do that?” but when playing Dragon’s Den people are allowed to openly question and think-outside-the-box. Indeed, since many have seen the game show people naturally fall into the roles and need little encouragement to challenge ideas. It becomes easy for a lowly engineer to say “I don’t see the market for this” or “Why would I buy this when product XYZ does that?”

Better than Word and PowerPoint

This in turn leads to two more benefits. First the Product Leaders need to be clear about what they want, why they want is and why they see value. They can’t hide behind PowerPoint charts or long business plans, they need to explain their point and defend their position in real-time. Product people are made to up their game.

People sometimes say to me “These two stories can’t be compared, they are like apples and lemons.” But money – even fantasy money – is a great leveller, it measures such asymmetric things. After all, the money you get paid for labouring over a hot keyboard each day can be used to pay your rent, buy a beer or take a holiday. How else could you compare the value of having a roof over your head with drinking beer?

This approach allows everyone involved to have a say. All the brain power in the room, all the knowledge, all the neurodiversity, can be exercised and used. New ideas, start flowing. Dragons and Product Leaders frequently see new or missing features which could be included enhancing innovation benefits.

In one game the Product Leads were proposing an app based around lunch time food trucks. They pitched story after story to the Dragons who gave it low value. The idea didn’t fly. After a quick consultation the entrepreneurs switched from pitching stories with benefit to food truck operators and pitched on Hungry Jo customers. The valuations rocketed. This is where the value was.

With all the discussion, the challenge, the reply, the adjustment something else happens: everyone builds a great shared understanding of what the product is supposed to do, how the entrepreneurs see it being used and who the target audience is. It becomes a great way to understand requirements and specification – far better than reading a dry document or even a PowerPoint presentation. This is why even playing this game with the engineering team can be highly rewarding.

Scheduling to maximise value

Believe it, or not, giving the stories a value can also help with scheduling – even without effort estimates. Once a story has a value one can ask “If this story is work 100,000bp today, what is it worth next month? in six months? in a year?” If the value never changes then the story can safely be postponed indefinitely because the value is always there. If on the other hand the values falls rapidly then the story needs doing soon. Sometimes, there might be more total value from doing a low value story (which will loose value soon) before doing a high value story which will hold its value.

Some readers will notice this is the start of a cost-of-delay conversation. One might now start to talk about Time-Value Profiles. Equally, only when you have value on individual work items can you really start doing cost-benefit, and biggest-bang-for-your-buck, analysis.

Finally, one big benefit I hope you’ve realised along the way: this game is a lot of fun. Not only does it help teams understand but it helps teams bond.

Want to play?

If you would like me to run this game for your company or your user group or meetup please get in touch.

Benefits of Value Poker (2 of 2) Read More »

Playing Value Poker in the Dagons’ Den

How often has someone on your team said “We should prioritise by business value” ?

How often have you heard someone say “We should do the biggest bang for the buck” ? – “lets find the quick wins which deliver the most value” or “Lets do the 20% that delivers 80% of the value.” The more studious people may call it “cost-benefit analysis” but it amounts to the same thing.

Yet while teams are quick to assign effort estimates – hours, days, story point or some other unit of measurement – very few teams add a value figure. When you think about it – and you only need a moment here – how can you do cost benefit analysis if you only know the cost? Without a number any attempt to “prioritise using business value” is likely to end up in decibel prioritisation, he who shouts loudest wins.

In fact, it is quite easy to estimate value in the same way we estimate effort. I’ve started including this in my product leader training workshops a few years ago and have seen game-changing results when used with clients. In one case estimating value allowed a client to remove more work in two hours than the team had delivered in two sprints.

Here I’ll describe how to play the game, the next post will describe the benefits and how to exploit values once you have them.

In the past I’ve improvised with value poker cards but the good folk at Agile Stationery have created a dedicated deck with 6 colour coded sets of cards.

I like to set the game up like the TV show Dragon’s Den – Shark’s Tank in the USA and other names in other countries. On TV four or five investor “Dragons” sit on one side of the room while a series of entrepreneurs (usually in pairs) pitch their product for investment. After the pitch the Dragons get to quiz the entrepreneurs and, after a little negotiation, may decide to invest in the product.

In my version the entrepreneurs are played by a pair of product people – these might be Product Managers, Product Owners, Business Analysts or someone else who works on the “what should be build” question. They start by pitching the product, or if the product exists, the goals of the next increment.

On the other side of the room sit my Dragons. These might be senior managers, other product leaders, actual customers or the engineering team who will build the product. Each role brings its own take on what is happening and adds value so don’t feel that you don’t have the right people.

As in the TV show the Dragon’s listen to the pitch and ask questions. Once everyone understands the product – or increment – is going to do the game differs a little from the TV show. Now the product leaders switch to pitching individuals stories – I say stories but these might be epics, features, functions, capabilities, or whatever the unit of work is that your team use. I’ll call them stories for now.

I take one of these stories – one I think is low value, preferably the lowest value. I hold it up and read it to everyone. Next I take a pen and write “10,000bp” on it, I tell everyone that this story is worth 10,000 business points – sometimes I invent a currency on the fly, perhaps the London Dollar or the Swedish Franc. It is important that the currency is not real, if it was people would argue about the valuation but it is the ratio between values on stories that is important not the actual number itself. Finally, I post the card where it can be clearly seen – on a wall, whiteboard or flip chart.

This done I hand each dragon a set of value poker cards. Each set contains about a dozen cards ranging in value from zero to one million.

Switching back to the entrepreneurs, one reads out the story, adds any description they think helps and the dragons reply with questions. When everyone has a good understanding of what the story is I ask the dragons to put a value on it.

As with planning poker dragons are asked to select up one playing card to indicate the value they put on the story but initially keep it secret. I count down, “3, 2, 1 – show ’em” – the dragons reveal their cards.

If there is a wide variation in votes – say three people vote around the 1,000bp mark and one 10,000bp we might have a discussion followed by a revote. More often than not I simply average the scores and write the value on the story card. For example, if four Dragons have voted 500, 1000, 2000 and 10,000 I might write “3,375bp” on the card. I then post the card on the wall relative to the others. So, a 3,375 card would be below a 10,000 card.

Usually I will impose a No Duplicate Values rule so if the next card also comes out at 3,375 I’ll ask the Dragons “Higher or lower?” We’ll adjust the value a little, say up 3,500 and place it higher.

We keep going through all the stories the entrepreneurs wish to value. Usually the second product leader will be selecting the stories they think will get a high value and feed them to the first. Sometimes they will write out new stories to cover ideas which have come up during the game play.

At the most basic levels the values suggest the order of work. Yet actually, as I’ll discuss next time, there are a lot of conversations that can now be had which were not possible before.

One time I did this exercise with a client team. The Product Lead from my team had already divided the stories into Must, Should and Could and the clients were asked to value only the Musts. Still, several stories came out with zero value. The Product Lead might have seen them as must haves but the client didn’t give them any value. Sadly, those stories represented more work than the engineering team had done in total over the last few sprints.

Next time I’ll write more about the benefit of putting value on your stories.

In addition, to Milton Keynes tomorrow I have tentative plans to run this session at events in London and Oxford later in the year, more details to follow.

And finally, if you like the idea go and get yourself some value poker cards – or, invite me to run the game for you, just get in touch.

Playing Value Poker in the Dagons’ Den Read More »

My customer wants a roadmap with dates

Another question from Oredev, one comes up a lot:

Q: What do I do when a customer wants to see a roadmap showing features with dates?

Selling features by the pound

First note, even getting into this position in the first place suggests problems. You are selling features rather than solving customer problems. While many software companies have found this a profitable line of business it is self-limiting and reduces long term ability to create value and generate revenue.

Working like this is akin to a vegetable shop selling potatoes. Customers come in with money and leave with potatoes. Every-time a customer walks in you need to have potatoes in stock. What happens is someone else offers potatoes for less? Or customers want rice?

Contrast this with the subscription model of meals companies like Hello Fresh. These companies don’t just sell potatoes, they solve a problem: how do I feed my family?

When you are selling features by the pound you are at the low end of the market. You have to keep selling features which means your product is destined to end up feature rich and unusable. You are always playing catch up with where the customer wants to be.

When you sell solutions you get ahead of your customers and show them how they can be better. Instead of selling them a hypothetical future sell them the quality product you have now.

This is also better for the engineering team. Sales are based on never ending feature requests everyone is on a treadmill.

So: stop selling features, sell solutions. To do this understand your customers, understand their problems, aim to sell solutions and get ahead of customers. Become their trusted partner with fees to match.

Let the customer drive

Back to today: you are probably following some form of backlog driven development (BLDD). So let us accept your organization could be better. What do you do in the meantime?

I would turn the question around. First ask the customers what they want to see, then ask them when they would like to have these things. Make this prioritisation conversation, A or B first? I might extend that conversation to value (“What benefit will this feature bring you? How much money will this save?”). Right after the prioritisation conversation or I might postpone value till later and I might use value poker to get handle on value.

Next I want to know their dates. Laugh when they say “Yesterday.” If need be explain you don’t have a time machine but recover and get them serious. If they keep insisting yesterday, now, tomorrow start slicing the work down. “We can’t give everything but maybe we can give you something small.”

More on, do you need this in the next 3 months? the next 6? next year? More specifically, what is the time-value profile? when is a feature worth the most money? and when does it become worthless?

Notice, I don’t want to suggest anything at this stage, I want to hear what they want.

Neither do I want to talk about dates based on effort estimates. The only thing that is certain about estimates is that they are wrong. Remember there is always more than one way to solve a problem. You now have their perfect roadmap.

Back at the office I would talk to engineering about what might be possible in the time frame the customer is asking for. See, I’m prepared to change the solution to meet the time scales.

Lean roadmap

All the time this is a “what if exercise.” There are only thing you can say for certain: what you are working on now and what you think you will work on next.

Some people call this a Lean Roadmap. This has 3 parts: what we are doing now, what we plan to do next and everything else.

Now if you have just one customer you can iterate on this process and effectively co-create a “what if” plan with the customer. But I still wouldn’t want to go further than now, next and everything else.

In contrast, if you have multiple customers you can still iterate but at some point you have to accept that you are going to upset them. The question is: how long do you wait before you break the bad news?

Now, you might be thinking “This is unrealistic, my management won’t buy this so I have no chance with my customers.”

In this answer I am being brutally honest: no schedule based on effort estimate dates will work – read Dear Customer. Putting out such a “roadmap” only delays reality and means people will be unhappy when dates are missed so let’s find a better way.

The Lean Roadmap (now, next, everything else) is one option.

What we really want are rich conversations with ourselves and our customers. From those conversations we can build understanding. We can say things like “In Q3 we plan to build a solution to the mobility problem.” You might even stand a chance of delivering such a plan. What you cannot say with any confidence is “In Q3 we plan to build epics 1234, 1249 and 2734.”

Creating those rich conversation means enriching the communication between engineering and customers, reducing intervening proxies (BA, Product Manager, Sales) and focusing on solutions and the benefits.

If that still sounds impossible then by all means list your features, write some random dates against them – don’t waste your time on pretending you can estimate unless you have the statistics to prove it. Hand that to your sales people, make sure you are paid regularly and accept you are working in a feature factory.


Subscribe to hear more from Allan Kelly and download Continuous Digital for free

My customer wants a roadmap with dates Read More »