Ever since user stories were introduced to the world they have been compared to use cases. There has been a small war between the agilists promoting user stories and the “mainstream analysts” holding on to their use cases. But is all this rivalry really necessary?

When comparing use cases and user stories, they turn out to be different in every way:

• Use cases can be used as permanent documentation, User stories are thrown away at the end of the iteration
• Use cases are at the level of what the user is trying to achieve with the system, User stories are small enough to plan into an iteration and to iteratively and incrementally deliver value
• Use cases are a base for high level preliminary estimations, User stories are a base for development estimates

So to me they simply serve different purposes

 

Why do we need user stories?

User stories help you focus on developing small increments at a time allowing you to quickly receive feedback from users. By doing this:

• you only need to adapt a small amount of code in case users change their mind and
• users might realize the functionality that is shown already meets their needs and they don’t need everything they originally requested.

Why do we need use cases?

Use cases provide you with a high level overview of the goals a user can accomplish with the system. Having this overview will allow you to create user stories while always keeping in mind the big picture.

Use cases are often linked to waterfall development processes. But to me use cases are only waterfall if you use them in a waterfall way. You don’t need to specify use cases up front, define all possible aspects of a use case or collaborate with developers by handing over a document.

Use cases are only as waterfall as the mindset of the person using them

And if the requirements are clear to you, it will not cost you any additional time to specify a use case. If it is taking you a lot of time, you probably didn’t get the requirement well enough.

The intersection between use cases and user stories

Before user stories become user stories they are epics. Epics are usually the same size as use cases, but they evolve differently from this point on. Use cases are further detailed with descriptions, pre- and postconditions and maybe even a design. Epics however are split into smaller user stories, given some context from the user and extended with acceptance criteria.

So are user stories and use cases at war?

To me it only makes sense to combine them. This allows us to benefit from the strengths of each technique and to avoid their weaknesses. And this is how I believe it can be done in a just-in-time and just enough manner:

At the start of your project:

• You identify 80% of the use cases or epics. This way you have a high level overview of the functionalities the system will provide to the users.
• You identify the Minimum Viable Product (MVP), by identifying the necessary user stories.

When preparing an iteration:

• You specify acceptance criteria and, if necessary, some additional information such as a mock-up. You do this while keeping in mind the high level scope, minimising refactoring.
• Add a pre-and postcondition for the use case(s) covering the user story. In some cases, but I do believe this exceptional, it might be useful to create a use case design.

And now you have it all: incremental, iterative software delivery while taking into account the high level scope and a minimum of permanent documentation of the system.

(I haven’t mentioned aspects such as information and non functionals, not because I don’t find those crucial, but because this is not the focus of the post)

Like this Blog?

Then you're in for a treat! Visit Sarah Denayer's personal blog, which offers many more hours of excellent reading material!