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 FreeMarket has a product named Taxeze that can be used to calculate the marginal income tax rate and total tax based on a person's taxable income and filing status. Obviously, since you have already used a working version of Taxeze, 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 (also known as conditions of satisfaction and the definition of done) for each of these sprintable stories.

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. Items in the checklist must be atomic.

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.

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. Almost certainly, there should be several acceptance criteria for each story.
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.