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
Nearby
has a product named
Wherez that can be
used to calculate the longitude/latitude of addresses.
Obviously, since you have already used a working version of Wherez,
the 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 (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 are a checklist of what
needs to be accomplished for a product backlog item to 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 the audience
(i.e., who they are written for). In other words, when writing
acceptance criteria assume they are being written for, and will be
confirmed by, the stakeholders 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.
- "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.