User Story Guidelines

The goal of user stories is not only to document the requirements, but to deliver working software used by customers in production. User Stories provide a mechanism to document the discussion between the customer and developers w.r.t functionality of the software.

Definition

"User Stories represent customer requirements in a card, leading to conversations and confirmation." ~ Ron Jeffries

Template

The following are well known templates used in defining user stories and acceptance criteria.

Value Statement: As a (user role), I want to (activity), so that (business value)

Acceptance Criteria: Given (context), when (action performed), then (observable consequences)

General Guidelines

The following are some general guidelines to consider when writing user stories:

• User Stories have three aspects: Card, Conversation & Confirmation (Ron Jeffries 2001)
• User Stories should represent functionality that is of value to users or system owners.
• User Stories should describe a single feature.
• User Stories should have a note section where conversations are documented about the user story detail.
• User Stories should have an estimation (cost) in story points which indicates size and complexity.
• User Stories should be prioritised according to its value to the customer.

Attributes of good User Stories (I.N.V.E.S.T)

Mike Cohn specifies six fundamental attributes of a good user story in his book User Stories Applied. These are:

Independant (I)

• User Stories should be free of dependencies on other user stories.
• User Stories should be self-contained.
• User Stories should be completed and released in any order.
• User Stories should be combined or split in different ways when dependencies occur.

Negotiable (N)

• User Stories should not be contractual obligations as they are negotiable.
• User Stories should be a collaborative negotiation between customers, developers and testers.

Valuable (V)

• User Stories should be of value to the user or owner of the software.
• User Stories should not be only of value to developers.
• User Stories should clearly define the benefit to customers/users to assist in prioritization.
• User Stories should be written by customers to ensure it is valuable to customers/users.

Estimatable (E)

• User Stories should be estimated in terms of story points.
• User Stories should be clearly understood before it is estimated by development teams.
• User Stories should contain enough detail before it is estimated by development teams.
• User Stories may not be estimatable when development teams lack domain knowledge.
• User Stories may not be estimatable when development teams lack technical knowledge.
• User Stories may not be estimatable when the user story is too big.

Small (S)

• User Stories should be as small as possible while still providing user value.
• User Stories should be able to fit into one iteration.
• User Stories that are to big will be difficult to understand and estimate.

Testable (T)

• User Stories should be verified by tests to prove they are implemented correctly.
• User Stories should contain the story acceptance criteria to guide testing.
• User Stories should be easily unit tested. (Technical Implementation)
• User Stories should be easily acceptance tested. (Behavioural)
• User Stories should be tested in an automated manner where possible.

Story Point Planning

• Fibonacci ( 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ?, Pass )
• Modified Fibonacci ( 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, Pass )
• T-shirts ( xxs, xs, s, m, l, xl, xxl, ?, Pass )
• Powers of 2 ( 0, 1, 2, 4, 8, 16, 32, 64, ?, Pass )

Definition of Done (DoD)

There are numerous criteria a team can use to define their Definition of Done. This ensures that teams deliver features that are completed in terms of functionality and quality. Definition of Done is an auditable checklist. The following is a set of possible criteria and activities for a DoD:

• Unit Tests Passed
• Acceptance Criteria Met
• Code Reviewed
• Functional Tests Passed
• Non-Functoinal Requirements Met
• Product Owner Accepts User Story

User Story Example

The following is an example of a user story.

Reference

• Cohn, Mike. User Stories Applied: For Agile Software Development. 1st ed., Addison-Wesley Professional, 2004.
• Wake, William C. Extreme Programming Explored. Addison Wesley, 2002.