Refine User Stories and Acceptance Criteria with Agile

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:

• Simple and precise (can be programmed, tested, and integrated within a single sprint)
• Useful (it should provide value to the final product)
• Focused on a specific user goal

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 [...]"

Example:

"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:

• As a new user, I want to register by creating a username and password so that the system can remember me and my data.
• 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.
• As a registered user, I want to be able to occasionally change my password so that I can keep it secure.
• As a registered user, I want to be able to request a new password so that I don't permanently lose access to my data if I forget it.

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:

• Each acceptance criterion should be independently testable
• Each acceptance criterion test should have a clear pass/fail result
• Acceptance criteria should be focused on the end result (functionality), not the mechanism through which it is achieved
• When relevant, "hidden" non-functional criteria should be included

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:

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:

• High-availability (the request cannot timeout due to there not being available resources), and
• Scalability (the request cannot take too long because the servers can't handle the load).

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:

• Removing user stories that are no longer deemed relevant
• Reviewing and re-assessing the priority of stories
• Assigning estimates to stories which have not yet been assigned one
• Correcting estimates based on new information
• Adding, editing, or removing acceptance criteria based on new discussions
• Etc.

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.