Select Page

A User Story Expresses WHAT, Not HOW!

Rule 2 in How To Write Effective User Stories That Express Business Needs and Minimize Misunderstandings

FREE

Author: Tom and Angela Hathaway
Video Duration: 7:08 minutes

 

This KnowledgeKnugget™ is part of an eBook and an eCourse

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.

Video Transcript Excerpt

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]

How To Write User Stories That Deliver Real Business Value

How to Capture, Write, Prioritize, Rightsize and Split User Stories Plus Acceptance Tests with Given-When-Then Scenarios

User Stories: A Collaboration Tool for Business and IT

How to Capture, Write, Prioritize, Rightsize, and Flesh Out User Stories with Defined Acceptance Tests as Given-When-Then (GWT) Scenarios

Writing Effective User Stories – Simply Put!

Writing Effective User Stories - Simply Put!

Requirements Gathering with Use Cases for Business Analysts

Lean Use Cases to identify and write Use Case models and diagrams

Kick-start Your Business Analyst Career

Books, eBooks, and Online Courses at a Reasonable Cost

Written for the aspiring Business Analyst and anyone tasked with defining the business needs, requirements, or user stories for a future IT solution.

Kick-start Your Business Analyst Career

Books, eBooks, and Online Courses at a Reasonable Cost

Written for the aspiring Business Analyst and anyone tasked with defining the business needs, requirements, or user stories for a future IT solution.

Pin It on Pinterest

Share This