Imagine you are buying a car. You have ordered your dream model that will allow you to travel long distances with your family. In the car showroom a salesman, presents to you a bright red, two-seater, sports car with a huge spoiler. He says that it reaches 100 km/h in 3 seconds. „But how am I supposed to take my family on holiday in this car? It’s only got two seats!” you say. Salesman replies: „Well, maybe you cannot, but think how fast it is!”. This example might be a little extreme, but misunderstandings happen all the time, even in programming. STATSCORE always places customers satisfaction as a priority and in order to do that, we need to meet the expectations.
How do we do this? Do we sent our developers to mind reading courses? No need, that is where user stories come to the rescue.
A user story is a set of requirements described from the customer’s perspective. That allows a scrum team to fully understand, what do the customer need. Usually it contains a description, acceptance criteria and a scenario.
TELL US WHAT YOU NEED: DESCRIPTION
The most common way to create the description is answering these three questions: Who? What? Why?
Who? – type of user for whom the issue is going to be delivered
What? – what the customer will be able to do?
Why? – why will it add value for the customer
The last W is often omitted, but it gives a developers team an idea about the context in which a new feature will be used. Here are some description examples:
As a user
I want to be able to set my password so that I can protect my profile from unwanted access
As a customer
I want to receive e-mail notifications about discounts, so I can get the latest informations about the best offers
ACCEPTANCE CRITERIA (AC) EXPLAINED
The aim of the acceptance criteria is to precisely describe when the issue can be considered completed. That is why it is extremely important to make the acceptance criteria clear and verifiable. They are a result of cooperation between customers and a team of developers. A full list of criteria is required before starting work on an issue.
The acceptance criteria should not be something complicated. It’s just a set of logical requirements that allows us to decide if a developed feature meets the customer’s expectations.
Benefits of using AC:
– preventing misunderstandings between the customer and the development team
– giving the customer a better vision of what the new feature will look like
– allowing the development team to estimate the amount of work required to complete the task and separate the criteria into separate issues (if needed)
Another example of how the acceptance criteria works, and we are going to use the two previous descriptions to make it easier to understand:
As a user
I want to be able to set my password, so that I can protect my profile from unwanted access.
Acceptance Criteria:
- password has to contain at least 8 characters
- password has to contain a capital letter, a number and special character
- in-putted password is presented in a form of dots, but a user is able to switch the view and see the characters
- after typing a password that does not meet the requirements, a user should see a red message <message text>
As a customer
I want to receive e-mail notifications about discounts, so I can get the latest information about the best offers.
Acceptance Criteria:
- notifications should be sent between 8 am and 8 pm in the user’s time-zone
- user should not receive more than two notifications daily
- notification’s size should not be bigger than 1 MB
SCENARIOS TO HELP THE USER LEARN
A scenario is used to illustrate the way in which a user is going to use the new feature. Typical scenario contains three elements: Given (initial conditions), When (action taken) and Then (result).
Let’s take a look at these examples:
Scenario: Creating a correct password
Given: As a new user I’m viewing a „Create a password” page
When: I input the correct password and click „Save password”
Then: I see a green „password created successfully” message
And: I am redirected to the Home page
Scenario: Inputting an incorrect password
Given: As a new user I am viewing a „Create a password” page
When: I input password that does not contain a number and click „Save password”
Then: I see a red „password should contain a capital letter, a number and special character” message
WHAT IS THE LESSON
It’s worth investing time in writing good user stories. How? A good way to do this, could be by using the INVEST rule.
I (Independent) – every issue should be independent
N (Negotiable) – a user story allows for further negotiations between the customer and the team
V (Valuable) – each user story should add value for the customer
E (Estimable) – the team should be able to estimate the amount of time for completing the issue
S (Small) – big stories (epics) should be separated into smaller, more digestible pieces
T (Testable) – a tester should be able to test the issue to call it done
AVOID THE COMMON MISTAKES
Finally, let us have a quick look at some of the most common mistakes when writing user stories:
- Including a solution as a part of the user story.
The user story should describe what should be done, instead of how it should be done. (e.g. the customer should describe a colour for his new car, rather than explaining exactly how to apply the paint.)
- Not providing enough information
For example, a missing user’s role, acceptance criteria not specific enough, no information about the value, etc. - Lack of cooperation between the customer and the team when writing a user story.
- Descriptions too broad
A short description and 3-5 acceptance criteria will be enough.
- Requirements added to the Why? section.
Quick example: As I user I want to save my shipping list, so that I can duplicate and print the list.
In this example “duplicating and printing” are separated requirements that have been added to the „why?” section. „Why?„ should only contain business added value.
To sum up, those few simple pieces of the puzzle, put together will give you a recipe for the perfect user story. The customer then can relax, being sure, that the developing team know exactly what to do. Putting some time and effort in creating a good user story, adds great profit to the rest of the workflow.
This is what we do at STATSCORE. We always take care, to provide our partners with software that will help them reach their business goals. If you want to become part of the STATSCORE team, visit our career page and join us, as we build the biggest sports data centre in the world.
1 Pingback