With traditional software development methods, someone, somewhere, writes a massive Book of requirements based on something, somehow, and to the extent the development team can make any sense of it, they write code that more-or-less matches what they think it says, or at least something that is actually possible to write, in contrast with what is described in the Book. At that point, all the management-level personnel involved with the project declare victory and take promotions. Then, over the course of dozens or hundreds of production support calls, the application is gradually hammered into a form that gives the user community some fraction of the value they had originally hoped for. With luck, something usable may materialize before the business opportunity has passed and it ceases to matter. This is a relatively easy process for developers, since they need not interact with any living human beings (LHBs) to take their project from requirements to deployment. They can just write code, which is their favorite thing to do (apart from having lunch, of course).
With agile software development methods, something both wonderful and terrifying occurs: The development team interacts directly with their customers. This is wonderful, because for the first time the developers can get an idea of what the customers really want. It is terrifying, because it requires the developers to learn a new skill set: How to interact with LHBs. Now, it so happens the nature of the universe is such that it is far easier for a software developer to learn to do business analysis than it is for a business analyst to learn to write software. Therefore, when these two roles collapse, as they inevitably must do if agile methods are to be employed to best effect, it falls to the software developers to learn to elicit requirements from their own customers.
Confronted with this reality for the first time, many developers react like deer caught in the glare of oncoming headlights. When reminded that they often interact with LHBs in other contexts besides software development projects, most developers relax a bit. They may have assumed that customers belonged to a peculiar and mysterious subset of LHBs that could only be understood by professional Business Analysts. After all, that has been the message put forth by the business analysis community, lo these many years. It is a relief to discover that an LHB is an LHB, and that the man behind the Business Analyst curtain has always been nothing more than a man behind a curtain. But immediately after exposing this Big Secret, the developers may not yet be too sure how to go from Point A — a face-to-face interview with a real customer — to Point B — an actionable User Story that accurately reflects the customer's needs.
Enter Keith Eades and his book, Solution Selling. It contains a Tool. We all know how dearly software developers love Tools. The Tool is called Nine Boxes. It is a Tool to help with interviewing Customers. It can help developers go from Point A to Point B. Here is what the Tool looks like:
Now let's switch to an informal second-person writing style, and pretend we're talking to developers.
The idea is to work your way through all nine boxes in the order in which they are numbered. When you have reached a mutual understanding with the Customer for the box you're in, you move to the next box. If you realize that there is more yet to understand, you move back one or more boxes. It's just that simple.
The boxes are arranged on a grid. This helps you organize the interview in a rational way, and also helps you remember everything you intended to talk about. What you're going to do is explore three aspects of the Customer's situation. These three aspects are represented by the columns of the grid.
First, you'll define the problem. This often helps the Customer understand the problem as much as it helps you. Second, you'll identify who is affected by the problem. Finally, you'll help each other understand what the Beautiful World of the Future will look like when the problem has finally gone away. Note that you aren't talking about any particular solution to the problem. You're just talking about how wonderful the world will be once the problem is solved.
To structure your exploration of each of these three aspects, the grid organizes portions of the interview into three types of questions. You begin the exploration of each aspect of the situation with open-ended questions designed to get the Customer to open up and tell you stories about what concerns him/her. Once you both feel you understand this, you move on to so-called Control questions. Based on what you learned from the open-ended questions, you will be able to formulate questions that quantify the problem - how much? how many? how often? etc. Finally, for each aspect of the situation, you will Confirm what you think you understood the Customer to say. This is an important step, because it often causes the Customer to think of something he/she didn't mention before. When that happens, or if the Customer says your summary of what he/she said is not correct, you simply move backward in the grid to the appropriate numbered square and clarify your mutual understanding.
Eventually, you will receive the Customer's affirmation that you have properly understood his/her explanation in square number 9. That's when the magic happens. The magic of the Nine Squares is that the information you gain from the interview can be applied directly to a User Story. Of course, you may need additional information besides this, but it's a huge help. Here's how the information maps to the typical User Story format, "As a <role> I want to <action> so that <value>."
And there's more. You know how hard it can be, sometimes, to get Customers to relate to the sort of information we call, "non-functional requirements?" Well, get a load of this:
Is that cool, or what?