User Stories | 10 Tips For Writing Good User Stories

10 Tips For Writing Good User Stories
Roman Pichler | Mar 07, 2022 (Update)

1 Users Come First
2 Use Personas to Discover the Right Stories
3 Create Stories Collaboratively
4 Keep your Stories Simple and Concise
As <persona>,
I want <what?>
so that <why?>.

5 Start with Epics
6 Refine the Stories until They are Ready
7 Add Acceptance Criteria
8 Use (Paper) Cards
9 Keep your Stories Visible and Accessible
10 Don’t Solely Rely on User Stories

Author = Roman Pichler


Mobile Apps | Requirements

Functional and Non-Functional Requirements for Mobile App: What’s the Difference?
Lvivity Team | February 20, 2021

Functional requirements for mobile applications describe what specifically needs to be implemented in a particular system or product and what actions users have to take to interact with the software. They determine what the system should do.

Non-functional requirements for mobile app show what properties and features a particular solution has, namely, how the system will work and why.

What do Functional Requirements Include?
We can highlight three main groups of functional requirements:
Business requirements. These define the high-level goals set by the customer’s company that is ordering the software development and stipulate what the system is to solve in terms of their business. Example: an application allowing potential customers to browse through the company’s product catalog and to purchase products.
User requirements. These describe the system goals/objectives the users may reach when using the created system (UseCases). Simply put, this is what a user can do: sign up, view certain content, recalculate data using a specific algorithm, and other functions.
Functional requirements. These define a list of actions the system has to perform. In addition, they have to specify how the system responds to various input data, how it behaves in particular situations, and so on.
This group also includes system requirements describing hardware and software environment features necessary for correct operation.

Non-Functional Requirements in Simple Words

As a rule, the non-functional requirements primarily include various product quality attributes determining system quality features, most often as examples below:
Availability – requirements for app continuous running, for example, 24/7, minimum idle time, etc.
Reliability – app behavior in case of alarm status, for example, automatic restart and operation recovery.
Scalability – ways to expand the system and avoid adversely affected performance.
Performance – how many simultaneous users or transactions the system is to service and its response time.
Security – app operation and use of safety requirements related to access control, private data processing, and external attack risk reduction.
Usability – ease of use and user-friendly interface, that allow users to seamlessly interact with the product.
Extensibility – requirements for app extensibility in case there is a need to add new functional requirements.

Wikipedia = Non-functional requirement


Author = Lvivity Team


User Stories | Atlassian Examples

User stories with examples and a template
Atlassian | Undated

User stories are development tasks often expressed as “persona + need + purpose.” 

What are agile user stories?
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.
A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

Why create user stories?
User stories serve a number of key benefits:
Stories keep the focus on the user. A to-do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
Stories create momentum. With each passing story, the development team enjoys a small challenge and a small win, driving momentum.

How to write user stories
Consider the following when writing user stories:
Definition of “done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
User personas — For whom? If there are multiple end users, consider making multiple stories.
Ordered Steps — Write a story for each step in a larger process.
Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
Once the user stories are clearly defined, make sure they are visible for the entire team.

User story template and examples
“As a [persona], I [want to], [so that].”

Breaking this down:
As a [persona]“: Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.
Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you’re missing the point.
So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

Author = Max Rehkopf


User Stories | I.N.V.E.S.T.

The 6 Attributes Of Effective User Stories – INVEST
Kaizenko | Mar 08, 2016

Bill Wake came up with the INVEST acronym to help us remember guidelines for writing effective user stories: Independent, Negotiable, Valuable, Estimatable, Small, and Testable.

Independent: As much as possible, try to make sure that stories are not interdependent as this might lead to prioritization and planning problems. Independent is different from logical order of developing things. By independent, we mean story features. For example, let’s say we are supporting payment by credit card and we want to support payment by American Express, Mastercard and Visa. Well if we had a story for MasterCard and another for Visa, then the estimates will depend on which one we do first because implementing the other story will then be relatively straight forward. So we’d want to clarify and have one story represent “providing a primary payment option using VISA”. The other stories can then change to “provide a secondary payment option using American Express”.

Negotiable: A story should be brief. It is not a detailed contract. It’s purpose is to encourage ongoing conversation and scope negotiation between the customer and the developers.

Valuable: A story should provide value to the customer or the user. If a customer cannot think of a value statement, then perhaps we should de-prioritize the story or maybe the work is unnecessary, and we should eliminate it altogether.

Another reason to have a value statement is that value represents why we are building a certain feature. Presenting the team with the Why (value) and not just the What (feature) might trigger different ideas of alternate features that are easier or faster to develop and yet achieve the same goal and deliver the same business value.

Also, because a story is delivering a piece of functionality, the customer can figure out how much this functionality costs and then decide if they still need it.

Finally, remember that not all value is monetary. Mitigating risk is value. So is knowledge learning or acquisition.

Estimatable: Developers need to be able to estimate a story. It should be written in such a way that the developers can understand it and have an idea of how to implement it. Key factors for estimation are properly sized stories as well as domain knowledge and technical knowledge.

Small: Stories should be small.

Testable: Stories should be testable in order to help determine completeness. A story should have an acceptance criteria. The acceptance criteria should be objective. Avoid using criteria like easy to use, fast or bug free. Try to write criteria that can be measured and tested (ideally automated). For example, test that payment verification responds in 1 second or less at least 95% of the time.

Author = Fadi Stephan


User Stories | Use Cases, User Stories, Flow Charts

Understanding Use Cases, Use Case Scenarios, User Stories, Flow Charts
krasamo | Nov 18, 2020

Table of Content
What is a user story?
What are a use case and a use case scenario?
User story and a use case. What is the difference?

Example 1: Let say that we encounter a mobile app sign-in; the user story will be: User A needs to SIGN IN to access the app. (Who, What, Why). Then, we developed the use case: first, we need to open the app, verify connectivity in the device, and then present the user the options that they have to accomplish the task. We see that we have multiple choices; we can sign-in using our Facebook account, Twitter account, or email. The use case is sign-in; each of the options to sign in is a use case scenario. All of the situations lead to the same outcome, but as users, we will encounter different interfaces depending on our choice of sign-in.

A user story will give us more information regarding the motive and needs of the user; it will also give us a high-level goal vs. the use case. It will provide us with the details of how to accomplish the target and all the scenarios that the user can encounter while performing the task.
The use case is more detailed and focuses more on functionality.

What is a Flow Chart?

A user flow is a more detailed and graphical representation of a use case or use case scenario. Flow Charts express navigation as a map; they use shapes and graphics to convey the screen’s content and navigation indicators to convey the interaction between screens. Complex cases should not use Flow Charts as documentation. When the use cases involve lots of screens/elements and navigation specifications, the diagram can become too big and too difficult to understand.

The user flows can be:
Task flows: Shapes and navigation arrows represent steps.
Wireflows: More detailed flows. Instead of graphic forms, they involve Low to Medium fidelity wireframes and navigation arrows. Wireflows do not focus on specific tasks, more on the general navigation.
User Flows: It includes Low to Medium fidelity wireframes with the difference that the flows are specific on functionality from a user or task perspective navigation vs. the Wireflows that document more than one global perspective

The use cases and flow charts, in our experience, are documentation that goes through several parties involved in the process:
The Product owner takes the use cases to validate the user stories.
The Technical Leads and developers use the use cases and flow charts as documentation to verify the functionality of the implementation.
The UI UX designers develop wireframes and mockups based on the use cases.
The SQA team take the use cases to validate the expected functionality vs. the implementation.

Author = Montse Cordova (krasamo)


User Stories | Assumptions, Risks, & Dependencies

Assumptions, Risks, and Dependencies in User Stories
DZone (Agile Zone) | Mar 06, 2019

Don’t gamble with your project. Learn where these three often hidden elements may be in your user stories and how they can derail your project.

An assumption in requirements is an assertion on which a given requirement or set of requirements depends.
There are 3 fundamental problems with assumptions:
An assumption is not quantified in terms of likelihood. It is nakedly stated as a fact.
An assumption is not quantified in terms of impact. “What happens if this isn’t true?” is not part of the structure of an assumption.
An assumption has no required or inherent follow-up. In my experience, assumptions are frequently placed in requirements documents and then forgotten about. It is “assumed” that someone has added a tickler in a project plan to check on the status of an assumption, but that frequently doesn’t happen.

Assumptions were a way of attempting to formalize connections to external conditions (systems, tasks, states, etc.) that would later be called dependencies.

A dependency is simply a connection between two items (often tasks or teams, but can also apply to components, modules, or other software structures). A dependency asserts that the dependent (client) state cannot change (start or finish) until the dependency (precedent) reaches a certain state
. There are four types:

Start/Start – item A can’t start until item B starts. Cars in a motorcade can’t begin moving until the lead car begins to move. In fact, each car in a motorcade can’t move until the car immediately in front of it moves.
Start/Finish – item A can’t start until item B finishes. The second stage of a rocket can’t fire until the previous stage has finished.
Finish/Start – item A can’t finish until item B starts. Less common in software development, but an example would be an evening security guard who can’t end his/her shift until the guard on the next shift clocks in and begins their shift.
Finish/Finish – item A can’t finish until item B finishes. My accountant can’t finish our income tax preparation until we have finished assembling all requisite data from the year.

Dependencies have similar problems to assumptions, though to a lesser degree.

Generically, a risk is something Bad that might happen (in this context we add “…that affects the timely and correct implementation of software”). More formally (at least in Project Management circles), a risk is a potential negative condition that can be quantified in two dimensions:
How likely is this condition to occur?
What is the impact should this condition occur?

It is important to note at this point that risks should be identified which affect the project, not the company.

It’s also useful to note how well this approach (originating in Project Management) dovetails with Agile. Identifying and quantifying risk gives Agile teams the ability to prioritize tasks. Some people are insistent that risk is a potentially negative external condition that can affect a project. But internal risks need to be identified and quantified as well.

Which brings up the second beneficial aspect of using the Project Management approach to risk: it requires the creation of a plan to mitigate any negative impact on the project. This has an implication that isn’t immediately obvious: risks that can’t be mitigated are effectively not risks.

Since dependencies are a form of risk, it stands to reason that they should be included in any mitigation plan.

Train your teams to avoid the use of assumptions in user stories, use cases or any requirements document. Excise existing assumptions from such documents by examining each one in detail, then either a) removing the assumption unilaterally, or b) converting the assumption into a risk or dependency.
Use dependencies specifically to document the order of events, steps or stages (not components), and be clear about how the term is being used. Treat all dependencies as risks.
Use risk to quantify likelihood and impact, using whatever scale is appropriate for your organization. Use the term and scale consistently across teams and projects.
Establish a mitigation plan for (at least) high-priority risks.
Remove any identified risks that have no possibility of mitigation, most effectively by bumping it up to any architectural planning group that oversees long-term development practices.

Author = Tom Fulton (Agile Zone)


User Stories | User Story (+ Tool)

Glossary = User Story
ProductPlan | Undated

User Story
Definition: A user story is a small, self-contained unit of development work designed to accomplish a specific goal within a product. A user story is usually written from the user’s perspective and follows the format: “As [a user persona], I want [to perform this action] so that [I can accomplish this goal].”

What is a User Story?
In agile software development, a user story is a brief, plain-language explanation of a feature or functionality written from a user’s point of view. Many agile experts also describe a user story as the smallest unit of product development work that can lead to a complete element of user functionality.

Product teams choose to break development work into user stories instead of product features or product requirements for several reasons.

User stories:
Are easy for anyone to understand
Represent bite-sized deliverables that can fit in sprints, whereas not all full features can.
Help the team focus on real people, rather than abstract features
Build momentum by giving development teams a feeling of progress

What Does a User Story Look Like?
Most product teams use a similar user story template, typically just a sentence or two written according to the following formula:
As a [description of user], I want [functionality] so that [benefit].

User Story vs. Use Case: What’s the Difference?
Like user stories, a use case describes how a user might interact with a product to solve a specific problem. But the two are not interchangeable; they are different tools used in product development.

Ivar Jacobson, who is credited with developing the use-case concept, explains that use cases document both a user’s goal and the functional requirements of the system. In other words, use cases are designed to capture much more detail than a user story about the process a user goes through to achieve the desired outcome from interacting with a product.

Whereas a user story is written as a very brief statement describing only the user’s end goal, a use case often describes several additional steps, including:
The preconditions required before the use case can begin
The main flow of events (also called the basic flow) describing a user’s path, step by step, to completing an action with the product
Alternate and exception flows, meaning variant paths a user might take with the product to complete the same or similar goal
Possibly a visual diagram depicting the entire workflow

How Do You Write a User Story?
Here’s a simple, six-step process for crafting user stories:
Step 1: Decide what “done” will look like = definition of done
Step 2: Document tasks and subtasks.
Step 3: Determine your user personas.
Step 4: Create stories as ordered steps.
Step 5: Seek user feedback.
Step 6: Draft stories that can be completed in one sprint.

Product Teams, Why Wouldn’t You Write with Your Users in Mind?
Aside from the fact that they’re designed to fit on index cards and can be easily understood by anyone, one of the biggest advantages of user stories is that they can help you from getting lost in the technical details of your product’s backend or from becoming enamored with a UX you believe is elegant but that isn’t actually structured in a way your users prefer to work.

User stories help your team accomplish all of this — and build better products — by forcing you to make one simple change to your approach to development planning. Rather than writing up your plans from the product’s point of view (which features to build), user stories force you to draft each proposed idea for new functionality from the point of view of the actual people who will be using that functionality.

Tool = ProductPlan
Share your product story
ProductPlan is a roadmap platform that aligns your team so you can build what matters.


User Stories | Acceptance Criteria

Acceptance Criteria for User Stories: Purposes, Formats, Examples, and Best Practices
altexsoft | May 18, 2021

What are the acceptance criteria and their role in projects?
Acceptance criteria (AC) are the conditions that a software product must meet to be accepted by a user, a customer, or other systems
. They are unique for each user story and define the feature behavior from the end-user’s perspective.
Acceptance criteria are the lowest-level functional requirements
Well-written acceptance criteria help avoid unexpected results in the end of a development stage and ensure that all stakeholders and users are satisfied with what they get.
An important aspect in regard to acceptance criteria is that they have to be defined before the development team starts working on a particular user story. Otherwise, there’s a decent chance the deliverables won’t meet the needs and expectations of a client.

Acceptance criteria main purposes
Making the feature scope more detailed
Describing negative scenarios
Setting communication
Streamlining acceptance testing
Conducting feature evaluations

Acceptance criteria types and structures:

(A) Scenario-oriented acceptance criteria (GWT)
As the name suggests, the scenario-oriented format is the acceptance criteria type that comes in the scenario form and illustrates each criterion. It is approached through the Given/When/Then (GWT) sequence that looks like this:
Given some precondition
When I do some action
Then I expect some result

The acceptance criteria template in this format includes the following statements:
Scenario – the name for the behavior that will be described
Given (a precondition) – the beginning state of the scenario
When (something happens) – the specific action that the user makes
Then (this the result) – the outcome of the action in “When”
And – used to continue any of three previous statements
When combined, these statements cover all actions that a user takes to complete a task and experience the outcome.

Example – User story: As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.
Scenario: Forgot password
Given: The user navigates to the login page
When: The user selects option
And: Enters a valid email to receive a link for password recovery
Then: The system sends the link to the entered email
Given: The user receives the link via the email
When: The user navigates through the link received in the email
Then: The system enables the user to set a new password

(B) Rule-oriented acceptance criteria format
The rule-oriented form entails that there is a set of rules that describe the behavior of a system. Based on these rules, you can draw specific scenarios
Usually, criteria composed using this form look like a simple bullet list.

Example – User story: As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.
Basic search interface acceptance criteria :
The search field is placed on the top bar
Search starts once the user clicks “Search”
The field contains a placeholder with a grey-colored text: “Where are you going?”
The placeholder disappears once the user starts typing
Search is performed if a user types in a city, hotel name, street, or all combined
Search is in English, French, German, and Ukrainian
The user can’t type more than 200 symbols
The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”

Ready-to-use acceptance criteria templates

Roles responsible and how acceptance criteria are created
Some of the criteria are defined and written by the product owner when he or she creates the product backlog. And the others can be further specified by the team during user stories discussions after sprint planning.
There are no strict recommendations to choosing the person responsible for writing the criteria. The client can document them if he or she has ample technical and product documentation knowledge. In this case, the client negotiates the criteria with the team to avoid mutual misunderstandings. Otherwise, the criteria are created by a product owner, business analyst, requirements analyst, or a project manager.

Main challenges and best practices of writing acceptance criteria
Document criteria before development.
Don’t make AC too narrow.
Keep your criteria achievable.
Keep AC measurable and not too broad.
Avoid technical details.
Reach consensus.
Write testable AC.

Follow these tips for guidance on how to phrase your AC.
Write in active voice, first-person.
Avoid negative sentences.
Write simple, concise sentences.

Final word
Don’t neglect the acceptance criteria as they – being simple and approachable – solve multiple problems at once. They document customer expectations, provide an end-user perspective, clarify requirements, prevent ambiguity, and eventually help quality assurance verify if the development goals were met. Regardless of whether you use Agile methods or not, make sure to choose the best format or experiment with your own ones. Different types of user stories and eventually features may require different formats and testing the new ones that work for you is a good practice.

Author = altexsoft