Table of Contents

Scrum...................................................................................................................................................................1
Overview.................................................................................................................................................1
Scrum rules.............................................................................................................................................3
Sprint Planning meeting..........................................................................................................................3
Daily Scrum Meeting..............................................................................................................................4
Sprint.......................................................................................................................................................5
Sprint Review Meeting (Demo)..............................................................................................................6
Sprint Retrospective Meeting.................................................................................................................7

Scrum
Overview
Scrum is a methodology for managing agile development projects. It involves iterative, incremental planning,
which occurs between spurts of development work driven by clear goals. Team members manage their own
work and track progress through daily meetings.
Scrum, as a methodology, focuses on agile project management. It takes its name from the scrum in rugby, in
which players form a tight knot and together execute a plan for passing the ball in a desired direction.
The Scrum methodology is based on short daily meetings, Daily Scrum, in which all team members
collaborate on managing a development project.

In Scrum meetings, each team member answers three questions:

What work have I completed since the last scrum, and why?
What do I plan on completing between now and the next scrum?
Do I have any roadblocks or problems that the team can help overcome?
Also borrowed from rugby is the concept of a sprint. In Scrum, each sprint (iteration) is a fixed-length
development period with a clear goal, consisting of an agreed set of work item to implement. Each successive
sprint builds on the last, and planning occurs between the sprints.
A Scrum team uses three types of backlogs to plan and manage a development project:
A sprint backlog -> details the work items that team members have agreed to complete in a given
x-day sprint. Once a sprint starts, no changes should be allowed to interfere with its goal.
A release backlog - > details all the work items that must be completed before a software product can
be released.
A product backlog - > details all changes and ideas for implementation that dont directly support the
agreed goal for the current sprint. This backlog then informs the planning for subsequent sprints.

Scrum

To track its progress in completing the agreed work items during a sprint, a Scrum team uses whats known as
a burndown chart. In the chart, the straight line indicates the ideal workflow, in which work items are
completed in a completely steady, uniform manner. A second line, which is updated daily, represents the
teams actual progress. This makes it clear when adjustments are needed to bring development back on
schedule.
* Sprints, a burndown chart, and daily Scrums.:

Scrum emphasizes a management process based on empirical control, with planning thats iterative and
incremental. In addition, a key principle is that a Scrum team must be self-organizing. Team members
organize and manage their own work, based on the goals for a sprint and on daily scrum meetings.
Core values associated with the success of the team include commitment, focus, openness, respect and
courage.
The ideal Scrum team includes four to nine members. However, this methodology is scalable. If multiple
teams are involved in a project, each teams daily scrum meetings can be followed by a second scrum. In the
second scrum, a representative from each team collaborates to ensure that all the teams efforts are
coordinated.
A focus in Scrum is on the equal participation of all team members. Accordingly, apart from the team itself,
only two Scrum roles are specifically defined:
Product owner - > he represents the interests of the customer or end user. This person is also
responsible for liaising between the team and the customer.
Scrum Master - > facilitates and reports on the work of the team, focuses the team on the highestpriority tasks, and assists in overcoming any roadblocks.
Core Scrum Roles:

Overview

Scrum rules
The ScrumMaster is responsible for ensuring that everyone related to a project, whether chickens or pigs,
follows the rules of Scrum. These rules hold the Scrum process together so that everyone knows how to play.
If the rules arent enforced, people waste time figuring out what to do. If the rules are disputed, time is lost
while everyone waits for a resolution.
If someone wants to change the rules, use the Sprint retrospective meeting as a forum for discussion. Rule
changes should originate from the Team, not management. Rule changes should be entertained if and only if
the ScrumMaster is convinced that the Team and everyone involved understands how Scrum works in enough
depth that they will be skillful and mindful in changing the rules. No rules can be changed until the
ScrumMaster has determined that this state has been reached.

Sprint Planning meeting

The attendees are the ScrumMaster, the Product Owner, and the Team. Additional parties can be
invited by any of these people to provide additional business domain or technology domain
information and advice, but they are dismissed after this information is provided. There are no
chickens as observers.
The Product Owner must prepare the Product Backlog prior to the meeting. In the absence of either
the Product Owner or the Product Backlog, the ScrumMaster is required to construct an adequate
Product Backlog prior to the meeting and to stand in for the Product Owner.
The goal of the first segment, or first 4 hours, is for the Team to select those Product Backlog items
that it believes it can commit to turning into an increment of potentially shippable product
functionality. The Team will demonstrate this functionality to the Product Owner and stakeholders at
the Sprint review meeting at the end of the Sprint.

Scrum rules

 The Team can make suggestions, but the decision of what Product Backlog can constitute the Sprint is
the responsibility of the Product Owner.
The Team is responsible for determining how much of the Product Backlog that the Product Owner
wants worked on the Team will attempt to do during the Sprint
Time-boxing the first segment to 4 hours means that this is all of the time that is available for
analyzing the Product Backlog. Further analysis must be performed during the Sprint. Large-grained,
high-priority Product Backlog with imprecise estimates might not be thoroughly understood during
this part of the Sprint planning meeting and might result in the Team not being able to complete all of
the Product Backlog that it selects.
The second segment of the Sprint Planning meeting occurs immediately after the first segment and is
also time-boxed to 4 hours
The Product Owner must be available to the Team during the second segment to answer questions that
the Team might have about the Product Backlog.
It is up to the Team, acting solely on its own and without any direction from outside the Team, to
figure out during the second segment how it will turn the selected Product Backlog into an increment
of potentially shippable product functionality. No one else is allowed to do anything but observe or
answer questions seeking further information.
The output of the second segment of the Sprint planning meeting is a list, called the Sprint Backlog,
of tasks, task estimates, and assignments that will start the Team on the work of developing the
functionality. The task list might not be complete, but it must be complete enough to reflect mutual
commitment on the part of all Team members and to carry them through the first part of the Sprint,
while the Team devises more tasks in the Sprint Backlog.

Daily Scrum Meeting

The Daily Scrum meeting is time-boxed to 15 minutes regardless of the number of Team members.
Hold the Daily Scrum in the same place at the same time every work day. The Daily Scrum is best
held first thing in the day so that the first thing Team members do on arriving at work is think of what
they did the day before and what they plan to do today.
All Team members are required to attend. If for some reason a Team member cant attend in person,
the absent member must either attend by telephone or by having another Team member report on the
absent members status.
Team members must be prompt. The ScrumMaster starts the meeting at the appointed time, regardless
of who is present. Any members who are late pay $1 to the ScrumMaster immediately.
The ScrumMaster begins the meeting by starting with the person immediately to his or her left and
proceeding counterclockwise around the room until everyone has reported.
Each Team member should respond to three questions only:
What have you done since the last Daily Scrum regarding this project?
What will you do between now and the next Daily Scrum meeting regarding this project?
What impedes you from performing your work as effectively as possible?
Sprint Planning meeting

 Team members should not digress beyond answering these three questions into issues, designs,
discussion of problems, or gossip. The ScrumMaster is responsible for moving the reporting along
briskly, from person to person.
During the Daily Scrum, only one person talks at a time. That person is the one who is reporting his or
her status. Everyone else listens. There are no side conversations.
When a Team member reports something that is of interest to other Team members or needs the
assistance of other Team members, any Team member can immediately arrange for all interested
parties to get together after the Daily Scrum to set up a meeting.
Chickens are not allowed to talk, make observations, make faces, or otherwise make their presence in
the Daily Scrum meeting obtrusive.
Chickens stand on the periphery of the Team so as not to interfere with the meeting.
If too many chickens attend the meeting, the ScrumMaster can limit attendance so that the meeting
can remain orderly and focused.
Chickens are not allowed to talk with Team members after the meeting for clarification or to provide
advice or instructions.
Pigs or chickens who cannot or will not conform to the above rules can be excluded from the meeting
(chickens) or removed from the Team (pigs).

Sprint
The Sprint is time-boxed to 30 consecutive calendar days. Aside from other factors, this is the amount
of time required for a Team to build something of significant interest to the Product Owner and
stakeholders and bring it to a state where it is potentially shippable. This is also the maximum time
that can be allocated without the Team doing so much work that it requires artifacts and
documentation to support its thought processes. It is also the maximum time that most stakeholders
will wait without losing interest in the Teams progress and without losing their belief that the Team
is doing something meaningful for them.
The Team can seek outside advice, help, information, and support during the Sprint.
No one can provide advice, instructions, commentary, or direction to the Team during the Sprint. The
Team is utterly self-managing.
The Team commits to Product Backlog during the Sprint planning meeting. No one is allowed to
change this Product Backlog during the Sprint. The Product Backlog is frozen until the end of the
Sprint.
If the Sprint proves to be not viable, the ScrumMaster can abnormally terminate the Sprint and initiate
a new Sprint planning meeting to initiate the next Sprint. The ScrumMaster can make this change of
his or her own accord or as requested by the Team or the Product Owner. The Sprint can prove to be
not viable if the technology proves unworkable, if the business conditions change so that the Sprint
will not be of value to the business, or if the Team is interfered with during the Sprint by anyone
outside the Team.
If the Team feels itself unable to complete all of the committed Product Backlog during the Sprint, it
can consult with the Product Owner on which items to remove from the current Sprint. If so many
items require removal that the Sprint has lost its value and meaning, the ScrumMaster can abnormally
Daily Scrum Meeting

terminate the Sprint, as previously stated.

If the Team determines that it can address more Product Backlog during the Sprint than it selected
during the Sprint planning meeting, it can consult with the Product Owner on which additional
Product Backlog items can be added to the Sprint.
The Team members have two administrative responsibilities during the Sprint: they are to attend the
Daily Scrum meeting, and they are to keep the Sprint Backlog up-to-date and available in a public
folder on a public server, visible to all. New tasks must be added to the Sprint Backlog as they are
conceived, and the running, day-to-day estimated hours remaining for each task must be kept
up-to-date.

Sprint Review Meeting (Demo)

The purpose of the Sprint review is for the Team to present to the Product Owner and stakeholders
functionality that is done. Although the meaning of done can vary from organization to
organization, it usually means that the functionality is completely engineered and could be potentially
shipped or implemented. If done has another meaning, make sure that the Product Owner and
stakeholders understand it.
Functionality that isnt done cannot be presented.
Artifacts that arent functionality cannot be presented except when used in support of understanding
the demonstrated functionality. Artifacts cannot be shown as work products, and their use must be
minimized to avoid confusing stakeholders or requiring them to understand how systems development
works.
Functionality should be presented on the Team member workstations and executed from the server
closest to productionusually a quality assurance (QA) environment server.
The Sprint review starts with a Team member presenting the Sprint goal, the Product Backlog
committed to, and the Product Backlog completed. Different Team members can then discuss what
went well and what didnt go well in the Sprint.
The majority of the Sprint review is spent with Team members presenting functionality, answering
stakeholder questions regarding the presentation, and noting changes that are desired.
At the end of the presentations, the stakeholders are polled, one by one, to get their impressions, any
desired changes, and the priority of these changes.
The Product Owner discusses with the stakeholders and the Team potential rearrangement of the
Product Backlog based on the feedback.
Stakeholders are free to voice any comments, observations, or criticisms regarding the increment of
potentially shippable product functionality between presentations.
Stakeholders can identify functionality that wasnt delivered or wasnt delivered as expected and
request that such functionality be placed in the Product Backlog for prioritization.
Stakeholders can identify any new functionality that occurs to them as they view the presentation and
request that the functionality be added to the Product Backlog for prioritization.
The ScrumMaster should attempt to determine the number of people who expect to attend the Sprint
review meeting and set up the meeting to accommodate them.
Sprint

 At the end of the Sprint review, the ScrumMaster announces the place and date of the next Sprint
review to the Product Owner and all stakeholders.

Sprint Retrospective Meeting

It is attended only by the Team, the ScrumMaster, and the Product Owner. The Product Owner is
optional.
Start the meeting by having all Team members answer two questions:
What went well during the last Sprint?
What could be improved in the next Sprint?
The ScrumMaster writes down the Teams answers in summary form.
The Team prioritizes in which order it wants to talk about the potential improvements.
The ScrumMaster is not at this meeting to provide answers, but to facilitate the Teams search for
better ways for the Scrum process to work for it.
Actionable items that can be added to the next Sprint should be devised as high-priority nonfunctional
Product Backlog. BDSRetrospectives that dont result in change are sterile and frustrating.

Sprint Review Meeting (Demo)