Today at IUE2009, I attended an excellent workshop led by Jan Moorman on scenario-based design and use cases.

My experience with use cases has been limited to what I’ve read from websites like AListApart.com, some select pages returned from Google searches, and snippets from books like Martin Fowler’s UML book and “Designing the Obvious” by Robert Hoekman, Jr. Based on what I’ve read, I have created UML diagrams for use cases and written out a few.

This limited knowledge may have been ideal for today’s workshop, because it gave me experience with which to make sense of the topic, while acknowledging that I have much to learn.

Jan led us through a number of different topics, but in general I remember focusing on these areas:

1. Using scenarios, drawn from observations of users, perhaps through contextual inquiry, to put context to a user’s experience.
2. Thinking of use cases as storytelling. (Possibly use storyboards in addition to textual stories.)
3. Use cases can exist at many different levels, as needed for the project
   1. Big picture of what is happening from a business goal perspective
   2. Use cases with brief details in simplified steps
   3. More detailed use cases which may include flow diagrams
   4. Use cases that include sections on data definitions and other functional requirements
4. Different examples of creating use cases that represent multiple systems and/or users, and use cases that map actors/goals to business logic to systems.

And what of use cases and Agile?

In addition, we spent some time discussing how use cases may fit into Agile methodologies, specifically Scrum, which we use at Covenant Eyes.

I thought Scrum and use cases would fit together well, but when we actually tried to speak to the similarities, it became tough. Seems strange, right? I mean, user stories are kind of like abbreviated use cases. Well, they are, sort of.

In spite of the user stories from Scrum, the tough part is that the language we use in Scrum is angled very differently than the language we use in UX, and specifically with use cases.

For instance, in Scrum we have a user story of “As a customer, I want to purchase the items I have in my shopping cart.” That user story could then become a product backlog item. We would then create a series of tasks needed to complete that backlog item. These tasks might range from finding information, like “Find out from accounting exactly what information we need to gather from customers” to coding tasks such as “Write Javascript to validate billing detail form” or “Write unit test to confirm that the shipping costs are applied to the bill.”

Note the language in the tasks. These tasks are worded for use by the developers in the Scrum. The presence of the user in these Scrum tasks is gone. It may be there if you read between the lines, but consciously, the work is at the nuts and bolts level now.

Use cases are worded on behalf of the actors, which are often our customers or users. They tend to be user-goal oriented, or exist a level-down from the goal nearer to the nuts-and-bolts level. The terminology is still geared closer to a user, though. For instance, “The customer sees shipping options with prices and selects an option.” You can see, as in that case, the user’s goals are still near at hand.

Benefit of use cases for Agile development

Based on observations from today’s seminar, it seems like one of the key reasons why we should do use cases in Agile development is that the process of hammering out use cases feeds the user stories and thereby the product backlog items. Without use cases, it is very easy to miss a big area of development, simply because we hadn’t considered it. Use cases forces some discipline into the process, and keeps the user’s goals front and center, along with the motivations of the business and developers.

Use cases can also be turned about to use as input into the planning of usability tests during design and development and acceptance tests during QA.

If we have a good batch of use cases, those can feed into development. Meanwhile, QA can receive those same use cases and begin writing acceptance tests. When development is ready, QA can step right in and run acceptance tests (which are based on use cases).

Now, what remains to be seen for us is how well we can integrate this valuable process of writing and using use cases into our Scrum process.

It’s been a long day! I hope to post more tomorrow about the session on field research.