User Stories 101 – The format of a story
There is an accepted format for user stories, and though there are variations, the fundamentals are widely used.
AS a I want so that
Example: As a registered user, I want to log into website A, so that I can access my online courses
Do you remember, our initial user story in yesterday’s post: Mum says to her twelve year old boy, “can you get me at least a litre of the best value milk”
This story focuses on the Goal only, ignoring the user and the reason why. That is what I would regard as a typical requirement, one that many analysts were comfortable with designing.
But agile user stories attempt to deepen that thinking.
By asking who wants this requirement, we start to think more closely about our customers and users. We begin to seperate them into different groups and then sub divide those groups in our head. At a fundamental level, we are now starting to focus on those customers.
By asking why we want this requirement, we are really asking if there is any value in this. Putting the two together we have a question: “what value is i this requirement and who is that value for?” Let me be blunt, if you can get your team thinking like this, you are on your way to success.
But let’s not get too excited. This shift to value and customer centricity is not easy. It is dificult to get people engaged with topics that have traditionally been ignored.
Let me end this section on user story format by talking about the characteristics of a good user story.
Back in 2003, a gentleman involved in agile named Bill Wake sat down and pieced together a set of criteria for a good requirement,
He came up with the INVEST model
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
Independent
Independent stories are those that do not overlap with other stories. They are self contained and can be delivered seprate to any other user story
Negotiable
User stories are a placeholder for a conversation, they are not a set in stone deliverable. We want people to discuss them, debate them, evolve them rather than just read them and carry out the instructions
Valuable
It must deliver value to our customer. Value is a topic in itself but let me just say that you need to first set out what is valuable to you before you can gauge each story against that value.
Estimateable
There is an old saying, if you cant measure it, you cant manage it. At the same time, be aware that estimates are just guesses. They should not be accepted as fact.They should be used to provide steer. Knowing that one user story is huge while another is very small will help you determine what to do next, especially when you merge it with our understanding of value.
Small
It is always a balancing act with user stories between a user story that is too big and one that has been subdivided (split) until it became too small. But there is an acceptable middle ground but that middle ground is in the SMALL region.
Testable
A good user story needs to be testable.
If it is not, then it could be that it is not clear enough, perhaps the value is not identified or that you need help identifying the tests. Testing is also a crucial step in determining if an item is complete
A word of warning, the format and criteria listed above, are all simple to understand, but difficult to implement.
My advice is:
- Before you begin, work with the team to establish a set of personas representing your customers and users to start the thinking process
- Define what is valuable to your product and get it agreed and understood by the team
- Train the team in writing user story
- Have a plan for sustaining the engagement of the team in the user stories format
- Establish a community of practice with a focus on user stories.
You need to work hard to achieve the focus and benefit that user stories brings.
Good luck!
To Be Continued
