Idea Reduction


When the idea-generation phase ends, it is time to initiate idea reduction. Several steps are involved.

Pruning Ideas

The first step is to "prune" those ideas that are not worthy of further investment by the group . The facilitator starts by visiting each idea briefly and asking for concurrence from the group that the idea is basically valid. There is no reason for any participant to be defensive or to claim authorship for any idea; any participant may support or refute any idea.


The presence of ideas that can be easily pruned is an indicator of a quality process. The absence of a fair number of wild and crazy ideas indicates that the participants were not thinking far enough "out of the box."

The facilitator asks the participants whether each idea is worthy of further consideration and then removes an invalid idea, but if there is any disagreement among the participants, the idea stays on the list. If participants find two sheets with the same idea, group them together on the wall. (This is usually preferable to removing one; its author may feel insulted.)

Grouping Ideas

It may be helpful during this process to start grouping similar ideas. Doing so is most effective when participants from the session volunteer to go to the wall and do the grouping. Related ideas are grouped together in regions of the walls. Name the groups of related ideas. For example, the groups might be labeled as follows :

  • New features

  • Performance issues

  • Enhancements to current features

  • User interface and ease-of-use issues

Instead, they may be specifically focused on capabilities of the system and the way they support various types of users. For example, in envisioning a new freight and delivery service, the features might be grouped by:

  • Package routing and tracking

  • Customer service

  • Marketing and sales

  • Web-based services

  • Billing

  • Transportation management

Idea generation can be reinitiated now for any one of these groups if the participants feel that the grouping process has spurred development of new ideas or that some area of key functionality has been left out.

Defining Features

At this point, it is important to take the time to write a short description of what the idea meant to the person who submitted it. This gives the contributor the opportunity to further describe the feature and helps ensure that the participants have a common understanding of the feature. This way, everyone understands what was meant by the idea, thus avoiding a fundamentally flawed prioritization process.

In this process, the facilitator walks through each idea that has not been pruned and asks the submitter to provide a one- sentence description. Table 12-1 gives some examples.

A welding robot feature, such as "automatic reweld," may already be sufficiently described, and no further work is required. It is important not to bog down in this process; it should take no longer than a few minutes per idea. You need capture only the essence of the idea.

Table 12-1. Examples of Feature Definitions

Application Context

Brainstormed Feature

Feature Definition

Home lighting automation

"Automatic lighting settings"

Homeowner can create preset time-based schedules for certain lighting events to happen, based on time of day.

Sales order entry system


Response time will be fast enough not to interfere with typical operations.

Defect tracking system

"Automatic notification"

All registered parties will be notified via e-mail when something has changed.

Prioritizing Ideas

In some situations, the generation of ideas is the only goal, and the process is then complete. However, in most settings, including the requirements workshop, it will be necessary to prioritize the ideas that remain after pruning. After all, no development team can do "everything that anybody can ever think of." Once the groupings have stabilized and been agreed to, it is time to move on to the next step. Again, a variety of techniques can be used; we'll describe two that we use routinely.

Cumulative Voting: The Hundred-Dollar Test

Results of cumulative voting:

Idea 1 $380

Idea 2 $200

Idea 3 $180

Idea 4 $140

Idea 5 . . .




Idea 27 . . .

This simple test is fun, fair, and easy to do. Each person is given $100 of "idea money" to be spent on "purchasing ideas." (You may even wish to add a kit of "idea bucks" to the workshop ticket inventory.) Each participant is asked to write on a sheet of paper how much of this money to spend on each idea. Then, after the participants have had a chance to vote, the facilitator tabulates the results and provides an order ranking. It may also be helpful to do a quick histogram of the result so participants can see the visual impact of their decisions.

This process is straightforward and usually works just great. However, you should be aware of the following caveats. First, it will work only once. You cannot use the same technique twice on the project, because once the results are known, participants will bias their input the next time around. For example, if you're a participant and your favorite feature is first on the list but your second-favorite feature didn't even get honorable mention, you may put all your money on the second feature. You're confident that other voters will see to it that your favorite feature still makes the cut.

Similarly, you may find it necessary to limit the amount anyone spends on one feature. Otherwise, a tricky participant, knowing full well that "other items" such as "Run faster" and "Easy to use" will make the cut to the top of the list, might put all of their money on "Runs on the Mac platform" and elevate it to a higher priority. On the other hand, you may wish to allow a higher limit, so long as you have the opportunity to understand where the really big votes came from. They may represent high-priority needs from a limited stakeholder community.

"Critical, Important, Useful" Categorization

A colleague taught us another prioritization technique that has also been very effective, especially with a small group of stakeholders or even just one stakeholder (such as when you need your boss's opinion of your priorities). In this technique, each participant is given a number of votes equal to the number of ideas, but each vote must be categorized "critical," "important," or "useful." The trick is that each stakeholder is given only one-third of the votes from each category; therefore, only one-third of the ideas can be considered critical.

  • Critical means indispensable , suggesting that a stakeholder would not be able to use a system without this feature. Without the feature, the system does not fulfill its primary mission or meet the market need.

  • Important means that there could be a significant loss of customer utility, perhaps even market share or revenue, or new customer segments served without the feature. If the important items don't get implemented, some users would not like the product and would not buy it.

  • Useful means nice to have. The feature makes life easier, makes the system more appealing or more fun, or delivers higher utility to some class of users.


With this scheme, all ideas that survived the pruning process get at least a "useful" vote, avoiding insult to those who submitted them.

In a larger group of participants, each item will have a mix of categories, but this is not really a problem. The facilitator has one more trick: Simply multiply "critical" votes times 9, "important" by 3, and "useful" by 1 and add up the score! This will tend to spread the results to heavily favor the "critical" votes, and thus every stakeholder's "critical" need will tend to bubble toward the top of the list.


Managing Software Requirements[c] A Use Case Approach
Managing Software Requirements[c] A Use Case Approach
ISBN: 032112247X
Year: 2003
Pages: 257 © 2008-2017.
If you may any questions please contact us: