We use “user stories” to document and manage requirements. Recently I provided training for one of our customers. Here’s some interesting resources we recommend.
What are user stories?
User stories are a short placeholder for a detailed conversation about requirements – deferring detail until needed. Stories represent customer value and are written in the customers’ terminology.
The general formula for a user story is: As a <type of user>, I want <some activity> so that <some reason>.
For example: “as a registered user, I want the system to warn if my password is easy to guess, so my account is harder to hack.”
Why use them?
I’ve seen studies which state incorrect requirements are the cause of 80% of software project failures. User stories are a simple, low-overhead way of documenting and managing requirements.
One of the trickiest parts of using user stories is breaking them down to the right size. Richard Lawrence has written an excellent pattern language to help you in this process.
There’s been an interesting debate on the value of acceptance testing.
We recommend the following books:
- User Stories Applied: Mike Cohn
- Agile Software Requirements: Dean Leffingwell
- Specification by Example: Gojko Adzic
- The Art of Agile Development: James Shore
Try Goshido, our collaboration & project management platform. Goshido is so flexible it can be used for Scrum, Lean and projects with traditional work-breakdown plans. It’s great for managing product roadmaps and requirements documented as user-stories.