unitED Sprint 1
1 Before the Sprint Planning Meeting
Before the Sprint Planning Meeting you must read the
project description and all of the
documents it links to.
Also, you must read and understand the stories in the Initial
Product Backlog. They are contained in the following document:
You should also enter all of the epics and stories (which ScrumBoard
calls issues) into ScrumBoard. This will save a lot of time during
the planning meeting. To add an epic, select the "Epics" tab and
click on the ⊕ next to "New". Then, enter the title, a description,
the size, and an optional color. To add a story/issue to an epic,
select the epic and click on the ⊕ next to "Issues." Then, enter the
title, description, and size (in story points).
You should also add an epic for system testing that includes one
story/issue for creating an alpha testing script (i.e., the
instructions to be followed by human testers) and one story for
testing using that script.
Finally, every member of the team must read and understand the
interaction design document for version 1.
2 During the Sprint Planning Meeting
During the sprint planning meeting (which may, because of the length
of class meetings, be held over the course of multiple days) you
must:
- Decompose each PBI into tasks.
- Create effort estimates for each task. (To add a task,
select the story/issue and click on the ⊕ next to "Tasks",
enter the title, an optional description and the effort
estimate in hours)."
- Individually commit to (i.e. take responsibility for)
completing specific tasks during this sprint. (To take
responsibility for a task, select the appropriate team
member from the drop-down list.)
- Create acceptance criteria (i.e., "definitions of done")
for each feature that will be completed during this
sprint. (To add an acceptance criterion to a story/issue, enter a
description in the text field under "Acceptance Criteria"
and click on the ⊕.).
- Add a sprint to the project. (To add a sprint, select the
"Planning" tab and click on the ⊕. Then enter a title,
optional goal, and optional description.)
- Add stories/issues to the sprint. (To add stories/issues,
select the sprint, and click on the ⊕ next to
"Issues". Then, select the stories/issues to add and click
on [Done].)
- Negotiate the contents of the sprint backlog with the
product owner if necessary (for example, if there
are PBIs that the team won't be able to complete because
of time limitations).
- End the sprint planning meeting and start the sprint. (To
start the sprint, select it and click on the ▶ next to
"State:". Then enter the start date and end date and click
on [Start].)
2.1 Help Decomposing Features/Stories/Issues into Tasks
There are several things to keep in mind when decomposing
features/stories/issues into tasks.
-
Epics span multiple sprints, features/stories/issues can be
completed in a single sprint, and tasks require hours to
complete.
-
Remember that cards are placeholders for conversations. In
other words, unlike when using a heavyweight process in which
most of the details are determined and enumerated/documented
up front, when using scrum, a story contains only a brief
description of the feature. Hence, it is often necessary to
have conversations with the product owner to determine the
details that were omitted from the story.
-
Do not confuse engineering design decisions (e.g., what
classes will be created) and/or implementation decisions
(e.g., what layout manager to use for the GUI, what algorithm
to use) with tasks. Those kinds of decisions should not be made
during the planning meeting.
-
Each feature/story/issue often has some interaction/product
design tasks, some engineering design tasks, some programming
tasks, some unit testing tasks, etc... Many features/stories/issues
also have data acquisition tasks, integration/system testing
tasks, user documentation tasks, etc...
-
Do not forget to include overhead tasks (e.g., research), and
pay particular attention to overhead tasks that are
not related to a particular feature/story (e.g., grooming the
product backlog is a task that should be done in every sprint, and you
should plan for it accordingly).
You've seen several examples that you should use to guide you.
2.2 Help Creating Acceptance Criteria
It is very important that the team (the members of which have technical
knowledge/skills) and the product owner (who often doesn't) agree
before the sprint begins on what will be completed during the
sprint. It is also very important that, at the end of the sprint,
the team and the product owner agree on what was completed.
Since features/stories are often ambiguous, this means that the team
and product owner must agree on acceptance criteria/"definitions of done".
One might think that the tasks could be used for this purpose, but
they can't because they require technical knowledge/skills to
understand. Acceptance criteria must be written so that they can
be understood by both the team members and the product owner. They
must be specific enough so that, at the end of the sprint, there
can't be any disputes about whether a backlog item was or wasn't
completed.
You've seen several examples that you should use to guide you.
2.3 Help Negotiating with the Product Owner
You will be much more effective negotiating with the product owner if
you have specific and detailed data about the amount of time the
team can devote to the sprint and the time required to complete
each of the tasks. You will be ineffective if you just claim to not
have enough time.
Also, remember that the Product Owner is responsible for
maximizing business value. So, in the event that you are able to
convince the Product Owner that all of the stories can't be
completed during the Sprint, the Product Owner will prioritize
the stories based on the information that you provide. In other words,
the team should not argue that a story is unimportant, that is for
the Product Owner to decide.
3 The Remainder of the Sprint
After the sprint planning meeting is over, each member of the team
must complete the tasks that they took responsibility for and
record their progress in the Scrum tool (on the "Execution" tab).
When you start working on a story, you must move it from the "Open" state
to the "In Progress" state. As you complete tasks, you must click on the
associated checkbox. When a story is complete (i.e., when all of the tasks
associated with that story are complete), you must ensure that it moves
from the "In Progress" state to the "Completed" state.
4 What You Will Need for the Review
Obviously, all of your team's code must be in your GitHub repository
and all other sprint-related materials must be in the sprint
planning/management tool (which must be up to date). In addition, on
the day of the review your team must have the following:
- A version of the current increment of the product
that works on one of your machines.
- A printout of an "unused" alpha testing script.
- A printout of at least one "used" alpha testing script.
- A printout of one or more screenshots of the EclEmma view(s)
demonstrating the coverage of your unit tests.
The printouts must clearly identify your team.
5 Resources
You might find the following resources useful.
6 Technical Hints and Help
The CS Department's wiki has information that might help you add
some of the functionality described in the PBIs. For example:
Also, several of the labs contain information that might be helpful for this
sprint.
Finally, the following lecture materials on Java topics covered in
other courses might be helpful:
CS345 - Software Engineering
