Alistair Cockburn On Use Cases Vs User Stories

Posted by Tahira Karim on 10 April 2013

Having recently attended the two-day ‘Use Cases to User Stories’ workshop with Dr Alistair Cockburn, I thought it would be great to share some of my insights and learnings with you.

For those of you unfamiliar with Dr Cockburn, he is the originator of Crystal Light methodology, a family of Agile methodologies that embodies the lightest and least intrusive set of rules that will get the project over the line. He was also responsible for designing the OO Methodology for IBM’S worldwide Consulting group which is still in use and is widely applied to Business Process Re-engineering. Alistair is known for initiating the agile movement in software development and was one of co-writers of the ‘Agile Manifesto’, and he also co-founded the International Consortium for Agile.

Alistair is every business analyst’s ‘hero’ and his book Writing Effective Use Cases has become many a BA’s trusted source. He is someone I that admire and look up to for all the ‘answers’ to my many questions, and he is the kind of ‘coach’ I like to have on hand to guide me when it comes to writing use cases. So I consider myself rather privileged and fortunate to have attended his March session in Wellington.


So what did I learn? In a nutshell, why on earth do we make the use case such a complex piece of work? Its beauty is in its simplicity. Alistair sums it up nicely: A use case is textual, does not describe any GUI or data formats, comprises of 3-9 steps in the main scenario, is easy to read, is written at user’s goal level, and is a record of decisions made.

I am definitely guilty of writing UC comprising up to 15 steps (if not more)! What about the sub-use cases we often have a habit of creating? We tend to write these laborious long winded steps that actually have no value. We create complexity and confusion by our own doing and then claim the programmer did not read the use case properly.

If there was one thing I learned from this session, it was the fact that simplicity, preciseness, and conciseness are the art to writing a good use case. I mean, there are the usual structure and format principles that we need to adhere to, but essentially – as Alistair points out - the use case is just a story. It describes scenarios of a user succeeding or failing to achieve a goal using an automated piece of computer software. That is all it is!


I must admit that my personal preference has always been for use cases over user stories and perhaps I do have a bias and have not given user stories the credit they deserve. This session certainly opened my mind to the endless possibilities for using user stories as a technique for articulating system requirements. I have seen how well it works on Jeff Patton’s story mapping board. I have been infused with a sense of excitement at the prospect of using these new techniques I have acquired.

The greatest value of Alistair’s workshop was recognising errors that have been committed on previous projects I was privy to. How many of you have written user stories that start with ‘As a system’??? There is no such user story; you cannot write a user story from a systems perspective. There simply is no value add for a system! In the past I have tended to prefer use cases, as my philosophy has always been that I am not writing requirements simply to make the lives of programmers easier. Whilst I acknowledge that programmers are one group who have a vested interest in my artefact, I think that the artefact I produce should ultimately satisfy the needs of the project team as a collective unit. For this reason, I believed that use cases are better equipped to satisfy this need. However, having attended this enlightening session, I am now much more receptive to the thought of using user stories on my future projects.

What I valued from Alistair’s session was that I learned that user stories and use cases are completely different beasts. Each has its own merits and demerits and they serve totally different purposes. A user story is really something that is ‘actionable’, it is a work piece. I love the way Alistair describes the user story as a ‘promise for conversation’, and the card represents an invitation to prompt the project team or business person. My word, have we ever used user stories in this manner? Certainly not on some of the projects that I’ve been involved in.

I leave you with this thought. In Alistair’s world there are no BAs! We are value managers and we use our discretionary powers to make decisions that affect design. To be quite honest, I am slowly warming towards the whole value manager idea, as I find it rather apt and intrinsically appealing.

Acknowledgement goes to Alistair Cockburn for references made to the course material and to the workshop discussions, which have been used in the writing of this post.