User Stories in Scrum
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.
- The Purpose?
- When? What
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
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.
However, a documented User Story is not the main-part, but the associated communication between the team and the product owner.
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.)