Writing better user stories with the INVEST framework
+ a request for your opinion + Some PM tips for handling edge cases
Care to share your opinion?
I’m running an opinion survey this week to understand more about what readers are seeking from content around product management & growth.
It’s a total of 9 (mostly) open-ended questions. It might take 7-10 minutes of your time but it will give me some key insights into what you’re hoping for in terms of PM content.
https://nn7iabxuox6.typeform.com/to/Pg9aZWiN
Feel free to speak your heart out. I look forward to hearing your voice.
Writing better user stories with the INVEST Framework
It can be argued that a lot of issues in prioritization stem from the quality of written user stories. Poorly written stories can often lead to misunderstandings between development and product managers.
To help with this, there is a litmus test framework called INVEST that helps you keep your user story quality in check.
INVEST stands for:
Independence: a story shouldn’t be tightly coupled with another.
Negotiable: the scope of work should have some flexibility & leeway.
Valuable: the “why” behind the user story should be easy to understand.
Estimable: the team should be able to quantify the effort.
Small: the story should be small enough to be shipped within a sprint.
Testable: the verification process for the story is well understood.
Let's analyze a few example of user stories for a food delivery app:
👉 User Story: "As an order placer, I need to be able to place an order, generate an invoice with a link to share it."
🚩 What's wrong?
Violates the [I]ndependence condition. The story talks about generating an invoice after placing an order but also mentions the sharing link. Now, until the sharing link story is defined and ready to ship, this story will remain incomplete. This tight coupling deprives this user story from being independent.
✅ What's better?
Break into multiple stories: one for placing an order, another for generating a digital invoice and another for sharing it.
-
👉User Story: "As an order placer, I need to tap on a red full-width button with a trash can icon so that I can quickly clear my cart without removing each item individually.
🚩 What's wrong?
Violates the [N]egotiable condition. Button, full-width, icon? Such detail makes it too prescriptive for the designer to come up with a better solution.
✅What's better?
"As an order placer, I need to clear my shopping cart in one go, so that I can create a fresh order quickly."
-
👉User Story: "As an admin, I need to see the most expensive order till date."
🚩 What's wrong?
Violates the [V]aluable condition. The user story doesn't make it clear how the functionality will aid the admin & what the business case is.
✅What's better?
"As an admin, I need to identify the customers that have spent the most with us this month, so that I can mail them physical swag."
-
👉User Story: "As a restaurant owner, I want to view a real-time dashboard, so that I can track the orders, popular cuisines & breakup of order locations in one place."
🚩 What's wrong?
Violates the [E]stimable & [S]mall condition.
First, it's not estimable because we're not sure what "tracking" orders means here - is that viewing the count of orders over time OR a snapshot of all in-flight orders.
Secondly, this doesn't seem like work for a single sprint & needs to be broken down.
✅What's better?
"As a restaurant owner, I want to view a visual graph depicting the number of daily orders placed, so that I can understand how well the business has performed over time."
-
👉User Story: "As an order placer, I want smart food suggestions, so that I can make better purchasing decisions."
🚩 What's wrong?
Violates the [T]estable condition among other things. "Smart" is a vague term & cannot be tested against until defined. Does that mean cost-effective? Order speed?
✅What's better?
"As an order placer, I want to sort my search results by ascending calorie count, so that I can first see options that conform to my weight-loss goals."
I hope the above examples give you an idea on how the INVEST testing framework can help you write better user stories.
Dealing with Edge Cases as a Product Manager
Every sprint, Product Managers battle with their age old nemesis.
Edge Cases.
What's an edge case?
A non-obvious user path in a product that is travelled/triggered in specific conditions. It mostly refers to a scenario that's not appropriately handled by the code.
Edge cases arise when a product is designed with a strict set of assumptions & has no affordance to change, flex & a variety of conditions.
(some teams differentiate this against "corner" cases which is essentially a subset of an edge case - an oddity that occurs in very specialized conditions)
Example: On a multi-lingual site, a button looks mostly fine but in 1 specific language the translated text is longer than anticipated & breaks the UI.
Or here where the email address was longer than anticipated and the left panel didn’t wrap the text around:
Edge cases come in different shapes & forms.
💢 UI Breaks
Ex : The live chat widget covers a key CTA button on a certain browser.
Ex: When there aren’t enough jobs featured on a job site, the home page carousel leaves a gap on the side creating imbalance in the UI.
🎧 Device Support
Ex: Actions don't work on a certain browser.
Ex: An image editing app allows users to access actions via a right click but no gestures were configured for a tablet user.
🔧 Logical Holes
Ex: A geographical report is lumping data from London, UK and London, ON (Canada).
Ex: A user was able to create a cyclical loop on a workflow builder.
📁 Domain Blind Spots
Ex: A company allows employees to exist in 2 departments but the recruitment software assumes a 1-to-1 relationship.
🎍Externalities
Ex: A game assumes certain internet bandwidth & thus, works poorly for people with low-bandwidth data packages.
👓 Accessibility-related
Ex: Product uses color-coded labels to distinguish categories & in doing so, alienates color-blind people.
So, how can PMs address these edge cases proactively?
1) Ask: Is it even an edge case?
It's easy to conflate an edge case with an "overlooked bug". The team needs to hash out which is which based on the product goals, audience & expected user behavior. Is it really an uncommon user path?
2) Use visual representation
Textual narratives have their own place but they can be hard to process visually. Wherever possible, use flowcharts, story maps & mockups that lend themselves better for identifying unaddressed flows.
3) Prototype for a customer.
Get a set of customers to see your prototype early to uncover domain-related edge cases & address them before launch.
4) Collaborate intensely.
Involve developers, designers & QAs early in the process. Challenge them to break the spec down & identify plausible UI breaks & logical holes. Creative QAs & BAs can create a checklist of typical scenarios that the product has run into in the past and cross-check the spec in question.
5) Prioritize + Use probability.
How many people are going to be affected? Even if it's a small pool, how intense is the loss if not addressed? Is it reversible? Is there a workaround? Also, what's the effort vs. gain? A quick cost-benefit analysis can help what edge cases to prioritize. There will be several that you might choose to let go - and that's ok.
In the end, edge cases are part and parcel of a product management journey. It can be really hard to shoehorn fixes in during the sprint, so identifying and planning around them is important. Referencing common problems seen in past sprints can help a lot.
But most of all, it’s working collaboratively with the team, leveraging each of their vantage points, that helps clears the fog.