Every agile team is different. Team dynamics and synergy are key to a truly self-directed team, so every unique group of individuals will have to discover what works for them and what doesn’t. One thing on which most teams (regardless of how different they appear or behave) will agree, though, is that writing software specifications is hard. English is a notoriously imprecise language, and computers are meticulous to a fault; this combination is what makes requirements so difficult. The use of user stories and agile to combat this hardship is very effective, and Cohn does an excellent job of explaining these concepts.
The main idea behind user stories lies in the idea that a story represents a requirement, it doesn’t document it. The goal of a story is to encourage communication about what a feature is and how it should behave, not a treatise on the behavior that can be thrown over a wall to development. In the traditional software world, management will create a Product Marketing Document to define how they want every last feature to behave. Engineering will respond with a Functional Specification, which is a rewrite of the first document with a slightly different point of view. Development is then expected to go off for a year or so and create the product. Simple, right? Cohn discusses this approach, and sums it up with one of my favorite passages in the book: “Most of the times when I see two groups writing separate versions of essentially the same document I already know they are positioning themselves for the end-of-project blame sessions and for claiming to know the intent of the document. This type of silliness goes away with user stories. Along with the shift to conversations from documentation comes the freedom of knowing that nothing is final.” The phrase “nothing is final” frightens many executives with whom I’ve worked, but when you consider that all significant projects undergo changes during development (have you ever had a released application that exactly matched the original specification?) it really isn’t any different than reality, it just recognizes that change is inevitable and accounts for it.
Even if you are familiar with agile and user stories, this book is a great read. It is filled with examples both positive and negative and does an excellent job explaining not only what user stories are, but what they aren’t as well. These negative explanations in particular are quite valuable, as they compare and contrast many popular requirement gathering techniques such as Use Cases and IEEE 830. Looking at how these other approaches work helps clarify what the scope of user stories are supposed to be. I highly recommend this to agile teams, especially product managers and ScrumMasters.
Software requirements is a communication problem.
No comments:
Post a Comment