Writing Scenarios: Part 1 Identification

I get many questions about writing scenarios, but writing scenarios in general is a four-step process: identifying the scenarios, prioritizing & estimating scenarios, authoring scenario narratives, and decomposing scenarios into tasks. This blog entry looks at the first of these categories of questions, identifying scenarios. We start by identifying our scenarios to ensure we create scenarios in an agile way. As we traverse all four parts of this subject, you will see how agile scenarios can be.

There are actually many ways to brainstorm scenarios. A simple way is to gather your customers in a room and brainstorm with them. However, there is a more methodical approach, which starts by having the customers define the goals of the system similar to the way that we define these goals in use case modeling [Miller 2001].

A scenario is a single path of customer execution through the system. We ideally want to create very thin paths that we can augment as we go through each iteration. There are the “sunny day” scenarios, which provide the shortest paths to success. For example, in an online DVD rental system, the goals might be as shown in Figure 1.

Figure 1: The Scenario List

Each of these is potentially a scenario of the system. There are also exception scenarios where we look at things that affect these success scenarios. For example, we might have the maximum number of videos rented by a customer, and thus we might prohibit them from renting any more before returning videos.

When we are brainstorming scenarios, we don’t actually write the scenario narratives. Instead, we only use the names of the scenarios as placeholders to remind us that there is functionality to implement. We call these names scenario entries in the scenario list. A scenario entry is usually of the form, “goal : path” and might contain some notes on the differentiating factors or the thing that differentiates this scenario from the others. Usually the differentiating factors are clear from just reading the scenario name.

In the course of prioritizing & estimating our scenarios (described in Part 2), we may find that some of our scenarios are too big for a single iteration. To deal with this, we split these scenarios into smaller scenarios. These new scenarios should always provide customer value. For example, we might find that the sunny day scenario for “Rent DVD” is too big. In looking at this scenario, we can divide it into several smaller, customer-valued scenarios (as shown in Figure 2).

Figure 2: The brainstormed scenario list

Perhaps a simpler scenario than the “Rent DVD” scenario is to rent a single DVD. In this scenario, we search for a DVD by name and add it to our cart. Subsequent scenarios might allow renting multiple DVDs, add search options, and increment the number of DVDs rented with the appropriate new billing.

Comments

• Anonymous
  August 02, 2006
  The comment has been removed
• Anonymous
  August 02, 2006
  The comment has been removed
• Anonymous
  August 03, 2006
  The comment has been removed
• Anonymous
  August 16, 2006
  Remote Membership/Roles Management of ASP.NET 2.0 Applications Flickr-ing about with .NET VM Additions