User Story Applied 에서 발췌

Independent

• As much as possible, care should be taken to avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and planning problems.

Negotiable

• Stories are negotiable. They are not written contracts or requirements that the software must implement. Story cards are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team.

Valuable to users or customers

• Each story must be valued by the users.

Estimatable

• It is important for developers to be able to estimate (or at least take a guess at) the size of a story or the amount of time it will take to turn a story into working code.
• Even though they are too big to estimate reliably, it is sometimes useful to write epics such as “A Job Seeker can find a job” because they serve as placeholders or reminders about big parts of a system that need to be discussed.

Small

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

Testable

• 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?
• Untestable stories commonly show up for nonfunctional requirements