|Please contact us for more information
Precision Quality Software, Inc.
Luke Hohmann at SD West 05
Luke Hohmann presented several very dynamic and fast-paced ways of eliciting requirements. The class involved role-playing (always an effective technique for enabling adult learning) in a way that involved various subsections of the audience in collaboratively applying Luke's innovative twelve techniques for requirements elicitation. The techniques all have intriguing names, such as "Speedboat" and "Give 'em a jacuzzi." Each technique is thoroughly explained on a colorful card with an interesting picture. Although the techniques make the process of requirements elicitation a lot more enjoyable (and thus a lot more effective) Luke explained how each approach is rooted in a set of solid psychological principles.
Luke asked us to get into a group of eight. He handed out blenders (no-kidding, real kitchen blenders) and role cards. The role cards helped reinforce that when working with real customers you have to think about "operational segmentation" -- different groups of users who use the products in different way -- as opposed to more traditional market segmentation techniques, which are about marketing and sales strategies. Since the names of these roles, and their purpose, was kept a secret so that the players could only infer the players' roles by observing their actions, I'll simply say that you should take this class so that you can experience the power of these different roles for yourself.
Each "customer" was handed a set of Monopoly money, and a list of as-yet-nonexistent features, each with a price tag. One player was assigned the role of product manager. He enthusiastically explained the rationale behind each feature, and consistent with their roles, the "customers" would embrace or oppose each feature. A feature would find its way into production when someone, or some group of customers, was willing to spend the money to fund the feature. Often, this required a pooling of resources between customers with very diverse interests.
The point of the game is to show how a requirements engineer can interact with a set of stakeholders so as to prioritize a set of features. The technique lets stakeholders show what they value, by letting them act on the basis of their basic value judgments. For example, in the course of normal requirements engineering, it's easy (and pretty meaningless) for a user to ask for a feature. It's much more meaningful when the user is enthusiastically arguing or negotiating with other users to ensure that this feature is included. By observing this behavior, the requirements engineer can identify deep sources of needs that apply to more than one class of users.
The monetary aspect makes the process even more precise, since it helps quantify the relative demand for each feature. Luke's techniques are so inspiring that we started using them on the first day that we were back in the office. The result: better requirements.
To read more about Luke's company and ideas, please visit his Web site at www.enthiosys.com
Luke Hohmann | Jeff Johnson
Granville (Randy) Miller | Dan Rawsthorne | Karl Wiegers
SD West 05 | Andre Co-Presents at SD West 05 | Audience Questions | Cartoon Story | Excellent Speakers