moving

Most Common User Story Defects and Tips on How to Write Better User Stories [#UserStories #BetterUserStories #UserStoriesDefects #UserStoriesTips]

1. Ambiguity
2. Inconsistency
3. Complexity
4. Duplication
5. Omission
6. Testability
7. Size

1. Ambiguity
A user story should be clear to the user, the business analyst who wrote it and the developer who implements it.

Do not include words that have multiple interpretations.

And do not include phrases that lack clarity.

A user story should not leave a software developer or Scrum Master with more questions than answers.

2. Inconsistency
A user story shoul not conflict with itself, the epic in which it is included or the application.

3. Complexity
An user story should be simple and straightforward.

If it contains too many forks or subroutines, it will be difficult for a developer to implement.

Furthermore, complexity is often an indication that the business analyst did not properly understand the use case at hand.

4. Duplication
When you aggregate user stories, it is not uncommon to notice some overlap.

Do not waste developer clock cycles with 2 programmers working on 2 user stories that achieve the same objective.

When you organize the stories into epics, filter out duplicates.

5. Omission
There are three parts to a user story.

Each story needs a role, an action and a benefit to be considered complete.

Developers must fix all omissions before they implement a user story.

6. Testability
There is an old saying that asserts, if you cannot test it, there is no point in doing it.

It should not be difficult to create successful criteria that can prove whether a user story is functionally complete.

If it is difficult to test a given use case, how can you expect a developer to effectively code that use case?

Each user story must be testable.

If it is not, a developer will try to kick the user story through a moving goal post.

7. Size
The “size-ability” aspect of user story guidelines ties in with both the testability and complexity criteria.

A user story should be a modular part of a larger epic that is made up of multiple stories.

If a user story approaches the size of the epic itself, it is too large.

It should be possible to complete multiple user stories within the scope of a single sprint.

If a single user story must span multiple sprints, break it down into something smaller.

A user story with a size issue tends to result in excessive cyclomatic complexity.

Make your user story bite-size, not meal-size.

ADAPTED FROM:
The 7 user story guidelines every Agile developer should know
TheServerSide.com