The main reason behind building good software is to help the user. To make it happen, it is important to think like a user. User stories help software development teams and their customers to build user-centered products, one sprint at a time. User story requirements come from all sectors of the software development ecosystem, including stakeholders’ desires, business and technical constraints, and users’ needs. In short, user stories fuel the incremental delivery of value that characterizes agile development, and they work best when they are actionable, specific, and goal-oriented.
A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. The user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
Story splitting is the process of breaking one single user story into smaller stories. However, it’s not about breaking it into component tasks, but rather complete stories or slices that still deliver value to the user.
The easiest way to understand it is with an example. So, let’s say that you and your team are working on developing software that helps HR teams manage their company intranet. When working on a user story typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >. Here’s what you come up with:
As an administrator, I want to publish content to our company intranet so I can keep employees updated.
This user story gives you the functionality you need to focus on: administrators need to be able to publish content to the site. But, as you think about that further, you’ll realize that there’s a lot of different functionality rolled into that seemingly simple story. For example, you realize that:
Acceptance criteria are an important component of every user story that an agile team works on. It clearly defines the scope, desired outcomes, and testing criteria for pieces of functionality that the delivery team is working on.
The acceptance criteria is a shared understanding of how the value of a user story will be verified. These criteria ensure that each story is complete, and functional, and will result in the intended outcome. It is good to run the criteria by several stakeholders to make sure everyone is on the same page.
Acceptance criteria (AC) should be written anytime before the user story is deemed ready to enter Sprint Planning. Usually, it is written during the product backlog refinement meeting. AC can be progressively developed and added to a user story during the refinement.