Have you ever hired someone to build a solution for you, only to get something that didn’t quite meet your needs? Perhaps you have gotten through a notable portion of the development cycle in a project, only to realize the requirements weren’t clear enough at the start. Maybe you’ve struggled with determining how to define acceptance criteria for a solution during the testing phase. If any of these scenarios relate to you, user stories may be the key to success in your future projects.
What are User Stories?
User stories are a document that helps identify the stakeholders involved in a project, what their needs are, and how the solution will address those needs. This document is often prepared early on in a project management workflow, as it will help ensure the end result is what all parties expect. It should be prepared before mockups or any development begins. User stories are typically broken into three main parts:
Summary: A brief summary of the overall project provides context for the overall project. This section can be as short or as long as the project requires.
User Personas: These personas describe the roles of people impacted by the project, outline what issues they are experience in their current workflow, and identify how the solution will improve that experience.
User Stories: This section goes more in depth into what each user wants from the solution in question. It then outlines how they will know when those needs are met. This is often used as the basis for developing acceptance criteria.
How Do User Stories Save Time and Money?
Taking the time to prepare user stories can save you time and money over the course of the whole project. By writing user stories, you get more clearly defined requirements. This helps to ensure the end product will be what you expect and meet the needs of you and your stakeholders. In taking the time to be more detailed when outlining the requirements up front, user stories also help keep the project in scope. It is easier to make changes and more clearly define needs up front than to do so halfway through the project, when code is already written.
User Personas
The user personas are the “who” of the user story. There should be at least one role for each stakeholder type in your project (project manager, each type of end user, executives, etc.). It should be noted that the developers working on the solutions are not user personas. They are only concerned with how the solution will meet your needs. The basic format for each user story can be broken down as follows:
Biography: The biography is the “who” of the persona. Each persona should be named, have a specific job they perform, and one or two traits to help describe their character. Personas should not be real people, as it can cause those individuals to get bogged down with the details or overly attached to ‘their’ persona instead of looking at the focus of that role and its requirements.
Example:
Jamal is an experienced chef who has been working at La Coeur for twelve years. He is one of the three chefs on staff who are experienced enough to be allowed to experiment with new recipes. He enjoys exploring the way different flavors interact to create new, enticing dishes.
Problem: The problem section of the persona should identify what in the current system isn’t working for this persona, why it doesn’t work, and how that impacts the persona and the company overall. If workers that fulfill a particular function in the company have a number of complaints, it may help to break them into multiple personas, so the problem sections don’t become bloated.
Example:
Currently, when Jamal comes up with a new dish, he has to teach each other chefs how to prepare everything. Because teams work on different days, this can take a longer period of time. During that time, other restaurants may start offering similar dishes, some ingredients may become harder to find or more expensive, and some chefs may attempt to teach each other before they have fully mastered the recipe. This results in La Coeur losing a leading edge, losing revenue due to increased costs in preparing a recipe or due to time spent training a recipe that can no longer be prepared at all, and inconsistencies in the dish when it is delivered to customers by chefs who learned it improperly.
Goal: The goal section explains how the solution will resolve or improve the problems this persona faces. It should be a brief description that addresses the problems. Specific criteria can be gone into in the user stories.
Example:
The digital recipe management system will allow any chef to look up a recipe they need to prepare. This will significantly reduce the time between when a new recipe is approved and when the whole kitchen is able to prepare it, which will in turn, lead to decreased costs and an increased competitive edge. Because the recipes will be in a database that can only be edited by chefs who have permission to create new recipes and management, the dishes will be prepared consistently, regardless of who makes it. This will also help bring new chefs up to speed on La Coeur’s recipes quickly.
User Stories
The section for the user stories themselves outlines the requirements in more detail. Each persona will have at least one user story. Although, they may have more depending on what problems they have and how the solution will address them. The most basic approach for the user story is to write out a brief paragraph of [Persona] wants [action], so [benefit]. Then, list out the ways that persona will know when that action has been done.
Example:
Jamal wants to be able to upload a new recipe into the digital recipe management system as soon as its approved, so that other chefs can reference it any time they need to.
Jamal knows this is done when:
– Jamal is able to sign into the digital recipe management system as a recipe creator.
– Jamal is able to upload a new recipe to the digital recipe management system.
– Jamal is able to search for and pull up previously approved recipes in the system and review them.
– Jamal is able to make notes on each recipe with tips for anyone else preparing the recipe.
– Jamal can sign out of his account and view the recipe management system as a regular user.
– Regular users are able to view, but not edit, all recipes in the digital management system.
– Recipes can be searched by name, type of dish (appetizer, entree, side, or dessert), or ingredients.
Bonus: These lists translate really well into test cases and acceptance criteria.
