Creating User Stories for Testers

Even though the product owner is responsible for managing the product backlog, anyone in the project can create user stories. That means that even testers can create them, which they can ideate from instances such as running into bugs or revising user stories during product backlog refinement.

Creating User Stories

When the Scrum team consults with the product owner and the customers what features should be developed for the software product, they break down and summarise the requirements into statements called “user stories.”

User stories are tools to describe features from the user’s point of view. They are high-level definitions of requirements that state who the user is, what the user wants, and what the benefit would be. A user story would often follow this format:

As a <state user here>, I want to <state action here> so that <state purpose or benefit here>.

A user story is meant to be short and simple, enough to fit on a note card or sticky note, and it should contain just enough information for the Scrum team to start working with.  Let’s take a look at this user story:

US-001: As a new user, I want an easy registration process so that I can use the site as soon as possible.

It follows a user story template, but is it a good user story?

“INVEST in good stories”

The INVEST acronym simply summarises what a good user story would look like.

• Independent – As much as possible, user stories must be independent from one another. Their concept or purpose should not overlap.
• Negotiable – A user story is an invitation to a conversation, not a contract. It should capture the essence of what the user desires, and should be able to take changes as it gets refined further.
• Valuable – A good user story should be valuable to the specified user, and its benefit should be clearly stated in the “so that” clause.
• Estimable – Estimates are tools for negotiating the scope or acceptance criteria and splitting big user stories to smaller user stories. A user story should be clear enough for the Scrum team to estimate its size or complexity.
• Small – Because Scrum teams work in Sprints, a user story must be small or granular enough to fit within the agreed time-box.
• Testable – In order for the user story to be developed and tested, it must be clear enough to everyone. Understanding what the user story is about allows testers to write and execute good tests for it.

Going back to US-001, here are a few reasons why it doesn’t meet the INVEST criteria:

• Not valuable enough – “Easy registration process” can mean different things to different users. More research needs to be done to determine what “easy” is for their users.
• Not small enough – A typical end-to-end registration process would include clicking on registration link, filling out details, possibly correcting form mistakes, and confirming the email address. Based on those function points, US-001 needs to be split into several user stories.
• Not testable enough – Because the benefits are not clear and the user story could be split further, scope for development and testing are not clear as well.

It’s possible to set US-001 as an epic for smaller user stories, since it’s a big story that could over-arch several features. For the purpose of a demonstration, let’s say that we’ve written the following as one of the user stories under US-001:

US-002 – As a new user registering to the website, I want to know if my input fields are correct or incorrect before I submit the form so that I can save time and avoid re-entering data.

This new user story has focused in on one of the earlier concerns on correcting mistakes. It also clearly stated who the user is and what they want in particular. It could still be negotiated and revised, but that will depend on the Scrum team during product backlog refinement or sprint planning.

The INVEST criteria helps determine when a user story is granular enough and ready for implementation. Testers can help with further the clarification of user stories by using their mindset and experience in listing their acceptance criteria.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: