Alistair Cockburn

The first thing I noticed is that this book is almost 25 years old. That’s an eternity in computer science, especially in a non-mathematical subject. It was written under the “waterfall” paradigm of software development, before agile took over most of the software engineering world. Instead of a page or two, waterfall specifications could require a binder of dozens, if not hundreds, of pages. This book describes “use cases” instead of the “user stories” that agile commends. Why show more is this book worth someone’s time? In other words, why did I choose to read it?

For two reasons. First, I’m a big fan of studying history. I’ll admit that I didn’t read every page closely in 2025, but I picked up on why agile design documents are organized a certain way. Knowing the history of the field allows me to understand the present better – and theoretically, be prepared for the future better.

Second, most of the literature I’ve read on user stories is overly simplistic. They don’t go into enough detail about what to choose and how. When communicating with my developers, I want to understand what possibilities can and cannot be communicated. To see the global set of options, I had to go back in time to when large design documents were the norm. Just like when someone reads Beowulf or The Canterbury Tales to understand how modern literature took its form, I can see all the glorious option that writing a user story encompasses.

Realistically, I don’t expect this book to be explored by a ton of people now. After all, it’s almost 25 years old! But thumbing through its pages enlightened me a bit as I start to communicate my ideas to the developers I work with. This was the greatest book on use cases in the waterfall era, written by the greatest expert on the subject, so I’m better primed to jump into agile practices and whatever era comes next. show less

One of the best all around books on agile software development I've read, for the intermediate to expert developer. You could call this book "the _Pragmatic Programmer" of agile, because its more a collection of tips and patterns that depend on context, as opposed to a one-size fits all methodology.

It emphasizes the value of small teams, colocation, on site customers, and the importance of people over any technique or technology. If your team can get the people and communication issues show more figured out, most technology issues will resolve themselves, or so Cockburn argues and his Crystal methodology recommends just that. From my experience, if you get a good, small talented team with a cooperative customer, you are well on your road to success. Things like choice of programming language or TDD vs test-after dev become non-issues if you have smart people who can work together and improve together as they work. show less

After reviewing every book I could find on use cases, this is the one that is making it into the office library. Part 1 addresses the different kinds of use case templates and the parts of those templates. Part 2 is a collection of topics related to use cases (including relating use cases to other types of requirements). Part 3 is an executive summary, or a review of the entire book.

The text was fun to read, but I expect I will get the most use from the downloadable Word template from the show more author's website and the list of pass/fail tests for the different template fields in the endpapers. show less

Overview of the how to manage a project using agile methodology. Clear, good easy read.