Skip to content

Agilitypedia – User Stories

November 16, 2011

What are user stories

A user story is simply something a user wants.

A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

In short, user stories are very slim and high-level requirements artifacts.

Why Stories?

  • Words are imprecise:
    “Entree come with soup or salad and bread”
    What does this mean? : (soup or salad) and bread OR Soup or (salad and bread)
  • Everyone understands a story – user, customer, developer..
  • User stories lead to participatory design
  • Stories focus on value (end user needs) and not technical requirements
  • Enough info to understand What customer wants
  • They are not detailed enough to limit Team’s decision on how to do it

How to write US

A format that can be used is 3c’s : Card, conversation, confirmation

This step is about materializing the Item – writing down the Story text on a index card


As in example above, you can write your user stories using the format: “AS A.. I WANT.. So that…”,
but you can also use others as “Given… When… Then…”
Or …
WHATEVER MAKES SENSE – a story that:

  • is clear for everyone,
  • clearly states the end-user need/ request
  • makes sense to everybody and so all agree with that description

HINT Not rarely I’ve seen some US that are so straight forward that after a few iterations no one can remember what was the end-user request. Be concise and objective, but write down the US is a way that anyone can read it and understands what needs to be done.

Along with the Story you can also add the Story number, Priority, Size and Conditions of Satisfaction.

This is the MOST IMPORTANT step while writing/ analysing User stories:

Conversation between Customer (PO) and people doing the job (architects, developers, testers, writers,..) is vital and will define the success of all activities.
Discuss and get common understanding at least on:

  • US scope
  • Conditions of satisfaction
  • Assumptions

Also this is the right time to make clear any dependency specially between teams – If your team needs to talk with or work with some other team, this should be written and acknowledge by all. Inter working is a must in such a big company and within such complex and geographically spread projects as ours.
A great way to perform this conversation step is to specify the user story by using examples (end user examples) – this way everyone will have the same understanding on what is to be achieved.

Agree on acceptance tests, that in the end will confirm we build the right thing the right way

Everyone from the Scrum Team agrees on US scope, assumptions and how this US will be accepted.

A good story has six attributes:

I ndependent – does not depend on other items
N egotiable – it’s not a fixed contract – through conversation a simpler definition (or acceptance) can arise
V aluable – to users or customers
E stimation – it can be estimated
S mall – can meet DoD in less than a 1/3 of sprint by the team working together
T estable – acceptance tests are clear and can be automated
If the Story is not INVEST(ed), then it should be refined during Refinement session (or grooming).

HINT During US discussions (planning, refinement, demo, ..) there’s a lot of information going on, and sometimes, we miss to take notes and write down everything we decide about that Us: dependencies, assumptions, tricky stuff, ..whatever! So, my Hint to you is: don’t stop taking notes – write down or take pictures of all being discuss because you’ll need it later and you won’t remember . I wouldn’t .



Check out Mike Cohn’s Blog as one of the most concerned writers on US_


User stories applied Mike cohn
Agile Estimating and planning – Mike cohn
Bridging the communication gap
Writing Effective Use cases – Alistair Cockburn

Bill Wake – INVEST Technique


From → Agile

  1. I think the “small” aspect is important but it’s the achilles heel of user stories.

    How many “user stories” really are small enough to fit into 1/3 of a sprint?

    It seems that “user stories” are intermediate artifacts that in many/most cases need to be broken down into tasks to execute on.

    So, I really don’t see the value in user stories — most user stories will span sprints (so called epics) and the programmers are then executing against tasks and not user stories. I’m not sure what other peoples experience has been in this area but think that is a good topic for discussion.

  2. Hi Jordan :)

    Thank you for taking some time and post your thoughts :)
    You are absolutely right: it’s not easy to keep US small. But, that doesn’t mean it’s not possible, right?

    One thing I’ve found pretty useful until now is to give space, time and stakeholders availability, for teams to perform their Requirements workshops during Sprints.
    By stakeholders I mean all people relevant for the team to understand what’s the US about: Product Owner (customer) and (if you work with non-cross-functional teams) people for Architecture, UX, Testing, Customer documentation.. i mean : all people that work in the product.

    Additionally to Requirements WS it’s really really useful to apply Specification by example as the technique to get a common understanding bout the US and break it in smaller, manageable, incremental pieces.

    It’s not easy. Nobody said it would be, but then again, nothing worthy in life is easy. Even simple things, as running, needs hard work in order to improve and get best results.

    BTW: what do you use as Product backlog items?

Trackbacks & Pingbacks

  1. Ways of communicating, how we learn | SCRUMPLICITY

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: