Each User Story that the team considers ready for work must be as independent from other stories as possible. Independent means they are free from dependencies on other stories which means they can be worked on and implemented in any order.

We rarely achieve complete independence, but we seek to minimise dependencies and the constraints on sequencing of work that result, and on our ability to adapt to change.

User Stories are not contracts for features. The Team and the Customer co-create the details of each User Story over time to express the essence of what’s needed. The need must be described to a sufficient level of detail to allow prioritisation, planning and, ultimately, implementation.

The collaboration around User Story refinement can and should continue through development with additional detail, notes, and tests being added to help achieve a successful implementation.

A User Story should be valuable to the customer. Many teams find it useful to follow a pattern to write their User Stories. for example:

In order to [realise some desired value or benefit],
As a [specific type of user / persona],
I want/need [a specific feature or function].

The pattern is valuable because it encourages the team to lead the definition of each User Story by expressing the value it will deliver to the user.

To split stories into smaller stories, we slice the story so that the smaller stories encompass all layers of the solution architecture - database layer, Business logic layer, front-end layer. Like a slice of cake, you wouldn’t cut the top off; you cut a slice through all layers to give the full essence of the cake.

It should be possible for the User Story to be estimated to a reasonable degree. To do this the team would consider a number of factors such as the skills available to do the work; theTeam’s familiarity with the context of the work; the degree of ambiguity remaining in the User Story definition; the level of complexity of the work; and the team's level of confidence.

To constrain the time and effort expended in estimation an Agile Team will adopt ‘relative estimation’ which involves estimating tasks or user stories by comparison or by grouping of items of equivalent characteristics, not estimating each story separately in absolute units of time.

We make each User Story small enough to keep the cognitive load of the team low, enable a small engineering batch size, achieve a high-level of shared understanding, and maximise our ability to pivot in sprint.

Each User Story is a unit of value to the customer, which may impose a minimum size so that we can deliver all layers of the solution architecture. Since we want to deliver value early and often, Teams will endeavour to size Stories so they can be completed within a Sprint. Teams will consider their rate of delivery to understand how much work can be done in an iteration/Sprint.

A small Story will be easier to comprehend, so we will have more confidence in our estimates. Working in small batches reduces risk at every stage throughout development and implementation.

A good User Story must be testable. Thinking about how to both verify and validate the User Story helps define the work involved, and demonstrates a good understanding of what makes the item acceptable to the customer.

If you can’t define how you will test something, it may indicate a lack of understanding of what’s really needed.

Test Driven-Development (TDD) is an approach that defines and creates necessary tests during design activities. The set of necessary tests constrains the scope of the development work, helping the team to avoid work that is not required by the User Story definition.