User story writing is an overlooked & underhyped skill. Something which most folks take for granted.
Add to this, the multitude & unclear expectations when it comes to “What should be included in an User Story”. Organizations focused on Agile like Scrum Alliance dont go into the details of writing User Stories. Many Business Analysts end up thinking that user story writing is more about getting the format right which is “As a User, I want to.. ” – which is really not the case.
There are a number of things one can do to write a good user story. Good means – which will solve the purpose here – & that is giving the developer the functional details needed to develop a feature.
Mistakes to Absolutely Avoid:
- Usage of Unnecessary or free flowing words
- Grammatical
- Diversion from the format: As a XX, I want to XX, so that XX
- Ambiguity. If one needs to use subjective words, those better be using parenthesis to elaborate the meaning. Avoid words like “Manage” instead use words like “Create, Add, Edit, Remove, Schedule etc. “
- Not getting the persona right: Even if there are multiple personas which can be applicable for a scenario
Characteristics of A Good User Story:
1) Minimum Mistakes
Avoiding the mistakes captured above
2) Perfect Title
The best practice here is title should capture the persona & encapsulate the scope of the story in it. Example – If on the checkout page I want to display payment methods then, I will write:
As a guest user, I want to see payment methods on the checkout page, so that I can select a given payment method to make a purchase
Here, the persona – the Guest, Returning User etc. is captured correctly.
The scope of the story – which is displaying the payment methods is also displayed correctly.
A bad user story would be:
As a user, I should see payment methods on the checkout page. So that I can know which payment methods are available.
The above title: has mistakes related to persona, format & free flowing language.
3. Perfect Acceptance criteria
The Acceptance criteria should definitely
a) Follow the MECE rule (Mutually Exclusive & Collectively Exhaustive): Which means – no two criteria should ever be the same. I cannot stress this enough.
b) Include All scenarios: This is where “critical & analytical” thinking comes into picture. To give an example which may resonate with folks who have watched Money Heist. It should be in same way the professor would plan a heist – which is factor all scenarios.
c) Include Supporting documents: Figma, Zeplin links, data flow diagrams etc.
d) Use technical language: Use UI language which means using right terminologies for UI components (think of terms like Accordions, Chevrons, Cards, Hamburger Menu etc.). The reason here is it is a standard language & you avoid ambiguity if you use a language. Referring to frameworks like Bootstrap, Material Design etc. is immensely helpful here.
e) Highlight Dependencies: Highlight dependencies on external vendors, APIs wherever possible.
What may not be in an User Story
Technical details/ Implementation approach better not be included in the user story – at least should not be entered by Business Analyst himself. The reason is it clutters things & we have different documents like a TDD or SDD to manage the technical implementation implementation approach.
If it is absolutely necessary for the development team to include implementation details/ API details then it is best to groom the story along with development team & then get those added. This can also be included in a subtask though in tools like JIRA.
The Act of writing an User Story
User story writing is in fact an act of “writing”, which means it has be written with the same mindset & rigor as that of a professional writer. This typically includes: Having a structure in mind of what one wants to cover and most importantly rewriting (i.e. cleaning the story at least 2-3 times to prune out the errors to make it clean & effective).
There you go ! Post this you should have a clean and effective user story which a developer would love & the client would thank you once he sees the product.