User stories

User Story is a small (actually, the smallest) piece of work that represents some
value to an end user and can be delivered during a sprint.
Story: As a [persona], I [want to], [so that]
Description
Acceptance criteria
Pre-condition: steps

How to make use stories:

• Make up the list of your end users. Define what their “pain” or “need” is,
which you’re trying to solve.
• Define what actions they may want to take.
• Find out what value this will bring to users and, eventually, to your
product. Also ask yourself - will any party pay us for this?
• Discuss acceptance criteria and an optimal implementation strategy.

User Stories always fit the INVEST set of criteria.

Independent – they can be developed in any sequence and changes to one
User Story don’t affect the others.
Negotiable – it’s up for the team to decide how to implement them; there is no
rigidly fixed workflow.
Valuable – each User Story delivers a detached unit of value to end users.
Estimable – it’s quite easy to guess how much time the development of a User
Story will take.
Small – it should go through the whole cycle (designing, coding, testing) during
one sprint.
Testable – there should be clear acceptance criteria to check whether a User
Story is implemented appropriately.
Pre- condition
Acceptance Criteria (is a set of conditions that are used to confirm when a
Story is completed).
E.G:
As a passenger, I want several available drivers to be displayed so that I can
choose the most suitable option for me.
What acceptance criteria can be applied to this Story?
The app shows drivers that were online within last 20 minutes and don’t have
an ongoing ride.
The app shows only 5 drivers that are closest to the user.

E.G:
As Sascha, I want to organize my work, so I can feel more in control.
As a manager, I want to be able to understand my colleagues progress, so I can
better report our success and failures.