At Verys, we believe that user stories are a strategic, high-level development step in an Agile lifecycle.
For anyone using Agile Methodology, creating user stories is a given, but what makes a good user story? As a company, we believe it's important to have consistent user stories across the board. Reliable user stories can ensure that each developed feature brings value to the product and our customers. User stories are the fuel for development. We want to ensure that our development pipeline is well fed so that we can create meaningful contributions and deliver quality work to our customers.
A user story is a singular sentence written in the perspective of an end-user, to explain a software feature. It should cover the who, what, and why but not the how.
The main purpose of a user story is to ensure the feature being developed brings value to the customer. It's a vertical slice of code that includes both front-end and back-end development. For most of our projects, the product owner would be responsible for writing user stories for their development team. On occasion, a developer may write a user story. Regardless of who originates the user story, it is the job of the team to understand the story and refine it so it can be successfully developed by the team.
When we write user stories, criteria known as INVEST are utilized. It stands for independent, negotiable, valuable, estimable, small, and testable. In general, our stories should be easily estimated by the development team without reliance on any outside teams. It should be easy to test once completed and bring value to our customers. To learn more, you can check out our INVEST blog.
To create effective user stories, we use a few key ingredients to keep them uniform. This is helpful to everyone involved because it means that every story has the same format and elements. Here’s how we break it down:
It's important to clearly define what it means for a user story to be "done" so the whole team can agree when the work is complete. QA should be able to go through the entire story flow, end to end. If this is achieved, it means all development and QA testing is finished. Depending on how your company handles its deployments the feature may or may not be deployed to production when the story is considered done. When development and testing are complete, it will move to the Done column, which may consist of a handful of states such as ready for deployment, deployed, etc.
When multiple developers are working on one story together, we utilize subtasks to help track their work. Once all the subtasks are added the developers can assign the work amongst themselves or they can be assigned during sprint planning. This ensures each developer knows which piece of the functionality they are tasked with. During the daily standup, each developer can give an update on their progress, which can be tracked on their specific subtask.
If a particular function needs to be used by multiple users/roles, then we create a story for each user. This ensures that each flow by each user is accounted for, especially if the outcomes of the feature vary depending on the user.
If a particular feature is complicated, but each part can broken-down into individual stories, the overall feature is created as an epic. Each story can then be assigned to it for easy tracking, which makes the work easier to manage sprint by sprint.
Now that we know how to create an effective user story, let’s talk about what makes it a good user story. We are going to walk you through some of the tried-and-true ways for us to communicate effectively with the team so there isn’t any misunderstanding when someone reviews the stories.
The point of the title is to define the functionality. Here we can clarify who is doing the action and for what reason or motivation. The title should follow the formula: "As a [persona], I [want to], [so that/for]." By using this equation, it ensures that the developers understand who would be using the feature, what they want to be able to do, and why they need to be able to do it.
Examples:
Good:
Bad:
The first example is a good title because we understand who the exact user is, the exact action that the user wants to take, and why they want to take that action. The second example is a bad title because the user is vague and the process of what needs to be accomplished isn't very clear. This format should be consistent across simple and complex projects, because it encourages transparency and clarity in requirements.
We treat the description as the meat of the user story. The description allows us to give additional context to the title. It houses the Acceptance Criteria, which we will cover next and may contain links to mockups or designs as well as any constraints that need to be taken into account.
This is the most important part of the user story besides the title. This section covers actions or use cases that correlate to the implementation of the user story. Here we break down the feature for the developers step by step. Each piece of criteria should be a testable unit that can be approved by QA. It can be treated as a test manual for the QA team to ensure it is tested properly and thoroughly.
Examples:
Good:
Bad:
The second set of acceptance criteria is too vague. It doesn't cover in detail the criteria in which the ticket will be tested. The first set is more specific yet doesn't tell the development team how to develop the whole process. It still allows the development team room to decide how to implement each piece of criteria; therefore, the first set meets our requirements for solid acceptance criteria.
We use a point scale to give the development team the ability to estimate the difficulty of the work. This allows our product owners or project managers to make decisions on how many points to add to a given sprint. Once they establish the velocity of the team, tickets can be pulled into sprints based on those values.
We prefer the Fibonacci scale, which is a commonly used pointing system using the numbers: 1, 2, 3, 5, 8, 13, 21, etc. If a story is 21 points or higher, it should be broken down into smaller more manageable pieces. A story should never be so complicated that it can't be completed within a sprint.
We set deployment dates so that the team and our customers know when a story has been deployed into production. Deployment dates allow for easier tracking when trying to understand when a feature was introduced into the production environment. This can be helpful if any bugs arise because a particular feature can be rolled back to assess what may have caused the issue.
Adding a fix version also allows the development team to know which version of the application the story/feature was enabled. We can rely on the fix version to help with solving any bugs that may arise in the overall feature.
As we mentioned before, user stories are the fuel to a project. For a well-oiled machine to run, the fuel has to be tuned to those needs and constantly refueled or you may not get very far. Effective user stories win trust and satisfaction from your customers. We focus on building relationships with our end users so that communication and requirements are never an issue. Here at Verys, we believe that user stories are a strategic, high-level development step in an Agile lifecycle.
