Can I still use a use case on my agile project – even if the cool kids don’t use them anymore?

I have been told that use cases are very old fashioned now and that all the cool people have moved onto agile user stories.

But I am old school and I still like to pull the old approaches out every now and then and take them for a spin.

I found myself explaining use cases in both a lecture (where the company wanted me to explain them to the BA teams) and a small team where people had been doing use case diagrams but not really use cases. Then I got asked in a BA course – “do you use stories for agile projects and use cases for waterfall ones?”

My answer was “it depends – probably just ask the BA”. But the student responded that she was a BA and that all the other cool BA’s would make fun of her if she wore the wrong clothes to school or used the wrong tool on the wrong project.

I said that use cases were great on all projects and started to explain how much I like them. But as I started talking, people looked at me as though I was recommending that they play 1980’s music in a dance club.

So, never good at taking a hint, I ignored their stares and explained from scratch …

A use case is just an example of how someone would use something (a case study of what happened where someone put something to use). They used to be the in-thing when the band ABBA was around because they come from Sweden.

I asked people what they knew about use cases and they started talking about UML and how extends and includes don’t sound very Swedish. I was saddened by this so I told them that the little stick figures and the circles are like the drummer in a band.

Use case diagrams hang out with use cases but they are not really use cases in their own right, they just think they are. Use cases help you ask better questions and explore your thinking – use case diagrams just provide a map of the use cases you want to talk about.

Getting really excited about complex use case diagrams is like a really long drum solo in the middle of an otherwise great song. The drummer has a great time but … hmm

I didn’t think my story was helping the class so I moved on.

Why is it good to talk about examples (use cases) rather than just listing the things we want (requirements)?

The answer is a bit of an anti-climax.

• You can talk about the characteristics of what you want in something new (I want a car that is red and that has functionality to speed up, slow down, turn corners and impress my friends); or
• You can get away from talking about the car to talking about your needs (As a car driver I want to be able to accelerate so I am not stuck in the same place all the time); or
• You can talk about the sorts of things you want to use the car for (I want to drive it to work and to go for a nice drive in the country every now and then).

So you can instinctively work out when to use a use case regardless of your experience with system modelling. A use case is good whenever you want to talk about how you want to use something.

Of course the use case in crowd formalised things with classic styles and methods. Just as any music movement or fashion trend developed its own rules. But now that use cases are old fashioned you don’t need to follow all the old rules … oh, actually you never did.

A use case can be as simple as “The driver (actor) has a goal of accelerating. He also has a goal of slowing down fast enough to not crash into things”.

You can then expand this into a brief description, called in use case jargon “a brief” or you can draw a diagram showing what you want (called in use case jargon “a diagram”). However I would probably not generate too many use cases for driving a car – I would probably just tell an engineer or car salesperson (depending on my budget I guess I might hire an engineer, though normally just go to a car salesperson) and explain what I want.

Use cases tend to get more detailed when you want to give a more detailed example of how you would use something – for example how I might imagine using my new wearable technology.

“If I could get some of that cool new wearable technology I would do heaps of things, for example I would wear it.”

Hmm … it appears that I don’t actually know what I would use wearable technology for. Maybe I need to understand it a little better before I buy some. This is where use cases are very useful – they focus the customer on how they would use something rather than whether it is cool.

For example, I understand how to use an ATM (Automatic Money giving Machine – or apparently they have lots of options so it is an Automatic Teller Machine)

1. I insert my card
2. The ATM asks for a PIN
3. I type my PIN
4. The ATM validates my PIN
5. The ATM displays some options
6. I select “give me money”
7. …..

This can be the best way to really explore my understanding of how to use something.

• Ideal for safety critical things where I want to also give examples of misadventures to be avoided;
• Really good for training and testing; and
• I believe really helpful for helping a user analyse their thinking about what they want.

But stories do that too don’t they? No I don’t think they do.

Stories don’t talk about how to use things. They are an example of what something is but not how I want to use it.

So why do people love stories? Well firstly it is 2014 and agile is all the rage – in a few years we will be talking user journeys, which are about what people are doing when they happen to be using our new toy. But in fact there is a reason that stories can be a lot better then use cases.

A story is typically written in the form “As a user I want a car so that I can drive it around”.

This pulls me away from how I will drive my car so that we can discuss why I want a car in the first place.

That is probably the right starting point for exploring the problem you are solving. Then we use more detailed stories to continue the conversation – “I want to accelerate” or “I want to open the door so I can get into the car”.

But is this approach really better than use cases?

People constantly tell me that stories are better because they delay thinking until we need to analyse things. For example we can prioritise stories before we spend too long analysing those that we will never actually build. But I claim you can do exactly the same thing with use cases – as long as you remember they are the tool and you are the craftsman.

The use case should not make a tool out of you and make you list millions of lines of examples for things you don’t think you will want – it should help you detail what you want in the level of detail that you decide is useful.

So we come back to the same question: Is the “story” approach really better than the “use case approach”. All the cool kids say it is.

Well – let me ask you two questions about our original car example:

• What examples of cars can you think of?
• What is a car an example of?

The first question has a limited number of answers and answering it involves deduction – analysing the problem by breaking it down. This is where use cases are so good.

The second question is different. It involves induction – expanding our thinking and then synthesizing an answer.

OK that is probably academic waffle but I like that sort of thing. Here is what it means in practice:

• If you use a use case then you are asking the customer how they want to do things, which facilitates great analysis of what they want to do;
• If you are using a story then you are asking a customer why they do things. This helps to focus on what they really want to achieve and to then prioritise their needs.

But once you do detailed stories you are getting into the construction of the car: “I want to open the door” is not really a how or a why question, it is a “what” question. The story has become a user requirement. We are no longer talking about how or why – just what we want the car to let me do. In fact I could just as well work with “When the driver pulls the door handle, the door must open, if the driver is allowed to open the door”.

So using stories is awesome – especially if you want to ask the critical question of “why” or “What is that an example of?” in order to go beyond the obvious solution the customer can think of in order to get to their real needs and to find cost effective but very useful solutions.

But use cases are also awesome – especially if you want to ask the critical questions of “how do you see that working?” or “what could possibly go wrong?”.

So rather than saying that you should use stories or tell stories with use cases I will say this …

Just ignore the cool crowd – don’t even decide which tool to use until you decide which questions you want to explore.

If you just want to ask “what do you want it to do?”, then use either, or just use requirements. But if you want to explore “why” or “how” questions then use whichever tool helps you explore them more effectively.