I was recently asked to articulate what I consider to be “a good user story”. I had never thought about it before. I usually follow the SMART and INVEST frameworks to build the backlog, but how do I know when a user story is “ready”?

For me, the first thing I do is gain a better understanding. That is, an understanding of how the solution is going to fit within the wider business goals and technical landscape and understanding the value that the solution will be delivering. I am then able to start building the high level backlog to create a picture of how I see us delivering that value.

The context in which each user story sits is important to understand. It becomes easier to decide what will be delivered within the story and, sometimes more importantly, what will not be delivered within that story. Ensuring that the delivery team understand the context gives them a greater ability to make technical decisions appropriate for that client, and that solution, and it also allows the whole team to empathise with the end users and what is important to them.

User stories are not meant to be a complex set of very specific requirements. They should be a point of reference designed to start a conversation. They should include the key points that are required for the delivery of the value and should spark the collaborative nature required to deliver a great solution. Each member of the team can bring different experiences and expertise to the table, so allowing room for each person to think for themselves and to work together is important.

With that in mind, the first thing I will ever do is write a short paragraph describing who the story is for, what we are trying to achieve and why that goal is important.

The above paragraph structure is a clear and concise way of creating contextual understanding and keeping the focus on the value we are trying to achieve. After that, I can start working on the acceptance criteria (AC’s).

There are many, many schools of thought on how to format your AC’s, but there are a few key points that I have learnt over the years

1. Be clear and concise
2. Add enough detail, but not too much
3. Do NOT include technical details in the AC’s

Being clear and concise and adding enough detail, but not too much, both play into what I mentioned above about allowing room for people to come up with their own ideas on how that value can be achieved. Having a discussion about the best approach to take will give the team an opportunity to ask questions and iron out anything that is unclear. Having that discussion also gives me an opportunity to ensure that what I have meant, is what has been heard.

Not including technical details in the AC’s is a very important one to me. By including technical details, it starts telling the developers how they should deliver, not what they should deliver. Frequently, clients will come to us with a solution in mind and they will tell me what they think needs to be done, but that is not why they have hired us. They have asked us to help because we are experts in our field and we are able to give them the technical expertise that they do not have within their organizations. Often, by stepping back from their proposed solution to find what they are trying to achieve, we have been able to help them find other potentially better, simpler or cheaper solutions.

So, coming back to the initial question; What makes a good user story? It is one that focuses on the value that needs to be achieved, within a context that can be understood by everyone involved and it has enough detail to spark the creative juices, but not so much that everyone gets bogged down in the details.