About user stories and acceptance criteria

April 7, 2015
by Matthias Baur

Especially when joining projects for a second release with already existing functional design specifications (FDS), it may well be that user stories are not what they should be. With much room for interpretation they might not be clear, easy to understand or even complete. The impact is an additional (unexpected) effort with all further consequences and discussions between the customer and the contractor about what has and what hasn't been offered. But why is it like that? If you have ever asked yourself one of the following questions: "What is a user story?", "How can I write one?" and "Where can I keep all the conditions to lay the foundation for a successful project?" – well, this blog post is for you.

Product Backlog structure

Before we start with user stories and acceptance criteria, it is important to know where they are located in the Product Backlog. A Product Backlog consists of epics, requirements, user stories and acceptance criteria.

Product Backlog

An epic describes roughly a software requirement and is divided into finer detailed user stories (e.g. an order process (epic) consists of several user stories). While for small projects it is sufficient to have epics, user stories and acceptance criteria, for bigger projects you should consider to use an additional "requirement" level to bundle related user stories within an epic. You can add the mockups of all associated user stories there. In cases of UI updates you can replace them quickly (because the mockups are stored centrally in the requirement, instead of in each user story).

From requirements to user stories

In classic projects (e.g. waterfall model) a requirement is very well defined in the IEEE Standard Glossary of Software Engineering Terminology . Requirements in agile projects are written as user stories. According to Mark Cohn a user story is described as a short, simple description of a feature from a user's perspective . Indeed, the template provided by him has proven itself as very helpful:

As a <type of user>, I want <some goal> so that <some reason>.

The template consists of three components:

It's like in the real world: You (the user) read this article (goal) to get to know how to write user stories (reason). Maybe another example:

As a shop user, I want to be able to subscribe to the newsletter to stay informed about new products.

You don't have to write the reason for every user story, but it is very helpful for all stakeholders (and yourself). I wouldn't recommend to cut it off. But if you wish, the example above without "the reason", it would rather look like this:

As a shop user, I want to be able to subscribe the newsletter.

It isn't complex, right? But as you should have guessed correctly, this user story can't be tested and isn't complete. That's when the acceptance criteria come into the game.

No acceptance criteria – no game

No acceptance criteria, no user story. Simple, but important. Before the developer can mark a user story as "done", each criteria has to be checked as fulfilled to ensure the story works as planned. As indicators or measures, the acceptance criteria consist of the requirements of a user story. Only once these requirements are fulfilled, the story is done:

Acceptance criteria are incredibly important in Scrum because they spell out what a Product Owner expects and what a team needs to accomplish. There are no hairs to split and no points to argue. If it's in the acceptance criteria, then it needs to be in the release.

If you think the user story has been already detailed enough and there is no need for any acceptance criteria (or you don't know what you can write as criteria), maybe your stories are too detailed and you should consider a review. Do not write a story for every peanut. It creates a lot of work and the Product Backlog gets too complex to work with. Just keep focused on stories that create a value for the user, avoiding duplicates for several user groups. Acceptance criteria can be divided into the following types:

If you are wondering how acceptance criteria can look like, we'll use the user story from above about the newsletter. Here are some examples of acceptance criteria:

As you can see, these acceptance criteria help to check if the developer has fulfilled the task and also reduced the needed amount of user stories. They also serve as a basis for writing test scenarios to achieve high quality in QA and user acceptance tests (of course good test scenarios can't guarantee bugs won't come up). To identify all user stories and acceptance criteria for a project, Scrum uses different types of meetings:

Methods to complete acceptance criteria

Acceptance criteria are not easily defined. In this chapter, I will introduce you one of the most used methods to ensure all criteria are recorded:

All of those methods are very useful. You only have to choose the right method for each situation.

Prioritisation and estimation methods

With the Kano model (developed by Noriaki Kano) you divide the Product Backlog into basic needs (subconscious and assumed), performance needs (expected) and excitement (unconscious) needs.

Kano Model

Basic needs will never lead to satisfaction (only negative vertical line), but you should always implement them to reduce unsatisfaction. However, performance needs can both: When you implement them, they increase the stakeholder's satisfaction. If not, it leads to unsatisfied stakeholders. It is a linear scale (positive and negative vertical line). Delighters can only reduce or increase satisfaction (only positive vertical line), but these excitement needs make your product special comparing to others. Over time Delighters will become basic needs. For instance, in 1992 the SMS functionality of mobile phones was an innovation. But over time it has become a basic feature for mobile phones. For estimations Planning Poker is used in Scrum. Effort categories will be created by assigning the effort to numbers of the Fibonacci row (for example 1 = low effort, 2 = neu-tral effort, 3 = high effort, 5 = very high effort, 8 = etc.). The row reflects the uncertainty in estimating larger items: The higher the number, the more uncertain the estimation is. For instance, if three team members say 2 and one member estimates 5, the team has to discuss it in detail to find a common thread for the respective user story. Each next sprint contains a certain number of story points. From sprint to sprint the team learns how many story points can be done in one. Another approach is to estimate with real hours. Each team member calls the best-, average- and worst-case scenario in hours and the average will be calculated. According to the productivity of each person per day (never plan with 100%), you can plan the sprint and you will get the amount of stories which can be implemented in it.

Conclusion

Acceptance criteria reduce the risk for contractors, especially in fixed priced projects to isolate the offer's scope of performance and delivery from (chargeable) changes. They ensure that the user story is done and ready for approval. Of course, for acceptance criteria brainpower is needed. In Scrum you start with the user story and elaborate them in further meetings together with the team and customer for each sprint. From the customer's perspective, especially the management can be scared of the amount of meetings in scrum, but the investment in good user stories is paying off, as they affect the entire project and make it more efficient. It helps to simplify the understanding for all stakeholders, eliminates unnecessary communication and not at least the product does what it is intended for. A great piece of software and a satisfied customer are the reward.

Sources:

About the author: Matthias Baur
Comments
Join us
Are you creative and passionate about software development? Do you think unconventionally and act with initiative? Do you want to achieve great things within our team?