I recently read: User Stories Applied: For Agile Software Development
I recommend it if you can get it for cheap. It did have a large amount of good information, but it did have a whole lot of fluff also.
In the essence of keeping things simple:
Good:
- Examples of good user stories.
- Good process ideas about how to “troll” for stories.
- Actual real example of developing user stories for a product and estimation.
Bad:
- Lots of pages filled with the same exact information.
- 10 completely blank pages at the end of the book.
What I learned:
I was trying to put all done criteria into a story, making it more like a requirements document. This was bad. It's better to have a small story that is used as a reminder to have a conversation later with the customer. Where does the “done criteria” go then? On the back of the card, or eventually into the story, but after talking with the customer, not during planning or before planning.
I have three questions I expect to be answered by the customer for me to be able to complete a story:
- What is the system currently doing that you want changed? (If this story's feature is completely missing, that is a valid answer)
- What do you want the system to do after the change is made?
- How can you prove right now that it is not already done?
After reading this book I have learned that these questions can be deferred after planning, they don't have to originally be in the story, but someone still needs to be able to answer them.
