1 Purpose

The purpose of this assignment is to help you acquire (and demonstrate that you have acquired) the knowledge and skills required to write acceptance criteria for stories used in Scrum.

2 Overview

As you know, the (fictitious) company WeatherBits has a product named Tempz that can be used to calculate average minimum and maximum temperatures. Obviously, since you have already used a working version of Tempz, some product design, engineering design and construction have already been completed. For this assignment, you are going to replicate some of the product design process that they have already completed.

3 Tasks

Specifically, you must complete the following tasks.

1. Read the sprintable stories that were created for one of the early sprints.
2. Create acceptance criteria for each of the sprintable stories (not the epics).

Of course, normally you will not have a working product when you write the acceptance criteria. So, this assignment is actually much easier than it would be otherwise because you don't need to have conversations to obtain details about the stories. Instead, you can use the working product to obtain those details. Hence, your acceptance criteria must ensure that any product that satisfies them behaves like the working product.

4 Some Help

As you (should) know, epics are features that will require several sprints to complete, sprintable stories are features that can be added to the product in a single sprint, and tasks are activities that must be taken to complete a story and can be completed in a short amount of time (e.g., 1-2 hours). In other words, epics are decomposed into sprintable stories which are further decomposed into tasks.

As you should also know, acceptance criteria (sometimes called the "definition of done") are the things that need to be "checked off" before a product backlog item can be considered complete.

People sometimes have trouble differentiating tasks from acceptance criteria. When getting started with Scrum, one reasonable, though admittedly imperfect, rule of thumb is to think about who they are written for. In other words, when writing acceptance criteria assume they are being written for, and will be confirmed by, the stakeholder in the story. On the other hand, when writing tasks assume they are being written for people with technical expertise (e.g., programmers). Though this rule of thumb is not always appropriate (and is not guaranteed to work), it is a useful way to get started.

5 Submission

You must submit (using Gradescope) a .pdf file that contains a distinct list of acceptance criteria for each sprintable story.

From Gradescope's perspective, this assignment has only one question. So, you must associate all of the pages of your submission (if it has multiple pages), with that single question.

6 Questions You Should Not Ask

As always, you should feel free to ask questions. However, there are several questions you should certainly not ask.

1. "How many acceptance criteria do I need?"
   You need to have enough acceptance criteria to ensure that any reasonable person would agree that, if and only if all of the criteria are met then the feature can be considered complete.
2. "Is this the right level of detail?"
   We have discussed the different levels of details that get used for stories and their acceptance criteria. You should be able to answer this question based on that discussion.
3. "Where can I learn about the existing product?"
   You’ve used it before and can use it again.
4. "Can you give me some examples?"
   You were given examples of stories (with associated acceptance criteria) and tasks for another product as part of an earlier assignment. However, be careful - the acceptance criteria for features involving a graphical user interface (GUI) tend to be very different from a the acceptance criteria for other features. When the features involve the GUI, a non-technical person (e.g., the product owner) should be able to check-off acceptance criteria during a demo.
5. "What format should I use?"
   The format of an individual criterion is unimportant however the format across criteria should be consistent. Some people use the "As a stakeholder, when I action then the system criterion." If this format helps you then you should use it, but it isn't required.