A backlog of user stories is, in my opinion, the starting point of planning an iteration. Without a backlog, how would your development team know what they are supposed to be working on during the iteration?
I am not of the belief that writing stories happens in isolation. Story writing is the inclusion of the customer in the process of letting you know what they want to do as part of the application. Defining acceptance criteria for when those stories are complete is yet another component that I think is valuable to work on and complete before a story is "ready" to be worked on. Here are a number of the resources I have reviewed in the story writing process to define just what is in a story:
- What’s in a Story? (Dan North)
- Writing good user stories (Kelly Waters)
- Writing good user stories (David Churchville)
- The easy way to writing good user stories (Max Pool)
- Writing good user stories: the easy way (Luc Segers)
A quick goolge search on writing user stories will certainly give a great many other resources on how to write user stories. I have generally fallen into the "As an <X> user, I want to <Y> so I can <Z>" pattern of story writing. This method provides a decent amount of information to enable you to come back to a story some time later and still understand the intent of the functionality being created.
This is not, in my opinion, where a store ends. To give some context and specification to te story, I have taken to having stories have defined acceptance criteria to know when it can be deemed as "done". To this I looked toward something that would enable te development process to write criterial/specifications in a fashion that will aid with regression testing as well as help define a more "living" specification for the application. To this end I have started writing the specs using the flavours of Behavior Driven Development (BDD) to write the contect specifications. The story has given the context, the BDD frameworks give the structure to being able to write the expected behavior for the story to be "done". For .NET there are a number of BDD frameworks that I have come across that help with this:
- SubSpec (Phil Haack‘s introducing the xUnit.NET-based framework created by Brad Wilson)
- SpecUnit-NET (Scott Bellware)
- NSpec (Tim Haughton)
- DevelopWithPassion.BDD (J.P. Boodhoo)
- NBehave (Jimmy Bogard and Joe Ocampo)
I am not going to taint you with my personal choice as it’s somewhat uninformed. I took a cursory look at the frameworks and decided on one that I liked for how it expressed context specifications. The idea is that, if the framework doesn’t work for the team, it should be interchanged by any of the other frameworks. The important part is to get the specs into a format that can be run in a continuous integration process to exercise the application and change with the application over time to match the needs of the business, providing a more "living" documentation of how the software is to behave.
So, together, the "As an <X> user, I want to <Y> so I can <Z>" story-definition pattern, a name for the story, and a context specification together create a backlog item that can be scheduled for an iteration.