When I write user stories, in addition to the story itself, I like to help define edge cases in my stories and I typically do this as acceptance tests.
There are automated acceptance test tools such as FIT and Cucumber that not only allow me to define acceptance tests but also help me run them against the code that I’m building to see when they’re complete.
There’s always something more to do or some condition lurking out there we might not have thought of, so developers spend a lot of time trying to figure out if they’ve done enough on a project or on a particular feature. Having an acceptance test that is well-defined helps us know when we’re done implementing a feature.
When the acceptance test passes, we’re finished, and we can move on to the next feature. This helps us avoid gold plating and we spend more of our time building valuable features instead of needlessly enhancing the ones we’re currently working on.
I’m also not opposed to adding anything else that would help us when writing the story. If there are special security concerns or concerns that require operations, I’ll jot that down on my story card as well. When I teach writing stories, I typically teach using three by five cards to keep my stories short. My colleague, Greg Smith, typically teaches story writing using an eight and a half by eleven sheet of paper and he has several other support items that you can add to help when you’re writing a story. I like the “Smith Method” of story writing in practice, but generally, when I’m teaching I try to start out using three by five cards to emphasize how simple stories can be.
There are times I don’t use stories. They aren’t the appropriate tool for every kind of software development—I don’t believe anyone tool is. If I’m writing something highly procedural that involves a series of steps then I’ll go ahead and draw it up as a use case, but if I can take advantage of the OO paradigm I tend to use stories as my first way of defining what I want to build.
Once a story is written, depending upon how involved it is to implement, I’ll begin breaking it down into a series of tasks. Each task will give me a measurable step toward the overall implementation that I can then demonstrate as progress to my customer.
Development tasks should be as short as possible. I like them to be anywhere from a few hours to a few days. When a task is complete, another test passes in my acceptance test suite, and I’m one step closer to completing the story.
All of these may seem strange to you if you’re not familiar with building software in this way, but really, it’s just common sense. If you have any big problem that’s hard to figure out, breaking it down into a series of smaller problems often helps make each one more manageable. This is essentially what we’re doing when we build software incrementally. We still have to plan, design, and think very carefully about what we’re doing but we’re restricting the problem domain so it’s simpler to solve.
Agile is not a prescription to go on automatic pilot. In fact, just the opposite is true. Agile gives us opportunities to get more feedback than traditional software development and as long as we’re able to take advantage of that feedback and change our course of action when needed, we can use Agile to our advantage.
Previous Post: « User Stories Support Object-Oriented Development
Next Post: Still XP After All These Years »