Guia PES

Agile requirements

User stories you can build, test and estimate

The backlog is the heart of the project: when stories are well written, planning, estimating and proving progress become easy. Here are the template, good and bad examples, and a couple of games to practise.

The template

Every story says who wants what and why. The "why" is not decoration: it is what lets you prioritise and decide when the story delivers value.

You may write them in Catalan, Spanish or English, but always with the same template. Stories are grouped into epics, broken down into tasks and sized with story points.

As a cyclist, I want to see stations with free bikes near me so that I do not walk for nothing.

Com a ciclista, vull veure les estacions amb bicis lliures a prop meu de manera que no hagi de caminar en va.

Como ciclista, quiero ver las estaciones con bicis libres cerca de mí de manera que no tenga que caminar en vano.

Tap each letter

INVEST: six checks for every story

Before and after

Five stories, rewritten

Examples from a mobility app built on the Bicing open data.

Build the /stations endpoint with Express.

A technical task: it does not say who wants it or why.

As a cyclist, I want to see stations with free bikes near me so that I do not walk for nothing.

The endpoint becomes one of this story's tasks.

As a user, I want a social network for cyclists.

Too big: it is an epic, not a story.

As a cyclist, I want to follow other cyclists so that I see their routes in my feed.

One concrete piece of the "Community" epic.

The app must be fast.

An NFR nobody can check.

Criterion: 95 % of non-search requests answer in under 1 second.

Measurable, and checked in every story it applies to.

As a user, I want a green button at the top right.

Imposes a solution and does not say what it is for.

As a user, I want to book a bike from the map so that it is guaranteed when I arrive.

The button design is decided in the mock-ups.

As a user, I want to log in.

No benefit, no criteria: when is it done?

As a user, I want to sign in with Google so that I do not have to remember a new password.

Criteria: works with a valid account, shows a clear error on cancel, the session lasts 30 days.

Acceptance criteria

They add the missing detail to a story and state exactly when it is fulfilled. They are validated by acceptance tests, ideally automated. Write them in Taiga, inside each story.

A format that works very well is Given / When / Then: context, action and expected result.

At Fag-2 you are already expected to have the most important criteria of every backlog story, even if not in full detail.

Given I am 300 m from two stations
  and only one has free bikes
When I open the map
Then I see both stations
  and the one with bikes is highlighted
  with the number of available bikes
Given I have no connection
When I open the map
Then I see the data from the last load
  with its update time

Non-functional requirements (NFRs)

Story points and planning poker

Points are an abstract measure of complexity, not hours. Use a scale such as 1-2-3-5-8-13 and size each story by analogy (it resembles another), expert judgement or disaggregation (splitting it in your head).

Planning poker combines all three: everybody votes at once; if votes are spread out, the highest and lowest voters explain and you vote again. Try it here with a simulated team:

When to split a story

  • When it is still too big for a sprint, or it would fit but there is no room left.
  • Split it by data (stations first, bike lanes later), by functionality (view, filter, book), by removing cross-cutting concerns (languages separately) or by priority.

How to prioritise

Financial value, development cost, new knowledge it brings (about the product and the project) and the risk it removes.

Practise

Quick quiz: six questions