Homework: Scrum Acceptance Criteria
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.
- Read the sprintable
stories that were created for one of the early
sprints.
- 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.
- "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.
- "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.
- "Where can I learn about the existing product?"
You’ve used it before and can use it again.
- "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.
- "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.