In this KnowledgeKnugget™ you will learn how to apply step 2 to user story writing. When writing user stories, stakeholders should focus on what they want/need as the business outcome once the user story has been implemented. Technology decisions should be left up to the developers.

An Effective User Story Focuses on the Business Result

In the KnowledgeKnugget™ on Keep Your User Story Simple, we discussed Rule 1 of how to write effective User Stories that express business needs and minimize misunderstandings, to wit:

Rule 1: An effective user story is a simple sentence that does not contain conjunctions (and, or, but, etc.) or limiting phrases (unless, without, except, etc.).

Assuming that your user story complies with rule 1, what else can you as the author do to make your and your developers’ lives easier? In a word, lots. Just for info, there are going to be a total of five (read ‘em, 5) rules in this series by the time we are done. So without further ado, let us get on with the next rule:

Rule 2 in the series states: “An 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 is their job. The problem, as always, lies in the detail of how to follow this seemingly simple rule. So let us analyze this ubiquitous “what-not-how” rule to see what it is really all about.

Primarily, it is about focusing on the business results and avoiding thinking about how to achieve them. Avoiding preconceived solutions seems like a great idea, because all too often, your overworked developers will simply implement what you ask for without considering whether it is the best alternative. You need to avoid what I call “the solution trap” also known as the “how trap”. Think about “What” business result you want to achieve and let the developers think about “how” they can achieve it given your parameters.

Consider the Final Outcome

You can achieve this by thinking about the destination instead of the journey. Here is a good example: Let us say I am teaching a class in Houston next Thursday and Friday. The class starts at 8:30 AM Thursday morning. If I were to formulate a user story in that context, I could say,

… [end of excerpt]