| So if the stories are loaded with hidden assumptions anyway, how do you find the ones that are potential problems? We described the dual view of the tester back in Chapter 2, and that's the foundation for the basic approach: think about the story first from the customer's viewpoint, then from the programmer's viewpoint, and identify the mismatches. You can go about this in a lot of ways. The process doesn't follow a strict linear progression; you tend to switch between viewpoints a lot and part of the time even gaze simultaneously from both. With a little experience you'll develop your own way of doing it, but for those who might have trouble getting started, we'll provide a step-by-step approach. It's helpful if the entire team is aware and supportive of this process, so get them involved and consider using this as a team exercise early in the project. However, this is not a drawn-out analysis you perform alone for days (or even hours) and then write up in some tome "for review." This is real-time analysis, done on the fly while working with the team on stories or during the release planning meeting. When we break this analysis down into steps, it looks as if it could be a lot of work. In fact, you'll do this in a minute or two for a given story and use it as the framework for targeting your questions in the discussion. While you go through this process, people will probably add notes to the story cards. You'll take your own notes as needed to remind you and the customer about these points when writing the acceptance tests. Here are the steps: -
Imagine you're the customer and think about how this story relates to your business. Think how the customer would answer the following questions and what those answers imply: What business problem is it solving? How does it solve the problem? How could the system implement the story and not solve the problem? Are there alternate solutions? Are there related problems? -
Now imagine yourself as a user of the system in this story. What would be the worst thing for you that could happen? How about the best thing? What would really irritate you? In what ways can you, as a user, "screw up"? How would you want the system to respond? How often will you be involved in this story? What are you likely to have just previously done, and what are you likely to do next? -
Forget the customer and the user. Imagine you're the programmer. Based on what's written in the story, what's the simplest and easiest way to implement it that could possibly work? -
Now it's time to be the tester. How likely is it that the simplest implementation will really solve the customer's business problem? Solve the related problems? Be the best solution? Avoid the user's worst-case scenario and achieve the best case? Integrate with the user's workflow? And so on. -
Whenever the answer to a question in step 4 is "Not very likely," imagine what additional information is needed to change the answer to "Likely." This is the type of hidden assumption you're seeking. During this process, you'll inevitably be asking lots of questions of both the customers and the programmers. You'll usually need to ask more than either group wants to answer, and you have limited time. Be disciplined and think things through first, so you get the maximum bang for the buck from each question. Take a look at the following example. Example 1 Our customer team (a regional telephone company) has defined the following story for a business-directory application: | Story: Create a screen that will allow the user to search on the Web for businesses by category of business and location. |
Step 1: Think about the system from the customer's view. Remember, you're going through these points quickly, writing notes on story cards as appropriate. I'm the customer. How does this relate to my business? The phone directory is crucial to the phone system for both residential customers and business customers. Business listings and advertisements in the directory generate revenue. What business problem is it solving? How does it solve it? It's expensive to print and distribute a hard-copy directory, so I don't do it very often. This means new businesses can't get in for a long time, and I can't charge them. Plus users of the directory can't find them, so they call a directory operator, which is an expensive service to maintain. The Web directory can be updated cheaply, so I can afford to do it daily. This allows me to add new listings and realize the revenue right away as well as reducing directory-operator staffing and costs. How could the system implement this and not solve the problem? If people don't use the system, the problem isn't solved. Businesses won't pay if they still have to wait for the hard copy, and I won't be able to reduce the number of operators. Are there alternate solutions? Are there related problems? Can't think of any alternate solutions. Finding residential listings is a similar problem, but I can't get any revenue from that. If it works out as expected with the business listings, may try residential next. Step 2: Think about the system from the user view. Keep up your momentum and skip over questions where you don't come up with ready answers. I'm a user, searching for a business. What are the worst and best things that can happen? What would really irritate me? Worst thing: I find a business and drive to its location, but it's been out of business for a month (should have called ahead!) Best thing: I find the business, click a few times, and accomplish my goal (purchase/order/complaint) online. Irritating: I'm looking for a particular business and know the name (approximately), but I can't just search on the name. I have to figure out how some idiot categorized it and search on that, then pick it out of a hundred others. (I get irritated just thinking about it!) How can I screw up? How should the system respond? Misspell something, like the category. The system should correct it for me or at least offer some correction alternatives. How often will I do this? What will I do before and after? Not very often. A couple of times a week at most that's how often I use the hard-copy phone directory. What I've done before will usually be completely unrelated. Next thing is probably to call the business (if I found one) or get out the hard copy (if I didn't). Step 3: Think about the system from the programmer's view for a moment. I'm the programmer. What's the simplest implementation that could possibly work? A form with text input fields for category and location; a Search button in the browser. A server program gets all the businesses that match the category and location from the database and sends a list in response. Each item in the list has the business name, address, and phone number. Step 4: Identify any mismatches between these views. How likely is the implementation to solve the business problem? Not very likely, because solving the problem requires a significant percentage of customers to use the system. Say 20% of 20 million twice a week. That's over a million uses a day, or about 13 per second. The system needs to handle a peak load of ten times that, about 130 uses per second. Since each use will probably involve more than one search (say 1.5) and each search will involve multiple server interactions (say 5: presenting the form, loading images, and so on), 130 uses per second means about 200 searches and 1,000 hits per second. This is a fairly high performance requirement that the simplest implementation is not likely to deliver. How likely is the implementation to solve the related problems (residential listings)? Not very likely, for the same reason, and even more so (more users, higher performance requirement). How likely is the implementation to avoid irritating the user? Respond appropriately to user mistakes? Not very likely, because the simplest implementation has no search by name and no way to narrow the search or otherwise deal with a large number of returned results. The software has no provision for a pulldown list; users have to type in the category. It doesn't offer potential spelling corrections if a category is misspelled. Step 5: Identify the assumptions. All your discussion up till now has led to this goal. Already we can see that so many requirements are coming to the fore, we'd need several stories to implement all this search functionality. That's just the kind of issue you want to come out of these release planning discussions. As you begin asking your questions about the assumptions, try to avoid phrasing them as direct questions right off the bat. You don't want to put words into someone's mouth. For instance, thinking back once more to the "missing door" story, the question "Will you want to close the old basement off from the new addition?" is better than "Do you want a door in that doorway?" The reason the former is better is that it allows the customer to make the connection himself: "Yes, the old area won't be finished, so I want to be able to close the door. It should match the doors upstairs, which are six-panel oak, and have the same kind of doorknob (antique brass)." When they make the connection themselves, customers often think of the details and share them with you. If you mention the door first, they may say yes, but they're likely to assume you know all about the door they have in mind, since you brought it up, and you have another set of hidden assumptions to worry about. Later on, when we get into iteration planning, we'll want to make it easier on customers (and programmers) by providing choices between alternatives whenever we can. At that point, we'll be narrowing down and focusing in on the details, but here we're still in the gathering phase, using open-ended questions more frequently. This discussion will produced better-defined stories and may bring up the need for new stories. Here are some of the questions you might want to ask in Example 1: Assumption 1 How many concurrent users do you expect for this in production? What kind of response time is required? What values for category searches and locations would produce tests representative of production use? Assumption 2 Is this story just for the category searches, or can the user search for a business by name? What do the search results look like? What sort of error handling is desired? Assumption 3 What fields should be on the screen? Which ones are required? What happens if a given search produces no results? What edits may be required for the fields? Once you've identified hidden assumptions, what do you do next? One way to proceed is just to write those assumptions right into the story, but this can have some disadvantages. We'll offer an alternative in the next chapter, which deals with defining high-level acceptance tests for the user stories. |
