User stories are a core component of the Agile framework, shifting the focus from software requirements to a user-centric description of desired capabilities. User stories are intentionally short and simple, focused on one particular feature written from the perspective of the user of a system rather than the system's developers.
They're different from traditional software system requirements in that they bring end users to the center of the conversation, adopting a more informal language to provide context for the developers of the system. A user story thus constitutes an end goal, a desired functionality from the perspective of the user, not necessarily articulated in technical terms and agnostic to the engineering efforts that it entails.
As a product owner or team lead, it is your (and your team's) job to refine user stories such that they constitute small, "atomic" units of work in an Agile framework such as scrum or kanban. For example, in scrum, user stories are added to sprints to be "burned down" over the duration of the sprint, in which case it is important that the user story is small enough to fit into a sprint. It is also important to establish a clear set of acceptance criteria, which often involves discussions with the end users. In this guide, you will learn how to refine user stories and acceptance criteria with the Agile framework.
A well formulated user story is:
User stories are often expressed as persona + need + purpose. It is then typically written in a simple sentence that follows the structure:
"As a [persona], I [want to ...], so that [...]"
"As a user, I want to be able to securely log in to the system so that my information can only be accessed by me."
The first step in refining a user story is to think about the amount of work involved in implementing the functionality. This will often depend on other downstream features that may or may not be already implemented. For instance, in the example given above, if the system already had in place most of the user sign-up capabilities (registering with username and password, changing password, remembering password, etc.), then this user story could be small enough in scope as it would involve adding perhaps the user session handling in the backend and a login button to the frontend. However, let's assume that we're starting from scratch. In this case, we will turn this user story into an epic.
This epic will then include the following smaller user stories:
These smaller user stories are now more precise and refined in their scope and are more likely to fit each within a single sprint.
The acceptance criteria determine the specific conditions that the software product must satisfy to be accepted by and meet the expectations of the user. It also forms the basis for the acceptance testing stage.
During the refinement process, as larger user stories become epics and are broken down into smaller scoped user stories, it becomes easier to reason about the acceptance criteria and come up with a shortlist for each user story (less than five criteria listed, ideally one to three criteria as a good rule of thumb). If the list of acceptance criteria for any user story is too big, it may be an indication that the user story is too large in scope and should probably be split further.
Some guiding principles for defining acceptance criteria are:
An acceptance criterion is often expressed as a sentence following the structure:
"Given [precondition], when I [do some action] then I expect [result]”.
In the example above, the acceptance criteria for the first two stories could be:
|User Story||Acceptance Criteria|
|As a new user, I want to register by creating a username and password so that the system can remember me and my data.||Given that I am a new user, when I go to the sign up page and enter an username and password and click on sign up, then I am successfully registered and able to log in with my chosen credentials.|
|As a registered user, I want to log in with my username and password so that the system can authenticate me and I can trust it.||1. Given that I am a registered user and logged out, if I go to the log in page and enter my username and password and click on Log in, then the data associated to my user should be accessible. |
2. Given that I am a registered user and logged out, if I go to the log in page and enter my username but an incorrect password and click on Log in, then log in fails with an error message that specifies that the username or password was wrong.
As mentioned earlier, a good practice in defining acceptance criteria is to also include non-functional requirements, i.e., requirements related to the system's qualities and attributes that are not necessarily directly related to the functionality, but are crucial in meeting the user's expectations in regards to the system's behavior.
For example, building on the list of acceptance criteria for the user story:
"As a registered user, I want to log in with my username and password so that the system can authenticate me and I can trust it."
We can add as a criterion:
"Given that I am a registered user and logged out, if I go to the login page and enter my username and password and click on Log in, then my user login session is loaded in less than eight seconds."
This criterion captures two underlying qualities of the system's design, namely:
A non-functional requirement could also be captured into a new user story added to the same parent epic, especially when it involves a new functionality entailing implementation work by the developers. An example, related to the security of user's accounts, would be:
"As a registered user, I want to be notified if there have been three unsuccessful login attempts against my username so that I can take action to secure my account."
Although not specifically stated by any user, such "non-functional" capabilities are simply expected as common sense, or sometimes they may be included by the product owner as something seen as design or security best practice.
Finally, it is worth noting that refining user stories is not only about sizing and splitting larger stories into smaller ones, but can also involve the following tasks:
An Agile backlog is meant to be a living body of information. Therefore, it is not necessary that all user stories be broken down into smaller and refined stories with corresponding estimates and acceptance criteria right from the onset of the project. It is important, however, that at any moment in time there are enough refined stories in the backlog ready to be added to the next sprint or backlog iteration.
An Agile project is no different than a traditional software development project in that it is also subject to "scope creep" in the form of user stories not really adding any substantial value to the product, but that sounded like great ideas when they were created. Therefore, having an ongoing effort aimed at managing the backlog and refining user stories in light of either internal discussions or discussions with end users is fundamental to avoid budget overruns or an unsuccessful product that does not meet expectations.