How to use your stories effectively

Photo by rawpixel on Unsplash

User Stories are small and simple descriptions of a feature. They are narrated from the perspective of a person who will use this new functionality. User stories are the most popular agile technique to capture product features and are easy to use but harder to make effective. The basic foundation of a user story is; as a <user>, I want <function> so that <reason>. Stories should be Independent, Negotiable, Valuable, Estimable, Small and Testable (INVEST). This is all a good start, I always try and keep my stories relevant to the INVEST principles. Is that enough to make stories effective? Short answer, no. Here are a few handy tips to really get the most out of your user stories.

Users come first

User stories are written from the perspective of the user and how they will utilise the product. Spend some time identifying who your users actually are, it isn’t necessarily the end-user who will be directly interacting with your product. The user in your story should be the one who is directly interacting with the product for its intended function. For example, if you were making some enhancements to a web Content Management System. The end-user is your online web user however, work done to the CMS means your user in this instance are the authors. By determining this early, you can make sure their user experience is at the forefront of your mind.

Collaborate and build stories together

User stories should never just be handed to the development team to start working on, User stories are there to initiate conversations. By collaborating with the development team, the stories can be broken down further, reduce overhead and in turn accelerate delivery. As a Business Analyst, I gather requirements from stakeholders and tend to write up the initial stories. However, I like to perform elaboration sessions. In these sessions I run the team through these stories and as a group we break them down and discuss how we are going to meet these requirements. At this point, the team has built the story together. This builds up the understanding of what needs to be done as a group and ensures we are all on the same page.

Keep it simple

Seriously, keep it simple. Keep your stories concise and short, focus on what is important and make your requirements clear. If they are not clear, go gather more information. It’s really that simple. The way I structure my stories is with simplicity in mind, a narrative, one line description of what the story is about, a questions section (if any) and no more than 6–8 acceptance criteria.

An example of a simple user story

Splitting and refining your stories

Just like story writing, story splitting isn’t a one person task, infact there is probably a blog series on this alone — hmmm so stay tuned I might just dive into more detail in a seperate post . In the meantime take a read of this — Use your elaboration sessions to discuss the stories, if a story is anything bigger than what the team consider small, work together on the best way to split it. Think as a team, how can we split this story into smaller pieces of work and still maintain our ‘INVEST’ principles. The more you split them, the simpler and more manageable they become, leading to faster delivery. Sometimes you'll leave elaboration without having a story ready for development. That is fine, you’ve had a conversation and a greater understanding of the details you may need before the next elaboration. I have experienced spending multiple elaborations discussing the same complex user story. The final outcome however, was our one complex user story turned into three simpler and more manageable user stories.

The example above is a high level story split. These actually got split further with more elaborations. Keep in mind there are many conversations behind these user stories.

Acceptance Criteria

Acceptance Criteria are the conditions that need to be satisfied for the story to be ‘done’. These are conditions which developers will build to and testers will test against. In addition to being clear and concise they also need to be solution free. What I mean by this is, as a BA or a PO we should not influence the development team to build a product in a certain way, leave this for the collaboration sessions. For example, on a website managed by a CMS the stakeholder wants an image in the button component which links to another page. The image they want is the same image in the banner of the page the button component is linked to. My thought process would suggest that the image can be pulled from the page properties of the page the banner is on. However, a solution free acceptance criteria for this could be “Button component to have the same image as the banner of the page it is linking to”. This makes for more collaboration and more ideas on how to achieve this task. Getting the image from page properties is an effective method of achieving this, but is it the best method? Who knows, you can raise your ideas during elaboration and see what the team thinks.

Make sure the stories are always visible to the team

Stories should always be visible, the PO, developers and testers are always going to refer back to them. By having a board we can see what is in progress, who is working on it and what is done and ready for release. The PO can continuously prioritise the backlog and the development team can see what is coming up next.

Don’t just rely on user stories

User stories are a great tool but they should not be your only one for building a backlog of work. As they are small narratives with a few acceptance criteria, the details need to be documented elsewhere. Whether is is through process flowcharts and UX designs, this all depends on the type of product you are building and what the development team may need. You can refer to this additional material through your acceptance criteria. For example, we have UX designs for enhancing the menu bar in an app. One of your acceptance criteria in your story could be “Build menu bar as per UX design <Insert link to UX design>”. Our developers now have a guide to build to and testers have the same designs to test against.


User stories are small descriptions of a feature, designed to initiate a conversation. These conversations are what drive feature development, not just the user story. Through these conversations, your stories can be split into more manageable pieces of work by the team and provide them with a greater understanding of the requirements. For added value to the teams collaboration, don't just rely on user stories to capture user requirements. By using tools like process flow diagrams and UX designs, the development team can have a more visual understanding of what they may need to do.

Thanks for reading — my name is David Rizkalla — I’m 3–1 by KO and its time to eat.