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