Articulating Value With Testable User Stories

User stories are used to articulate the value we want end users to get from a given feature. Writing a story is as simple as filling out a ticket for a sandwich at the deli; you specify what you want, the sandwich is made per your specifications, you inspect your order, and then pay for it if it meets the requirements you outlined; it’s a work ticket for an independent, negotiable, valuable, estimable, small, testable deliverable.

Story Criteria

Ultimately the goal of any story or any work we do is to provide value to a client and to complete work that will provide solutions to their problems. To ensure this is the case the following 3 criteria must always be met:

• The client understands the story and is happy with what they will be getting from it
• The team/developers understand what is required for the story and can implement it
• The client and team's understanding of the story is the same

Bullet three is a crucial one that should not be overlooked. The risk of the two understandings diverging can be reduced by ensuring your stories include all of the elements of a strong story. It is the responsibility of the product owner to keep up with code reviews and questions to ensure that the team is developing what the client expects.

Things to think about when writing a story

Here are some questions that product owners should be asking themselves as they are thinking of possible stories and when writing them.

• Does the story make sense at a fundamental level? Sometimes clients will ask for things that don't make sense because of a misunderstanding of how the system works. If the product owner is also unsure of how something works they should talk with their team to ensure that time is not wasted creating stories about things that don't make sense in the context of the real system.
• How much background information do the people that will be working on this story have? The product owner is the most knowledgeable person on the project, what may seem obvious to them may not be obvious to the rest of the team. It is wise to include some context with the story to help them understand it properly. This is also helpful when looking back at past stories to remember how and why something happened
• What design elements/design direction/text copy will the person implementing this story need? The exact text copy and designs are sometimes not needed in order to estimate a story. However, in order to complete it, they are. Make sure they don't slip through the cracks after approval.
• Who are the actors, and what do they do? Some features only include one actor performing an action or series of actions. More complicated stories can include multiple actors going back and forth. The story should make clear who is doing what.

Elements of a strong story

• Consistency. All elements of the story work together and don't contradict each other.
• Don't repeat yourself. Repeating the same thing multiple or in multiple ways can be confusing and makes it more likely for inconsistent AC to happen.
• Background info/context. Set the stage for the story so the person reading knows what the story is related to.
• Assets/copy. If the story has UI, the design is at least communicated, and preferably shown in an attachment. For stories more about text, e.g. emails, ensure the copy is provided.
• All flows are handled. All the different ways the user may interact with the feature, good or bad, are covered.

Syntactical Guidelines

• Nouns for Story Title. Use nouns for the story title to make it a feature instead of a to-do list item. The subtasks can use verbs which makes them action based
• Title Case the Story Title. Using title case makes the story look more consistent.
• Bullet points for Acceptance Criteria (AC). Use bullet points for AC to keep them easy to digest. They will also serve as a checklist for the developer and QA that way.
• AND / OR. Only use AND / OR if you really mean that both or either condition should be met. If an AC can be broken into two pieces then split it into two bullet points
• ALL / NONE / ALWAYS / NEVER / ANY. Use absolutes only when intentionally wanted. If something can be enumerated, rather enumerate it because it helps the devs to remember to handle that case and QA to test it there.
• Flows vs End Results. AC should not just be a list of steps. Include steps in the background if helpful. The AC should describe the outcomes of the feature.