I don't remember the first book I read on Extreme Programming, but I clearly remember two sensations: enthusiasm and confusion. Indeed, I felt there was something great in it, but I was unable to grasp many of the real practices they were talking about; it was like I was looking at them through a thick fog; user stories was one of those practices.
Many years have passed from that day, five, maybe more; my understanding of user stories expanded from a shape in the fog to a paper card. However, as many things you learn on the Net, some parts of the card were very clear, while other were still difficult to discern: for example I was not sure how big the card should have been or how many details I should have put on it. Less confusion and a little more enthusiasm.
Then my twin brother brought me this book, and told me "read it". And as I always do with everything he gives me to read, I put in on the shelf, and I forgot it. You may wonder why I do it; you're welcome: I wonder too.
Anyway, the book remained on the shelf for many months, then, I don't remember why, I took it again and started reading it; I've stopped and started many times, then, yesterday, thanks to a trip in train, I finished it.
Indeed, Mike Cohn did a very good job at explaining user stories; many of the questions I had about user stories found their answers here, and I think I'm better at using them, now; at least, Mike gave me all the tools I needed to improve, and not only in the user stories, but in the release and iteration planning as well, two practices intertwined with the former. There was even a nice example which gave me more insights on all the process.
As a matter of fact, I don't like how the book is written: each chapter is divided in an introduction, a core, a general summary, a summary of developer responsibilities, a summary of customer responsibilities, and some questions; this structure makes hard to read the book from the start to the end, as I like to do.
Nonetheless, I like when Mike tells us not what we should do, but what he did, and this happens most of time; he shows us real life examples, tells short and long anecdotes to explain and expand what he said just a paragraph before; in short, he does what is often forgotten: he shows as the theory of user stories becomes the practice of user stories. And I thank him for this.
When I was in high school, my grades in written italian were bad. Not so bad to become a problem, but bad nonetheless. The strange thing is that I loved to write. It was my favourite way to spend my free time.
But I was not able to write in good italian when I started high school. And I was still bad when I finished high school.
I've always wondered why. After reading this book, I understood: no one taught me. Ever.
Writing is a craft, with its rules and its tools, and this book shows you them; you still need to practice them: just because you know what you should do to drive does not make you a good driver; but knowing it allows you to practice, to acknowledge your mistakes, and to fix them.
This is a book for us all. We all have to write, be it an entry in a blog, a report for a manager, a mail to a friend, or a recipe of our favourite dish. Or, even, an howto on installing Linux on the latest notebook from Alienware. We all need to write.
Better then if we can learn to Write Well.