Fifty Quick Ideas to Improve your User Stories is another book from Gojko Adzic, a consultant and author that already produced some very good books on Agile requirements like Impact Mapping and Specification by Example. It goal is to help people involved with Agile requirements to improve their discussion with the stakeholders and the planning activities associated with user stories. This is clearly not a book for beginners on how to write user stories.
Fifty Quick Ideas to Improve your User Stories is structured around five user stories main activities: create, plan, discuss, split and manage iterative delivery. For each of the fifty tips about user stories contained in this book, there is an initial discussion about the concept, often with real life experience report. It is followed by two sections explaining the key benefits of the idea and how to make it work in practice. The book is easy to read as each idea is developed on 3-4 pages and mix user stories concepts with a practical vision gained from the authors’ extensive consulting experience in Agile software development projects. You can read this book sequentially or explore the ideas that are more appropriate for your current situation.
Fifty Quick Ideas to Improve your User Stories is a book that I will recommend to every software developer that has to elicit and manage requirements, whether they are user stories or not. The philosophy and the ideas contained in the book have value that goes far behind Agile software development.
Reference: Fifty Quick Ideas to Improve your User Stories, Gojko Adzic and David Evans, http://leanpub.com/50quickideas
Website: http://www.50quickideas.com/
Quotes
Letting go of a template, and trying out different formats, can help to shake up the discussion. This also helps to prevent fake stories. Following a template just for the sake of it is a great way to build a cargo cult. This is where stories such as ‘As a trader I want to trade because I want to trade’ come from, as well as ‘As a System I want the … report’.
The MoSCoW model, splitting features into Must have, Should have, Could have and Would like (really Won’t do), still seems to be the standard way of prioritising work items. One of the biggest problems with this model, which we constantly see working with clients, is that most of the items end up in the Must have category. Lots of teams suffer from the priority one paradox: the more stakeholders are pressed to identify highest priority items, the more scared they are to leave anything out of that category.
When business stakeholders aren’t experienced with iterative delivery, plans based on user stories often turn into streams of consciousness. Anything goes, stories even get reverse-engineered from feature ideas. A common result is that stakeholders feel that they constantly get small improvements, but the delivery team has no capability of achieving anything big.
Technical discussions are important, but shouldn’t necessarily happen at the same time as the conversation about the business perspective of a user story. Unless your business users are also programmers, split those two discussions into separate, more focused meetings