User Stories in Scrum

Written by Marvin Siegert

User Stories in Scrum

Monday, 31 August 2015 00:00

Requirements are often described very technically. Problems with understanding may arise between the different departments within the company. Why don’t we therefore document our requirements from a user-perspective?
With the agile Software-development Scrum, WidasConcepts relies on User Stories. A User story serves towards demonstrating an accurate description of a feature and this from the perspective of a person who ultimately uses this feature. But how do I form such a user-story?

1 The 7 simple questions

Basically, the following 7 questions should be thoroughly dealt with and answered.

  • Who?
  • What?
  • The Purpose?
  • Where?
  • When?
  • What
  • How?
  • Why?

As WHO, I want WHAT, so that I SOLVE PURPOSE
The first three are the most important here.
As (“Who”) I want (“What”) so that I <get use> (“Purpose”)
The question “Where” stands for the Context. As to where in my application should the function be available?
The question „When“ stands for the timely-flow. Here, dependencies towards other features or legal requirements can play a role.

The answer to the question „How” should describe how the function should be implemented. Here, one can describe how exactly one had imagined the construction of the feature. In Scrum, it is however common, that the team decides over the “How”.
The question „Why” is not to be confused/ is not the same as “What purpose”. The question that looks for the use is questioned with “What purpose”. The “Why” is the question that looks for the reason.
A possible reason would be for example a legal requirement/ a statutory regulation.

2 Acceptance criteria

When one has answered the questions, then the team has pretty much a clear understanding of what the task is all about and what should be the end outcome of it. In order to exactly define this function and to make it ready for testing, acceptance criteria (success criteria) must be defined, as the next step. An acceptance criteria should here be capable of being covered by exactly one test-case Example:
1. A House would be built from Lego blocks
This success criteria can be more accurately specified as per each of the ideas
2. A red House would be built from Lego blocks
3. The House has a flat roof
4. The house is atleast 30 cm high
With this data it should be pretty clear, as to what the idea-giver (Client) had in mind.

3 Example User Story of Smart City

As a resident of Smart City, I want to be able to open my house door without any keys just by carrying around an RFID chip





Success criteria:

1. A Lego House with a door would be built

2. Mounted beside the door are 3 LEDs (green, yellow, red)

3.Mounted beside the door is an RFID-Reader

4. The green LED is on, when the door is open

5. The red LED is on, when the door is locked

6. The door opens for 5 seconds when a specially coded RFID chip comes close to it.

7. If an incorrectly coded RFID chip comes close to the door, the red and the yellow LEDs blink alternatingly; for 5 seconds.

4 DoR – Defintion of Ready

To detach a story each team has a definition of Ready (DoR). This avoids ambiguities that need to be clarified during the Sprint and the Sprint objective is not jeopardized.


Definition of Ready (for Sprint)

1. The Story is fully understood by Team

         a. The Story has a distinct, unique title.

         b. For Whom What, Why (user groups / personas / technical developers, etc.)

         c. Concepts are clear, descriptions are free of contradictions

         d. The „User“of Story-(Part)-Results („As x I want…“)

            is defined

         e. Standard-Story-Pattern: „As x I want y, to reach z“

            x, y and z are respectively defined

2. The Story is removable

         a. Success criteria are clear, measurable and verifiable by acceptance tests

            Formulated as (Functional + non-functional)

         b. Between PO<->Team (DEV/UX) coordinated

3. The Story is assessable

         a. Has at least one implementation Sketch

         b. Dependencies are shown (e.g. contact person for coordination,

            another story)

         c. It is up to the Team as to how they will technically implement the Story under

            Compliance with the DoR and success criteria

4. The Story can be completed in a Sprint

         a. The complexity of the Story may not exceed X points

            (8-13 as per each Team)

         b. Dependencies are taken into consideration and if necessary, counter-measures are initiated.

5. All o.a. information is documented

         a. All success criteria and requirements and needed documents are

            either linked or placed as attachments.

         b. Comments serve as the communication, are but not a component of the Story.


However, a documented User Story is not the main-part, but the associated communication between the team and the product owner.

5 Conclusion

User Stories contribute not only towards a uniform understanding, but at the same time demonstrates the value of an assignment/task from the user perspective – our customers. In addition, you underline the verbal communication and also will be understood by people with no technical background. (Give me a use and I will give you the Function towards it that you wished for.)