User Stories — A Designer’s Vision by Pradeep Kumar
1. Definition
A User Story is an informal, natural language description of features of a software system. They are written from the perspective of an end-user or user of a system. Depending on the project, user stories may be written by different stakeholders like clients, users, managers, or the development team.
2. User story criteria
INVEST criteria:
- Independent: Independent of other User Stories. This helps to change its order in the Product Backlog and eases the Developer’s development.
- Negotiable: Negotiability enables the Development Team and PM to work together to build more detailed and relevant content for future changes. Without this feature, adapting to change is difficult.
- Valuable: The User Story must be valuable to the customer. Technical people may find frameworks, databases, or designs important. However, not with customers.
- Estimable: A good User Story can be estimated, although it does not need to be exact. Large or unclear User Stories are often difficult to estimate. The ability to estimate helps the team better estimate the work to be done and also the release plan. Obviously, this depends on the capabilities of the team.
- Sized appropriately: User Stories that are about to go into production need to be small in size (meaning they are described more clearly), User Stories that have not yet been put into production may have a larger size.
- Testable: If the development team knows how the User Story is complete – clearly testable, they can better understand their work, less misunderstanding.
3. How to write User Story (with example)
3.1 User story structure:
Structure 1:WHO - WHAT - WHY
As a persona (Who) I want to do something (What), so that I can derive a benefit (Why).
As you can see, the user story is written in the Who-What-Why format, and without the How, it is not known what sequence of steps in the user function should be performed. In fact, all the details, logic, scenarios that are not described in the user story are often included in the Acceptance Criteria.
Structure 2:WHY - WHO - WHAT
In order to achieve some business value (Why) As a persona (Who), I want to do something (What).
In fact, to write user stories quickly so they can keep up with the project progress, they often ignore the WHY part. And that is also the biggest problem of the user story writer. So later appeared the structure 2: writing WHY (purpose) first, and changed “So then I can…” to “In order to…” for context.
In addition, when it comes to “user story”, it usually 2 meanings:
- The story structure (as above), and
- A requirement item.
So that, an epic or feature can also follow the story structure, but the scale & scope of the epic is higher than the feature, and the feature is higher than the user story.
3.2 How to separate User story
Below are 6 options to separate a User Story. When analyzing stories and putting them into the sprint, we need to separate them into smaller stories or separate AC into smaller ACs. “Small” meaning can’t be any smaller (but also avoid crumbs!). Note that a Story should not have too many ACs (< 10 ACs), just as an epic should not have too many stories (10 → 15 Stories).
Option 1️⃣ Separate from Workflow
A workflow has many steps, instead write a Story, we separate each step into a User Story.
Instead of writing:
As a grocery store cashier, I want to checkout a customer, so that I can complete the sales transaction.
It should be:
As a grocery store cashier, I want to…… calculate the total amount that will be charged to customer. (Story 1)
… specify the method of payment preferred by the customer. (Story 2)
… enter the credit card details. (Story 3)
… print a receipt for the customer. (Story 4)
Option 2️⃣ Separate from Data Detail
On a screen with many fields of data the user must enter, it is possible to separate into groups of related data, each group has a user story.
Instead of writing:
As a student, I want to view my grades for this semester’s courses, so that I can see how I’m performing.
It should be:
As a student, I want to view…… my numeric grade for this semester’s courses, so that I can quantify my performance. (Story 1)
… my letter grade for this semester’s courses, so that I can calculate my GPA easily. (Story 2)
… the class average for this semester’s courses, so that I understand my relative performance. (Story 3)
Option 3️⃣ Separate from Happy Paths, Unhappy Paths
A user story often only focuses on the main purpose of the user (happy path, happy case, main flow), the analyst forgets about many other flows. Corner cases are also possible in different stories.
Instead of writing:
As a Uber-taxi customer, I want to view information about my booked taxi, so that I can track its movement.
It should be:
As a Uber-taxi customer, I want to view information about…… an on-time taxi, so that I can track its movement. (Story 1)
… a delayed taxi, so that I can track its movement. (Story 2)
… a cancelled taxi, so that I can re-book another one. (Story 3)
Option 4️⃣ Separate from Core & Enhance
Focus on the main & simple first, e.g. a Search function with default parameters, separate upgrades into user stories, e.g. Search function with different filters.
Instead of writing:
As a Salesforce user, I want to create revenue, profit, and growth reports, so that I can perform monthly forecasting.
It should be:
As a Salesforce user, I want…… to create a revenue report for a month, so that I can view the revenue generated in that month. (Story 1)
… to create revenue, profit, and growth reports for all months, so that I can perform forecasting for the next month. (Story 2)
Option 5️⃣ Separate from Business Rules / Policies
Separate by each business rule/product policy is a story. The rule that is important and has a great impact is put first, with higher priority.
Instead of writing:
As a customer, I want to purchase the goods in my shopping basket so that I can receive my products at home.As a shop owner, I want to track & control the orders submitted from the customer in my store, so that I’m aware of what status of the order is.
It should be:
As a shop owner, I want to…… decline orders below 10 dollars, because I don’t make any profit on them. (Story 1)
… decline customers from outside the US, because the shipping expenses make these orders unprofitable. (Story 2)
… reserve ordered products from stock for 48 hours, so other customers see a realistic stock. (Story 3)
… automatically cancel orders for which I have not received payment within 48 hours, so I can sell them again to other customers. (Story 4)
Option 6️⃣ Separate from Operations
Each activity in management/maintenance/operation is a user story.
Instead of writing:
As shop owner I want to manage products in my online shop, so I can update price and product information if it is changed.
It should be:
As a shop owner, I want to…… add new products, so customers can purchase them. (Story 1)
… update existing products, so I can adjust for changes in pricing or product information. (Story 2)
… delete products, so I can remove products that I no longer stock; …hide products, so they cannot be sold for the time being. (Story 3)
3.3 So when you write a User story, remember this checklist:
✅ Keep them short.
✅ Keep them simple.
✅ Write from the perspective of the user.
✅ Make the value/benefit of the story clear - What is the reason for the story?
✅ Describe one piece of functionality. If you have to write and break it into 2 stories.
✅ Write stories as a team.
✅ Use acceptance criteria to show a MVP.
4. FAQ
❓ When do you need to write User Story?
User Stories are written throughout project development, which means members can add new User Stories at any time.
