Photo by Dakota Roos on Unsplash

Framework to write User Stories

The below framework can be used as a guideline to define user stories.

1. A good user story should describe the problem that we are trying to resolve rather than offer a solution to the problem
2. It should focus on the outcome rather than the output
3. To create empathy, the user story should have a specific persona rather than a faceless user
4. It should also point towards a business or customer value that will be achieved if we implement this specific user story
5. The user story should follow INVEST (A user story should be Independent, Negotiable, Valuable, Estimateble, Small, and Testable.)
6. Ideally, a single user story should be delivered in one sprint, if its large break into smaller stories
7. All the functionality or business rules to be implemented and tested should be crystal clear and transparent (As everyone on the team should be aware of them)
8. The functionality or the feature to be shipped should adhere to quality standards so that user stories can be considered as DONE

Is user story alone, enough?

The simple answer is NO. User story alone could provide the shared end goal. But how to get there, can be supported by
1) Definition of Done
2) Acceptance Criteria

1. Definition Of Done (DoD):
   DoD is usually defined on the project level and/or organizational level. It helps to answer the question “Is specific functionality/feature ready to be served to the customer? ”
   (For more details, please read 3 steps to define the Definition Of Done)
2. Acceptance Criteria
   Consider the following user story:
   As a new visitor of a website
   When I visit the home page
   Then I can see a Signup button

The above example has a single scenario. When a new visitor will be able to see a signup button, then we can say that feature is ready to be tested. Acceptance criteria is mentioned in the “THEN”

But for the complex functionality, e.g
As a signed in user
When I visit accounts settings page
Then I can see the updated design
And I can enter a hyphen in the phone number field

Instead of writing a new user story for each updated designs or how the developers are handling errors, we explicitly mention the expected behaviour in the Acceptance criteria.

The acceptance criteria would be
1) The fonts are updated according to the new design
2) Labels are being added according to the new design
3) Background color is updated according to the new design
4) Accounts setting will be saved when a user enters hyphen in the phone number
5) Error will be displayed when user saves the number after entering 2 or more hyphens
6) Error message will be displayed when the user will save the phone number after adding special characters “( “, “)” or “-”

What is the best format to write a user story?

User stories can be written in any format depending upon the functionality or the project. As long as it contains the following information:

1. Who: Who will be the end-user of the feature? “role”
2. What: What are we building? “feature/wish”
3. Why: What's the purpose or goal do we want to achieve? “value/benefit”

Most popular user story template:
As a <role> I want <target / wish>, so that <value/benefit>.

The template used should clearly define the user persona, their need, and their outcome . The rationale behind why we want to implement a feature helps the team to answer as “HOW” can we implement the functionality.

Do apply the above-proposed framework and let me know if you find any missing gaps. I will be more than happy to hear and work with you to update this framework.

For any kind of suggestions, feedback or queries, please feel free to comment or contact me on my email address nidasaleem333@gmail.com