A good story is:

  • Independent
  • Negotiable
  • Valuable to users or customers
  • Estimatable
  • Small
  • Testable




Care should be taken to avoid dependencies between user stories.

Dependencies lead to prioritization and planning problems.



Stories are negotiable. They are not written contracts or requirements that the software must implement.

Because story cards are reminders to have a conversation rather than fully detailed requirements themselves, they do not need to include all relevant details.

However, if at the time the story is written some important details are known, they should be included as annotations to the story card.

It is useful to think story card to contain:

  • A phrase or two that act as reminders to hold the conversation
  • Notes about issues to be resolved during the conversation




Story size does matter because if stories are too large or too small, you cannot use them in planning.

The ultimate determination of whether a story is appropriately sized is based on the team, its capabilities, and the technologies in use.

Splitting Stories

Epics fall into one of two categories:

  • The compound story
  • The complex story




Stories must be written so as to be testable.

Successfully passing its tests proves that a story has been successfully developed.

If the story cannot be tested, how can the developers know when they have finished coding?

Whenever possible, tests should be automated. This means strive for 99% automation, not 10%.