Carl Bruiners Agile / IT Development Consultant

The anatomy of a good story

I often get asked what a 'good Story' looks like. Creating a great Story isn't as difficult as people think, nor does it require an understanding of the dark arts.

A good Story should include as much descriptive text to describe the story as needed, though you should resist the need to write down too much detail (http://carlbruiners.com/2011/06/amber-is-heathly-green-means-youve-over-cooked-it-and-red-means-we-havent-got-a-clue/) in favour of writing a concise paragraph or two. To help support this concise paragraph (or two) break it up into a bullet point list which acts as your Acceptance Criteria. Also remember to keep in mind I.N.V.E.S.T (Independent, Negotiable, Valuable, Estimable, Small and Testable).

The only difference between a User Story and a Story is that a User Story must written in business english; i.e something that most people wil be able to understand if they even have a small amount of knowledge about the product. A User Story is from perspective of the User (hence its obvious naming).

A vanilla Story though should start off by identifying the requesting role type;

• As a developer...
• As a tester...
• As a architect...
• As a documenter...

And though you should ideally keep the text as readable as possible, you could add in detail such as a method name or a class name for example. Remember that you should always include Acceptance Criteria for both Story types.

How do you qualify your stories? For User Stories get a BA to read the story, ask the Product Manager to skim over the backlog and always ask the team to review your stories (normally when being chosen for a Release Backlog, don't waste time defining stories that may never get played). As a double check (when the team Scrum Master) I often read the User Stories and if I can understand that unit of work then its a good indication that the story is defined clearly enough.