One of the causes of death march project is poor story definition. Whether you call them stories, features, tasks, items or whatever, defining good stories is essential for success.
The ACID principle from database design applies to stories as well as databases. Atomicity, Consistency, Isolation and Durability. These principles apply to story design as much as they do to anything else.
Atomicity
Making stories atomic means making them “all or nothing”. When designing stories this means that the stories are small enough that the acceptance criteria will either be met or not met. When trying to accept the story, this translates to a fairly rigid adherence to the definition of done.
The reason for making atomic stories is so that requirements don’t get lost. The anti pattern for this is when there is a long list of acceptance criteria, the normal response is to accept the partially completed story and maybe split the incomplete parts into separate stories.
The downside of this is that information might get lost when this happens. The way to avoid this would be to make the stories smaller, more atomic, from the start. Rather than ending up that way, if you start that way no information would get lost.
Consistency
Consistency is really an aid for everyone other than the author of the story. Making the language consistent across stories is one of the most difficult things to do when creating new stories. However, it’s the most important thing for speeding up the time to market.
Some of the ways to deal with this can include creating a domain dictionary. For example, when you talk about SSO, what does that mean. If everyone has the same definition of the term, then fewer people get confused.
Isolation
In this context, Isolation means that stories should be relatively stand alone. There will always be some interdependence between stories, especially if they are atomic. Recognizing the interdependence between stories needs to be explicit and well understood by everyone.
For example, say that there are stories for a user logging in, and then other stories for different options displaying for different permissions. These stories interrelate because the permission stories depend on the logging in story. The simplest way to deal with this is to implement the stories at different times.
The anti pattern to this is when we create a circular dependency between stories. When story A depends on story B, which depends on story A. there is a real problem. That’s normally a sign that a story C should be created that has the parts of A that B depends on and the parts of B that A depends on.
Durability
Durability in the context of user stories is really about making stories that are about adding capabilities rather than removing them. For example, if you have a story adding feature A, don’t create a story in the next sprint removing feature A.
Basically, durability is all about reducing churn. Churn in any development process, is waste. It’s not adding value to the customer.
The way to avoid this is to make atomic stories, instead of creating a temporary feature A, create the final feature, but break up the stories up to start with the temporary story, then stories to refactor closer and closer to the final form.
In summary, the ACID principles are a good set of guidelines to keep in mind when creating user stories. Simple acronyms are easy to remember and will help keep the principles at the top of mind when creating user stories.
Scott's Thoughts 