Planning an Iteration – Defining a Story and How to determine if it is “Done”

In a previous post, I spoke of using fibonacci numbers to estimate tasks in an iteration. In the comments of that post I had mentioned that I would illustrate how those Fibonacci numbers are intended to be used during an iteration. I’d like to take a step back, before getting into iteration planning and estimating, and take a look at creation of an iteration backlog.

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:

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:

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s