How to improve the quality of User Stories

How to improve the quality of User Stories
DALL·E 2 Prompt: Carving an abstract figure out of a stone, with the carving process shown in progress.

đź“ť Summary (TL;DR)

This guideline is used to determine whether a system or developed software meets customer expectations.

The basis are acceptance criteria, which are the link between requirements or user stories and test cases. Since many projects require a systematic method for deriving acceptance criteria, this page presents a procedure based on questioning keywords. The presented method consists of up to five steps.

  1. Identify keywords

  2. Insert keywords in question catalog

  3. Find, check and discuss answers

  4. Define acceptance criteria

  5. Specify test cases*

*recommended for manual test cases

👨‍🏫 Prolog: The benefit of acceptance criteria

Since requirements or user stories are often open to interpretation by different stakeholders (e.g. requirement owners, customers, developers and testers), a common understanding of the actual content must be achieved. In addition, the goals of the different stakeholders may be conflicting, so they need to be sharpened and agreed upon. For this reason, it is necessary to talk about it and establish a common understanding. Defining acceptance criteria in this conversation can be used to concretize the requirements. The defined criteria serve as proof that this communication has taken place and sharpen the mutual understanding.

🏗 The Fundament - Description

User stories typically follow this structure:

As a(n) <Type of user> I want to <Request/Function> to be able/so that <Reason>

Example:
As a user
I want to save my profile
so that I do not have to enter my data again and again.

⚙️ From user story to acceptance criteria and test case in five steps


Step 1: Identify keywords

One way to define acceptance criteria is to ask for keywords. These must first be identified in the user story (description). Keywords are verbs, adjectives and subjects that can be assigned to the category <request/function>.

User Story (example)

As a user I want to save my profile so that I do not have to enter my data again and again.


Step 2: Insert keywords in question catalog

Then it has to be checked if questions - based on the so-called W-questions (who, when, how often, etc.) - can be answered in a meaningful way (a catalog of questions is attached below). Questions that do not allow a meaningful answer in the given context will be ignored. Your question must lead to a meaningful answer and must complement or concretize a user story.

User Story (example)

V_1 - Who must <save>?

V_2 - When should <save> take place?

V_3 - When is <save> completed?

V_4 - How can <save> be performed exactly?

S_1 - Which contents are contained in <Profile>?

S_2 - Which optional / mandatory aspects apply to <Profile>?

S_3 - Which contents of <Profile> and according to which rules should be checked?

S_4 - What does the layout for <Profile> look like?


Step 3: Find, check and discuss answers

Step 3 is for communication between stakeholders to achieve a common understanding of the desired implementation. The answers to the questions allow the definition of concrete acceptance criteria, which must correspond to quality criteria.

Possible quality criteria

Clarity - Completeness - Consistency  - Comprehensibility - Traceability - Identifiability - Freedom from redundancy
Need - Correct level of abstraction  - Correctly derived - Feasibility - Atomicity

User story (example):

Example: Find, check and discuss answers (extract of possible answers)

V_1 - Only the user; there shall be no automatic caching

V_2 - Only if all mandatory fields have been filled in and the content has been checked by e-mail address

S_1 - Names, address and contact data should appear as content in the profile

S_2 - Optional should be the phone numbers and the artist name, all other fields are mandatory


Step 4: Define acceptance criteria

There does not have to be a 1:1 relationship between the stakeholder responses and the acceptance criteria, but several responses can be combined into one acceptance criterion, or one response can lead to several acceptance criteria.

User story (example):

AC_1 - The profile data must come from the fields (first name, last name, artist name, street name, house number, city, zip code, cell phone number, landline number and e-mail address).

AC_2 - The fields artist name, cell phone number, and landline number are optional.

AC_3 - The user can save his profile when all mandatory fields have been filled in and the e-mail field has been checked for the regular expression [a-zA-Z0-9_-.]+@[a-zA-Z0-9.]+a-zA-Z{2,4}.

AC_4 - If the "Save" function cannot be performed, the user must be given a corresponding reason.


Step 5: Specify test cases*

*recommended for manual test cases

The last step is to create test cases that cover the proposed areas.

đź’ˇ
Note: Since acceptance tests often only include positive test cases, i.e. no test cases in which the system is confronted with incorrect entries, these test activities must be executed in an upstream component/system test. Such test cases can also be partially derived from the acceptance criteria.
The following areas should be covered:
Precondition - Test steps to be performed  - expected result - Postcondition

User story (example):

Example: specified test cases(extract)

T_1 - Test invalid e-mail address

Precondition

  • The user has registered, logged in and called up the input page for profile data

Test steps to be performed

  1. Enter values in mandatory fields
  2. Enter invalid value for e-mail address
  3. Click save button

Expected result

  • The save operation is not performed; the database is empty.
  • an error message is displayed indicating an incorrectly entered e-mail address

đź“š Catalog of possible questions

Verbs Adjectives Subjects
Who must <verb>? How is <adjective> defined? Which contents are contained in <substantive>?
When should <verb> take place? Which steps / activities are necessary to perform <adjective>? Which optional / mandatory aspects apply to <substantive>?
When is <verb> completed? How many users are to be considered with <adjective>? Which contents of <substantive> and according to which rules should be checked?
How can <verb> be performed exactly? Which time constraints have to be considered with <adjective>? What does the layout for <substantive> look like?
Where / how can I check whether <verb> has been executed? Which existing guidelines/standards have to be considered if <adjective> is to be implemented?
How often / often / large / fast should <verb> be?
Was it ensured that <verb> considers all data/aspects?
What happens if you cannot do <verb>?
What could prevent <verb> and what is expected then?
Which possible incorrect entries must be intercepted in connection with <verb>?

Read more