Writing user story is not only an art but also science

Everybody says focus on below 6 attributes to write a good user story and same is true but following these six attributes while creating story requires science and arts both.

Below is detailed explanations of all six attributes.

Independent

Dependencies in the stories lead to planning & prioritization issues so we should try to create stories as independent as possible. There could be two tricks to resolve dependencies:

Combine the dependent stories and create slightly large but independent story. – This is not suggestible

Split stories slightly different – This can be done easily if you are having good engineering practices like TDD. You can split in smaller stories and develop stories after mocking dependencies.

Example –

1. Search available Air France flight between London and Paris
2. Search available British Airways flight between London and Paris

Negotiable – Stories are not written contracts or requirements, which are hard to change. Stories should contain basic information and other notes about issues to be resolved during conversation. The details can later be negotiated between customer and development team.

Example –

1. Searching only direct flight between London and Paris or also including stop over?
2. Search will also show combined flights?

Valuable – Story should be valuable for user or purchaser. The details which are very specific to IT processes and technology could be valuable for development team but make no sense for customer/user. Let’s take few examples:-

1. All services should be exposed using RESTful services
2. All error and logging should be handled through Jlogger

But same can be presented in much better way for customer like below

1. User should see same data through web or mobile
2. All error should be logged in same way and presented to user

Estimatable – The possible reason why story might NOT be estimatable are team lacking technical/domain knowledge or Story being too large.

In case of issue with domain knowledge customer should talk to customer and try to gain domain knowledge.

If problem is with technology knowledge, team can conduct a spike i.e. a short time-boxed activity to research/experiment to learn enough to be able to estimate.

A large story should be disaggregated into smaller constituent stories so that these can be estimated more confidently.

Small – The story should be of right size, not too big or too small.  What is ‘right size’ depends on the team, its capability and technology in use. In case of very small stories, consider combining the stories. If story is large then split it in many small stories.

Example of splitting stories.

Big story – User should be able to search all available flights between London and Paris

Split it in many stories like below

1. User should be able to search all Air France flight between London and Paris
2. User should be able to search all British Airways flight between London and Paris

Testable – Stories must be written so as to be testable and should not be like below.

1. User Interface loading should be faster (How much?)
2. Software should be easy to use (How do we know what is easy?)

Better to have something like below

1. User Interface should get loaded in 30 seconds
2. Software should have a help button associated with every mandatory fields to explain what is needed