Writing Engaging User Stories

A user story is a small unit of work that captures the requirements and description of the product feature from an end-user perspective. A user story is usually delivered in a single iteration of an agile framework sprint.

Components Of a Well Written User Story

Description/requirements:

1. Who: our target end-user using the service or product.
2. What: what action do we want the end-user to perform.
3. Why: why is the above action important and what value does it add to the business E.g. As a ___, I want ___, so that ___ format answering Who, What, and Why?

Acceptance Criteria:

1. Confirms when a Story is completed and works as intended.
2. Demonstrates functionality to Product Owners at the end of the feature release cycle.
3. Performance benchmarks are met.
4. All supporting documents like design documents, architectural diagrams, testing specifications, product specifications, user guides, and deployment guides are signed off and meet the quality bar of the organization.
5. Acceptance criteria must be expressed clearly as to what the expected outcome is:
   1. What is acceptable and what is not acceptable.
   2. They must be testable: easily translated into one or more manual/automated test cases.

Dependencies:

User story dependencies are identified and linked in the story. This includes User story collateral (wiki pages, documents, images, etc.). Dependencies may include names of important stakeholders who will provide more clarity about the story and/or sign off on various aspects of the story’s execution.

Characteristics of a good user story

The INVEST model describes the characteristics of a good user story.

1. I - Independent

   1. Independent user stories can be implemented in any order.

   2. Can be traced, tracked, tested, etc. on its own.

   3. Although, having independent user stories may not always be achievable, but linking one user story to another may reduce the amount of work another story needs and can bring some order in the larger feature execution timelines.

2. N - Negotiable

   1. Focus on the essence, not the details in the user story. Keeping the details out allows for the evolution of the story as time progresses.

   2. Details are worked out over time as user story takes a concrete shape and form in subsequent sprints.

3. V - Valuable

   1. End user is our focus, user stories should be ‘valuable’ to the end user.

   2. Capture the importance of external impact (to the end user) and clearly describe the value (for the end user).

   3. Have a large feature and need to split into multiple user stories?

   4. Instead of splitting up the feature "horizontally" (having one story to complete the database layer and another to complete the logic layer) try to have each story result in a completed item that contributes to the overall feature. Imagine user stories like slices of cake – want to serve all layers of the cake by vertical slicing to include all layers.

4. E - Estimable

   1. Estimate approximately how long each story should take.

   2. In general, larger stories are harder to estimate than smaller stories could be due to dependencies on other smaller user stories, external dependencies, etc.

   3. Confidence in estimation will be a function of the team – experience, unforeseen interruptions like pager duties, customer issues, etc.

5. S - Small

   1. Well-defined user stories are small.

   2. Ideally, stories should last for one sprint.

   3. Scoping a user story so that it can fit in a sprint can be challenging if there are are a lot of unknowns (usually at the beginning of a new feature execution).

   4. Small user stories tend to have accurate estimates.

6. T – Testable
   1. Good user stories are testable and testing requirements are usually baked in as part of requirements.
   2. User story estimates should account for testing time (unit testing, integration, acceptance testing, etc.) as applicable.
   3. Lack of being able to test the user story could mean the user story and its requirements are not understood well enough.