You can use analytical methods to assign business value to a user story, of course, but another way is simple estimation. Allan Kelly describes an estimation exercise that combines the Scrum tool of planning poker with a TV show format to add some fun. You end up with enlightening conversation and revealed requirements.
You know this show. The investors line up on one side of the room—a few more than usual—and the entrepreneurs line up on the other side. One, calling himself the product owner, steps forward and opens his pitch.
“Our product is a website and app for food trucks. It allows food truck owners to find locations where they can park and sell food. They also can see what other competitors and cuisines there are at a location. For hungry customers, our app allows them to find a specific food truck’s location or cuisine and read reviews of trucks.”
No sooner has he finished than the investors start shooting questions at him: “How will you monetize the application? How many customers do you expect? Will it be available nationally? What about internationally? How will you ensure quality?”
Half the questions the product owner has ready answers for, but everyone can see he is improvising on others. As the questions slow, the host steps forward and hands each investor a set of cards. To most people these cards look funny: 0, 1, 2, 3, 5, 8, 13… but to software engineers, these cards are instantly recognizable.
The host holds up an index card he took from the entrepreneurs earlier. “This,” he says, “is your benchmark: one thousand American shillings. It’s a new currency; I don’t know the exchange rate right now, but we’ll find out.” He then reads from the card:
“As a food truck operator, I want to see all the registered food trucks in my area on a map so I can decide where to park at lunchtime.”
“Your cards,” he tells the investors, “are denominated in thousands of American shillings.” He holds up a poker card with the number 1 on it. “This card represents the thousand American shillings this story is worth.” He sticks the index card on the wall. The product owner reads from another index card:
“As a food truck operator, I want to know how many hungry customers visited a location yesterday, last week, and last month so I can see where there are lots of customers.”
Again the investors respond with a battery of questions, some technical, some business. After a few minutes the host moves the entrepreneurs to a vote. Each secretly selects a card to indicate the value they think the first user story has. “Three … two … one … play ’em!” calls the host, and they show their cards. The host averages the values while the investors quiz each other. “Nine thousand American shillings,” he announces, and writes “9,000 AS” on a card before pinning it to the wall above the first user story card.
The game plays on: The entrepreneurs pitch each user story, the investors query them, they vote on the value, and the host builds a list on the wall in value order. Sometimes the entrepreneurs write completely new stories as the conversation generates new ideas and immediately pitch them.
At the end of the exercise there is a value-based priority list on the wall and a pile of discarded stories on the floor—and everyone has a much better understanding of what they are building and little bits of requirements and specifications.
Estimating the Business Value of a User Story
You can use rational, analytical methods to assign business value to a user story, of course. But another way is simple estimation. After all, if estimation is good for effort, why not use it for value?
The exercise described above combines the Scrum tool of planning poker with a TV show format—I know it as Dragon’s Den and most American readers will know it as Shark Tank, but it is also known as Lion’s Den or Money Tigers.
The currency is a complete invention but adds some fun; combining a wisdom-of-crowds approach with a fantasy currency sidesteps the problems of using actual analysis and real money. Because the estimates are relative to each other, there is no claim of accuracy, only ordering. And because the estimates come from intuition and gut feeling, the technique is quick and disputes are handled face to face.
In a classroom setting I normally divide participants into teams, but in a real-world setting one could draw each group from those in the company who have investment and product knowledge. Surprisingly, the conversations follow similar patterns. Typical developers who know a lot of business language, when asked to role-play as investors, enjoy demonstrating their knowledge in questioning product owners.
While value estimates and priority are the most obvious outcomes from this process, it is perhaps the conversations and discussion the process encourages that can be the most interesting outcome. Put on the spot to pitch rather than deliver a dry business case, product owners become animated. Those playing investors are free from office etiquette and can critique and criticise proposed products and stories because they are role-playing.
And everyone has fun.
It isn’t necessary to value every card (although you could), because the entrepreneur team is making priority decisions as they go. Understandably, bigger, epic-type stories get bigger business valuations than smaller stories, so it perhaps makes sense to do this exercise early in the development before epics and stories get broken down in detail.
The Result: Prioritization and Conversation
These days I recommend every story have a value estimate attached before asking team members to assign effort estimates. The value estimate is good, but this technique also has other benefits. For a start, the conversation is incredible. The exercise is a form of war-gaming, with one side challenging the other. Assumptions get exposed, requirements expanded, specifications flushed out, opportunities identified, and stories junked.
At the end of the process the team has a first cut at prioritization by looking at the highest value. Of course, anyone can argue with the prioritization, but that discussion is itself valuable.
The spread of values makes it easy to slot another story into the sequence. And if something drops in value (priority), the whole backlog does not need renumbering.
More importantly, with a value written on the card in business points, teams can engage in meaningful cost-benefit analysis and trade-off.
A couple of hours playing your own version of Shark Tank can be very educational.
