What makes a good user story?

What makes a good user story? Is it as simple as just following the format advocated by many Scrum practitioners:

As a <who>, I want <what> so that <why>

For example: as a user I want to be able to add a product to a wishlist so that I can review/buy the product later on.

Originally, I thought it was pretty straightforward, but in a recent discussion at LADG, I realised that it’s not quite that simple – and I wasn’t the only one. Thoughts ranged from a user story being a reminder to have a collaborative conversation about the requirements through to others who thought that a user story should include detailed business logic.

My thoughts are that a “user story” as an item doesn’t contain the Conditions of Satisfaction, constraints, use cases, business logic, etc. A user story should be a brief description of requirements using plain, everyday language that your mum could understand. However, in order for the story to follow INVEST, you will need to have those accompanying items. If you’re doing that, then I think you’re off to a good start.

What is INVEST?

It’s a tidy acronym:

I – Independent
The story should be independent from other stories so that, should something block this story, the other items in the iteration are not affected (domino effect). Obviously this is sometimes difficult, but the more independent each story is, the better.

N – Negotiable
The iron triangle (quality, scope, time and resources) sometimes needs to be broken and the business needs to be prepared to negotiate on what gives.

V – Valuable
If it doesn’t have value to the business, why the hell are you doing it?!

E – Estimate-able
There must be sufficient information available to allow the team to estimate the story.

S – Size / Small
The story should be a good size (i.e. not an epic) to allow the team to be able to complete it within an iteration.

The difference between estimate and size was often confused:

• A user story may have sufficient information to allow it to be sized, but it could be a 100-point story. That is estimate-able but is not a good size.
• A user story might be 2 points, but not contain enough information for the team to give it a size. That is a good size but is not estimate-able (obviously the team won’t know that it’s a 2-point story though)

T – Testable
If you’ve got acceptance criteria / Conditions of Satisfaction, then you should be able to test it (note: this is not how to test the story, but what means the story passes).

 

Did you know? User stories aren’t an original Scrum concept; they originate from Extreme Programming.

 

 

---