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.
- 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…”
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
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