BarWare 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).
Finally, every member of the team must read and understand the
interaction design document.
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) there
are several things you must do.
First, you must first determine which features will be included in
the current increment as follows:
- Starting with the highest priority stories, 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)."
- Calculate the total number of person-hours required to complete
all of the tasks that have been identified thus far.
- Repeat these steps until the total hours required to
complete the tasks is greater than the total number of
person-hours the team has available.
- If necessary (i.e., if there are stories that can't be
completed because of time constraints), negotiate the
contents of the sprint backlog with the product owner.
After the team and the product owner have determined what features
will be included in the current increment, the team must:
- 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 ⊕.).
- Discuss the acceptance criteria with the product owner to
ensure that there will be no disagreements at the end of the sprint.
After the team and the product owner have agreed on acceptance
criteria, the team must:
- 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].)
- 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 Technical Hints and Help
The following hints might help you add some of the functionality
described in the stories.
5.1 Example Recipes
KitchIntel has created some example recipes that may help you get started:
The format of these files is unimportant. You should store recipes
in whatever format you think is most appropriate.
5.2 Serialization
One way to save objects to a file is to use serialization. This is described
in one of the labs.
5.3 Changing the Look and Feel of the GUI
The "look and feel" (sometimes called the "skin") can be changed
in a variety of different ways. Some help is available on
the
Departmental Wiki.
5.4 Decentralized Control in GUI-Based Applications
For complicated GUI-based applications, the listeners/observers
can get messy. One way to avoid this is to use "actions". This
approach is described in this
lecture from another course.
CS345 - Software Engineering