Keeping your user stories simple.
Rule one: An effective user story is a simple sentence that does not contain conjunctions; and, or, but etc or limiting phrases; unless, without, accept etc. assuming that your user story complies with rule 1, what else can you as the author do to make your and your developer’s lives easier?
Rule two: Effective user story emphasizes what should be done not how to do it. since the birth of the information technology IT profession and presumably even before that developers or builders of any kind have been asking the business community, their customers to tell them what they want not how to develop it after all the how is really the dominion of the developer community, it’s their job, the problem as always lies in the detail of how to follow this seemingly simple rule, so let’s analyze the what not how rule to see what it is really all about.
Primarily it is all about focusing on the business results and avoiding thinking how to achieve them. Avoiding preconceived solutions seems like a great idea because all too off and your overworked developers will simply implement what you ask for without considering whether or not it is the best alternative.
You need to avoid what I call the solution trap, think about what business result you want to achieve and let the developers think about how they can achieve it giving your parameters. You can do this by thinking about the destination instead of the journey, here’s a good example, let’s say I’m teaching a class in Houston next Thursday and Friday, the class starts at 8:20AM Thursday morning, if I were to formulate a user story in that context I could say as a traveler I could book a flight leaving the day before the class starts to be on time for the class, not that this complies with rule 1 and the suggest structure for a user story.
However, expressed that way I’m limiting my choices, booking a flight is a how or expressed differently is a preconceived solution because it assumes I will fly there. How about I say as a traveler I can be at the customer site at the designated time on the morning of the first day to begin the class on time, that leads me with lots of options to fill my business need, I could fly there on Wednesday and stay overnight in a hotel like most civilized folk will probably do, I can drive there in my motor home in a couple of days or even hitchhike from Tampa if I feel luck and realize the added element of uncertainty.
The point is, there are many possible ways of satisfying the business need so do not get hung up on the obvious solution too soon; try to think about business logic or rules instead of technology solutions. Let’s look at a real example to clarify exactly how subtle the difference can be. If a subject matter expert or SME has a problem with customers entering invalid State abbreviations in the address box of a form they might be tempted to write the user story, as an applicant I can select my state from a dropdown box of abbreviations to avoid entering an invalid state, that way eh SME will never get an illegal state abbreviation. The problem is that the dropdown box is actually a specific technology, not necessarily a bad one by the way but not necessarily the best either. If instead of jumping into the solution the SME considers what she’s really trying to achieve her better user story might be, as an applicant I can submit a valid state abbreviation to ensure an accurate quote for insurance coverage. This expresses what the business needs; a valid state abbreviation without specifying how we’re going to achieve it, the dropdown box. Why is this important? By avoiding premature technology decisions the user story actually becomes more valuable; if your user story tells me the developer that you want a dropdown box I may not even consider any other options. Perhaps instead of using a dropdown it would be possible to automate the process by using a zip code and a web app that return to the state automatically. As a website visitor I appreciate any solution that reduces or eliminates mistakes
An effective user story expresses what should be done not how to accomplish it by
- Avoiding preconceived solutions,
- Describing the business result not the technology needed and
- Describing the destination not the journey.
If you follow this simple recommendation your user stories will be much more effective.