Defining Scenarios

It's been a few days since I posted, mostly because I've done an enormous amount of writing this week between writing specs on our software project and a couple of long, heavy-thinking emails to my youngest brother, Ian. I've got a few things to post about, but I'll probably spread them out over the weekend.

This week has included a lot of writing down scenarios for how users will use the website we're developing. I'll just use the code name, Taranna, to refer to it from now on, since "the website we're developing" is so cumbersome. So a scenario is a way we describe a typical situation in which software is going to be used. By having a complete set of scenarios, you can capture all the action that'll be going on in the software and make sure you develop components to the software such that all those scenarios are covered.

In essence, scenarios are a step between raw requirements and functional specifications that make the requirements more readily understandable in human terms. I've never seen them used anywhere else I've worked, so Microsoft was my first exposure to the concept, but I think it's a pretty good one.

Unfortunately, I think a lot of people get badly hung up on scenarios and try to make them too detailed. For example, you might see something like this:

Bob is a systems administrator and wants to update his database server's settings to optimize the disk caching. He opens the Microsoft Awesome Console and performs a search to find the appropriate management setting tree. Finding the tree, he checks his watch and sees he has only five minutes before his leftover turkey, brought in to work in a plastic container he got at Walmart, will be done in the microwave down the hall. He initiates the settings wizard that analyzes the disk and determines optimal caching configuration. (etc.)

Seriously, I've seen scenarios that include stuff like the turkey thing. It can be entertaining, and I'm all for that, but the level of detail means that a lot of people never get finished with the scenarios and on to the next step of the work. Not everyone is cut out for the kind of near-fiction writing that seems to be desired by many.

Since I've had to write quite a few scenarios this week, I've taken to writing much shorter ones. For example,

A program administrator changes the address for a user that sent them an email with the correction.

Stuff like that will sometimes get feedback from others asking, for example, "What about other contact information?" While I think that it's effectively the same scenario, just another chunk of data that needs updating, I might change the above to:

A program administrator changes the address (or other PII) for a user that sent them an email with the correction.

(PII is "Personally Identifiable Information" and is very carefully protected at Microsoft, although that would be best discussed in a separate post.) So far, this seems to be working well, and I'm hoping my coworkers will start to follow suit and get less hung up on the scenario writing phase, thereby becoming more efficient and productive.