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.
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:
<type of user>, I want
<some goal>so that
The template consists of three components:
- Type of user: The user (of the system) can be a person or a system
- Goal: The objective the user wants to achieve
- Reason: The reason why the user wants to achieve the goal.
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:
- Functional criteria
- Non-functional criteria
- Performance measures
- Defect indicators
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:
- I can submit the newsletter form by entering my name, surname and email-address.
- When I click the submit-button, its color changes from blue to green.
- The system notifies me that a confirmation email will be sent.
- If I submit an empty form, I will see an error message to enter my name, sur-name and email-address.
- After submitting the form, I will get a double-opt-in-email to my specified email-address to confirm the subscription.
- When I click the confirmation link in the double-opt-in-email, I will be forwarded to the shop's newsletter page informing about a successful newsletter subscription.
- If I cannot click the confirmation link, I can copy the link to paste it into my browser.
- The system sends the email within 2 seconds.
- This function is available for the following user groups: Admin, standard user, power user, global user.
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:
- Story time: In this (external) meeting the Product Owner "tells a story" to the Scrum Team about the forthcoming user stories. Item by item, the developers can ask questions to the customer or the PO to get a clear vision of what's being requested. Then the gathered information will either be added as acceptance criteria or as notes to each story. Finally, the developers add their estimations to each story (e.g. as story points) to get it sprint ready. Meeting members are: Customer, PO and developers.
- Story Grooming: This (internal) meeting (also called Backlog Grooming) is about the organization of the project work. Developer and PO take care of the stories regularly and clean the backlog continuously. Stories which should be in the release will be identified, bundled to work packages and required data/information will be determined. The goal is to get structured work packages of user stories, which you can plan with. Though Story Grooming is not mandatory in Scrum, I recommend it as it saves time in the Sprint Planning making it more efficient.
- Sprint planning: Together with the entire Scrum Team, PO and Scrum Master the work load for the next sprint will be planned based on the refined and prioritized stories from the grooming meeting. The stories which can be implemented within the next sprint will be determined. At the end of this meeting you will get a clear commitment of all team members what the next sprint release will contain and what the acceptance conditions ("Definition of Done") are.
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:
- Six Thinking Hats: It is a structured and systematic technique of creativity. All team members will wear one "hat" at the same time. Each hat stands for one role:
- The blue hat (Managing): Manage thinking process, what is the subject, moderating attitude
- The white hat (Information): Analytic thinking, focus on facts, objective attitude
- The black hat (Devil's advocate): Describes criticism and fears, critical thinking, objective attitude
- The yellow hat (Optimism): Describes the best-case scenario, optimistic thinking, speculative attitude
- The red hat (Emotion): Emotional thinking, focus on feelings and ex-press emotions, subjective attitude
- The green hat (Creativity): Creative thinking and new perceptions, let thoughts run free, constructive attitudeThe sequence of the hats should be defined before the session starts. During the discussions the statements will be written in cards and hung to a board. At the end, the ideas, statements and thoughts will be assessed and discussed.
- 6-3-5 Method: In this creativity method you will have 6 people which write down 3 different ideas, in 3 columns, to a specific issue, on a piece of paper. Then they pass the paper 5 times and each time the ideas will be complemented by the next person. At the end you will have 108 ideas (6 participants x 3 ideas x 6 rows) which you can include in the user stories and acceptance criteria.
- Changing perspectives: Get a new look to your stories by considering the intention of a user story from different perspectives. The perspective of the user is different from the view of the system administrator, the customer, the system itself etc. Switching between all user roles of your project is important in order to cover all necessary criteria.
- 5 Whys: This question-asking method leads you quickly to the root of a problem. It explores the relationships underlying a specific problem. For example: 1. Why: No customer bought an article promoted in the newsletter 2. Why: No customer has received the newsletter 3. Why: No newsletter was sent 4. Why: No content has been created for the newsletter 5. Why: There is no valid license for the newsletter tool. Conclusion: Buy the license.
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.
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.
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.
- IEEE Std 610.12-1990: http://cow.ceng.metu.edu.tr/Courses/download_courseFile.php?id=2677
- "Kano model showing transition over time" by Craigwbrown – Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons – http://commons.wikimedia.org/wiki/File:Kano_model_showing_transition_over_time.png#mediaviewer/ File:Kano_model_showing_transition_over_time.png