Method 25 of 100: The Monetary Method

100 User Experience (UX) Design and Evaluation Methods for Your Toolkit

by Chauncey Wilson

The monetary method is an individual or group technique for prioritizing requirements by asking users and stakeholders to “buy” requirements from a “wish list” given a fixed (imaginary) budget of say “$1200”. Each requirement is described briefly, and a relative cost is associated with developing that feature.

This method for prioritizing requirements forces potential users to think carefully about what requirements are most critical. You can do this online without play money by just sending out the list and asking people to choose up to $1200 of items by checking cells on a questionnaire (and setting things up so no one can overspend).

Conte (2004) uses a variation on the monetary method as part of a rapid task analysis. Conte had a group of users write down, in 10 minutes, all the tasks that define their work on index cards - one task per card. The users then grouped the cards into different categories of work and listed task frequency (low, medium, high, really high) and task importance for each item (low, medium, high). Then the participants were given $1000 in fake $100 bills and everyone was asked to pin one or more of the $100 bills on the tasks they wanted the new product to support.

When to Use:
You can use the monetary method to:

• Prioritize requirements
• Learn what general sets of requirements, features, content, or other items provide the most value to different groups
• Get users to make clearer distinctions about what requirements are essential
• Make tough trade-offs when you need to drop features  

Strengths and Weaknesses:

+ Low cost, and minimal training

+ Fun and engaging

+ Can be conducted in person or online

+ The process of asking people to buy a set of requirements on a fixed budget provides a clear differentiation between important and “nice-to-have” requirements

+ Data analysis is simple

– You need a large sample of potential users

– Some companies worry about doing this online since it could reveal something about future products to competitors

– This method gets more complex if you have to consider dependent requirements

Procedure:

The basic monetary method procedure is:

1. Describe a small set of core requirements that will definitely go into a new version of software.  These “must have” requirements are guaranteed and not included in the list of requirements that users can buy. 
2. List a set of proposed requirements with clear descriptions and the relative costs to develop those features. For example, features that were easy to develop (e.g. 1-2 weeks) would cost $100, features that required a moderate development effort (e.g. 3-4 weeks) would cost $200, and features that were complex and difficult to develop (e.g. more than 4 weeks) would cost $300.  The figure below is a monetary method form that contains core requirements, instructions, and example requirements.
3. Brief the participants about the meaning of the relative costs.  For example, you might say that $100 requirements take 1-2 person-weeks to develop, $200 requirements take 2-4 person-weeks, and $300 requirements take more than 4 person-weeks of development effort.  
4. Give the participants play money and tell them that they could “buy” any combination of features as long as they don’t spend more than the allotted funds.  
5. Have users buy a requirement by circling (or choosing if online) the value in the Relative Cost column and put the money for that requirement aside. The amount of play money will depend on the number of features you present to the participants.  If you gave each participant $1200 in play funds, this means that they could buy four expensive features at $300 each, six medium priced $200 features, or various combinations of low, medium, and expensive features – as long as they don’t go over $1200. I generally give people enough money to buy three to five of the major features, though you can vary the amount of money to restrict the number of choices.  Another rough rule for assigning funds for buying requirements is that participants can’t buy more than about 30% or so of the total number of requirements with their funds.
6. Tabulate the results.

References:

Conte, L. (2004). The color of money – an agile technique for the prioritization of requirements. Proposal to the Boston UPA Miniconference. Natick, MA.

Gray, D., Brown, S., & Macanufo, J. (2010). Gamestorming: A playbook for innovators, rulebreakers, and changemakers.  There is a method in this book called the “$100 Test” that is similar to the monetary method.