When is a user story "ready" for dev?

In the Software Development world we have different tiers of requirements, the largest being an Epic, then a Feature, with the most granular level of requirement being a User Story. Each tier down increases in detail.

If we wanted to build a house our Epic, Feature and User Story would look something like:

Epic	House build 2024
Feature	The house needs a bathroom
User story	As a Home Owner, I want a sink in the bathroom, so that I can wash my hands, face etc.

In this article we are focusing on the user story, and when a user story is truly ‘ready’ to be handed over to the Development Team and be worked on.

What is a User Story? Why do we have them?

In simple terms, a user story is a non-technical requirement, written from the perspective of the end user.

Its purpose is to demonstrate how the requirement will bring value to the end user, and to align all stakeholders involved as to what the output of development will be.

A User Story doesn’t usually need to get into the technical detail of how something might be achieved – it’s a description of what the end result does.

When is a User Story Ready for Development?

Before starting any development on a user story it’s important that the key stakeholders understand and agree on the requirements.

In order achieve this we have devised a six step checklist for your User Story

1 - The user story has business value

The reason we write from the point of view of the user, is so that the thing we’re asking for is closely connected to a purpose, to real users and to business value.

Ideas that don’t have any business value will be hard to turn into a user story in the approved format, because you won’t be able to put yourselves in the shoes of a user who actually needs it.

2 - The user story written in the universally recognised format

A clearly written user story helps communicate the goal to the whole team.

The format for writing an agile user story is:

“As a <user/ role/ persona>, I want <goal>, so that <purpose/ motivation>”

To simplify writing a user story it’s important to break it down into three parts. It is easier to write and easier to understand like this.

Here are some questions to ask yourself when identifying the persona, goal, and purpose of a user story.

• Who – As a <user/ role/ persona> – Who are we building this functionality for?
• What – I want <goal> - What is this user/ role/ persona trying to achieve?
• Why – So that <purpose/ motivation> - What is the benefit we’re trying to deliver, or problem we are trying to solve?

Here are a few examples of what user stories might look like from different end users perspective:

• As a Home Owner, I want a sink in the bathroom, so that I can wash my hands, face etc..
• As a Marketing Manager of a media streaming service, I want to be able to find out the most popular film genres, so that we can provide more films within these genres to our customers.
• As a Customer of a large retail company, I want to receive email updates on my order, so that I know when my purchase is going to be delivered.

3 - Detailed acceptance criteria have been written

A user story should include at least one acceptance criteria. This is how you make sure a user story is fit for purpose, is bespoke and meets the goals of your end user.

Acceptance criteria should be specific and unambiguous, as they are the criteria for Developers to build against, and the Quality Assurance team to test against.

With this in mind, let’s now add acceptance criteria into our example user stories:

• As a Home Owner, I want a sink in the bathroom, so that I can wash my hands, face etc..
  • Acceptance criteria 1 – The sink must have a running water supply
  • Acceptance criteria 2 – The sink must have a separate hot and cold tap
  • Acceptance criteria 3 – The sink taps must be matte black

• As a Marketing Manager of a media streaming service, I want to be able to find out the most popular film genres, so that we can provide more films within these genres to our customers
  • Acceptance criteria 1 – I need to be able to view analytics for films based on their genre
  • Acceptance criteria 2 – I need to view analytics in a centralised location
  • Acceptance criteria 3 – I need to be able to filter analytics based on total views

• As a Customer, I want to receive email updates on my order, so that I know when my purchase is going to be delivered
  • Acceptance criteria 1 – The email template must use company brand colours
  • Acceptance criteria 2 – The email updates must be personalised to each individual customer and use their name in the salutation
  • Acceptance criteria 3 – The email update must include a hyperlink for the customer to track their package

Think carefully about acceptance criteria and beware of adding additional constraints that don’t align to your user’s needs. Also note that there aren’t technical details here – we’re not trying to specify the types of washers in the taps, or pipework under the sink.

4 - Any associated documents, designs, or technical specifications are agreed and signed off

Before handing user stories over to the Development Team, additional information is sometimes required.

This could be in the form of visual designs, or technical requirements such as API specs (documentation that describes how to build or use a connection or interface).

Work with your Designers, Development & Quality Teams to identify if there are any additional considerations required in order to implement your user story.

Any further detail you can include on the user story will only help in achieving the best outcome of the user story.

If it is identified that your user story will require supporting documents, in the form of visual designs or technical documentation, a separate session with all project stakeholders should be setup to agree and sign these off.

5 - User story has been estimated, and is achievable in one sprint

Estimation involves assessing the the scope, size and complexity of a user story to ensure it’s small and simple enough to complete in one sprint. This is typically 10 working days.

If user stories are estimated and are seen to be more complex, and estimated to take more than one sprint to be completed, consider breaking the user story up into multiple user stories.

The goal of estimating a user story is to understand it’s effort, complexity, and uncertainty (risk). This process of estimation should involve the whole Delivery Team; Product Owner, Designers, Developers, and Testers.

There are a variety of ways to estimate user stories, the two most commonly opted for are using story points, or t-shirt sizing.

6 – User Story dependencies have been identified

User stories should be independent of one another, in the sense that they can be delivered at any time and are not dependent on one another.

However in practice, dependencies will emerge – you won’t usually be able to build and test the order conformation email until the checkout has been completed, for example.

Make a note of any dependencies with your user story.

Ready for dev! What happens now?

Once you are satisfied that a user story meets the criteria set out in each step of this checklist you can then be sure the user story is ‘ready’ for development.

The next step is to have a refinement session to walk the Development & Test Teams through the user stories giving them an overview, and a chance to ask questions.

These sessions are key to aligning stakeholders on the outcome of development, and are an opportunity for key stakeholders such as Developers to ask questions in order to confirm their understanding.

Following this, the Development Team will create sub- tasks under user story, and add estimates against them. Then your Project Manager will work with the rest of the Delivery Team to plan the work into a sprint, and provide you with a timeline of when your user story will be done.

(What constitutes ‘Done’ for a User Story is a topic for another day…)

Concluding Remarks/Key Takeaways

When writing a user story think of the output you/ the end user will have at the end of development, and why you/ the end user needs it.

The key to writing a great user story is to put yourself in the shoes of the end user, and most importantly demonstrate how value will be delivered to them.