Value Poker

This tool assumes you are familiar with the technique of “Planning Poker” if not, take a glance at it first.

We talk a lot about value in Agile teams, delivering it, prioritising by it, measuring it, but value is a very abstract concept. People perceive value differently, they value different things, and have their own ways of reasoning about it. But if we are to prioritise our backlog based on ROI (cost vs value) then we need a common view of the value of items.

This is where Value Poker comes in!

Value Poker is a relative estimation technique, because we don’t actually need to know the exact value of items to prioritise them, just their value relative to the other items in our backlog.

First thing you will need is some baseline items, because to have a relative estimate, it needs to be relative to something. I suggest starting with recently completed backlog items that have already started to deliver some value.

Find the right people

Unlike in Planning Poker where the stakeholders are very clear (the team), this is not the case with Value Poker. Make sure you are involving the right stakeholders. There is no simple answer to who these people are, and it will vary from organisation to organisation, but my simple rule of thumb is find the 6-10 people who will have the most to say about how the backlog is prioritised.

Remember that the team building the product is as important a stakeholder as any other!

Agree on the time scale

Some things only create value over a longer period of time, some things diminish in value as time goes on. We need to agree on what type of time scale we are referring to when we are talking about the value of an item. Is it a week? Is it a year?

This will of course depend on your business context.

Find some 2’s

• Find an item that is close to the smallest value item in your backlog, not the smallest, but maybe second smallest.
• Everyone must agree that have a very good idea of the value of this item.
• Try to find something with very solid value motivation.
  • This saves us X hours per week.
  • This pays us X amount of money a week.
• Arbitrarily assign this it item a value of 2.

In Planning Poker we only have the development team, here we will be representing a lot of different facets of our organisation. Take the time to find several 2’s that represent these various standpoints and perspectives in your organisation.

You now have a baseline!

Find some 5’s

In order to confirm we have reached a baseline everyone agrees on, we want to find some more items we all agree of about double the value as the ones we just picked. The same rules as before apply:

• Everyone must agree that have a very good idea of the value of this item.
• Try to find something with very solid value motivation.
  • This saves us X hours per week.
  • This pays us X amount of money a week.

We have now confirmed our baseline!

Start Estimating

From this point on, it works just like Planning Poker.

• People each decide privately what they think the value of an item is.
• Everyone reveals their estimate at once.
  • If everyone agree we have the estimate.
  • If there is disagreement, we must motivate to each other the reasoning behind our estimates, and listen to others do the same.
• We repeat this process until the estimates converge or we decide to table the discussion.

We now have a common unit with which we can prioritise, ordering the backlog should now be trivial, right? Of course not, but it sure helps a lot now that we are all speaking about the same thing. Estimating value in this way of course lacks precision, but let’s be honest, was having no estimates very precise?

The true value in this activity is around the discussions that spawn as a result of it.

Value Poker helps to build consensus among those involved in the discussion, it helps us reveal our assumptions, opens the floor to discussions about the value of things, and provides us a metric to follow up. Just like Planning Poker!

Tips

• Take some time to discuss the different ways in which we perceive value; time saved, money in, quality, customer loyalty, etc.
• Do a quick “bubble sort” in the beginning of the discussion to make finding those 2’s and 5’s easier.
• Tell everyone the infinity card is only to be used in cases of “paradigm shifting” levels of value.
• Empower your Product Owner to make a decisions in cases where the people involved agree that they will never be able to reach a consensus.
  • Have everyone agree up front to abide by the Product Owners decision in these cases.
• Periodically re-establish your baselines as your knowledge of value in your organisation evolves.