Meticulously working on stories to make sure they have all the requirements from the business or customers is just one tiny-little part (of many) needed to achieve movement on the board. Here are some of the common areas-of-improvement you may find in your user stories - if you were to look carefully.

Your user stories need improvement when

• a story independently does not deliver any value to the end user.
• a story does not deliver any value to the end user.
• a story lacks a clear goal or analysis depth.
• a story is merely a technical task written as a story.
• a story is missing acceptance criteria.
• a story is either too big or too small.
• a story is trying to provide multiple items of value.
• a story does not have a clear user defined.
• a story is too rigid that it stops innovation and creativity on its tracks.
• you or the business start blaming user stories.

Too much? Well, while stories are the building blocks of a great product or service, it becomes extremely important to make sure there is some sort of consistency in size, analysis and value at the very least if not all of the above.

Creating Good User Stories

A user story is an opportunity to have a future conversation about what the users need. There is no one person that should be writing stories - the whole team should feel empowered to write a stories and share them with the team for feedback.

A Good User Story

A good user story is user-centric, estimable, testable and complete enough to provide a user with some value (often through a specific functionality) once it's done.

Key Definitions

There are 2 definitions that a Product Owner creates with the team and always keeps these handy or sticking at a place highly visible to everyone.

Definition of Ready (DoR) It is a working agreement between the team and product owner on what readiness means or in other words a way for a product owner to indicate an item in the product backlog as ready to work in sprint. It helps measure the ready state of items in the backlog and reduce the pressure on the team to commit to estimates before stories are ready i.e. meeting the DoR.

• Sample: A story is ready to be picked up by the team when it has a definition, acceptance criteria, design artefacts attached (if needed), estimation and there is no outstanding question remaining.

Definition of Done (DoD) Done means every task under the user story (or the user story itself) has been completed and any work created is attached (or linked) to the user story (or in comments) so the product owner can review it and make sure it meets his or her expectations.

• Sample: A story is done when it's coded to standards, reviewed, implemented with unit Test-Driven Development (TDD), tested with 100 percent test automation, integrated and documented.

With these key definitions in place, you can always nurture your stories and get traction on the board, both physical and digital.

Scenarios

In the age of behavior-driven development (BDD), scenarios in acceptance criteria become key to the success of the story. Here is a common framework that works like a charm for writing scenarios in acceptance criteria, GIVEN some context, WHEN an event happens THEN an outcome is observed. This can be extended like, GIVEN some context AND an the event happens, WHEN another event happens AND some additional context THEN an outcome is observed AND another outcome is triggered.

These scenarios add a lot of value to your acceptance criteria giving the developers more understanding on how their code has to work with changes in behaviour of the users using the product or service.

Do you have any other tips?