November 05, 2013

Method 25 of 100: The Monetary Method

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:

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.

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.

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.

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.

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.

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.