Scrum Guidelines

Service Delivery Handbook Page 1 of 12

 CONTENTS

1. PURPOSE.....................................................................................................................................................3

2. SCOPE..........................................................................................................................................................3

3. OTHER REFERENCE ..............................................................................................................................3

4. INTRODUCTION........................................................................................................................................3

5. SCRUM.........................................................................................................................................................3

6. SCRUM PROCESS FLOW........................................................................................................................4

7. CHARACTERISTICS OF A SCRUM METHODOLOGY....................................................................4

8. SCRUM ROLES & REPONSIBILITIES.................................................................................................4

8.1 PRODUCT OWNER .....................................................................................................................................4
8.2 SCRUM MASTER......................................................................................................................................5
8.3 TEAM....................................................................................................................................................5
9. SCRUM PRACTICES.................................................................................................................................5
9.1 SCRUM PLANNING MEETING:......................................................................................................................5
9.2 SPRINT:..................................................................................................................................................6
9.3 SCRUM MEETINGS :...................................................................................................................................7
9.4 SCRUM OF SCRUMS..................................................................................................................................7
9.5 SPRINT REVIEW MEETING..........................................................................................................................9
9.6 SPRINT RETROSPECTIVE.............................................................................................................................9
10. SCRUM ARTEFACTS............................................................................................................................10
10.1 THE PRODUCT BACKLOG.......................................................................................................................10
10.2 THE SPRINT BACKLOG..........................................................................................................................11
10.3 THE SPRINT BURNDOWN CHART.............................................................................................................11
10.4 THE PRODUCT INCREMENT.....................................................................................................................11
11. AMENDMENT HISTORY.....................................................................................................................11

Service Delivery Handbook Page 2 of 12

1. PURPOSE
customers are increasingly demanding the use of Agile techniques while developing
software. The objective of this document is hence to provide a common guideline for
Scrum process of software development projects in

2. SCOPE
The guidelines enumerate general points to be followed for effective implementation of
Scrum methodology

3. OTHER REFERENCE
• Agile Project Management with Scrum by Ken Schwaber
• Agile Project Management by Jim Highsmith published by Pearson Education
• http://www.agilealliance.org
• ITS-S-G007E Hot Housing Guidelines
• ITS-S-G007H Agile Guidelines

4. INTRODUCTION
“Scrum” name is derived from activity that occurs during rugby match i.e a group of
players forms around the ball and the team-mates work together, sometimes violently, to
move the ball downfield. In IT context it is Project Management Methodology for Agile
development

5. SCRUM
On one hand, Scrum is very simple. The process, its practices, its artifacts and its rules are
few, straightforward and easy to learn. On the other hand, Scrum’s simplicity can be
deceptive. Scrum is not a prescriptive process; it doesn’t describe what to do in every
circumstance. Scrum is used for complex work in which it is impossible to predict
everything that will occur. Accordingly, Scrum simply offers a framework and set of
practices that keep everything visible. This allows Scrum’s practitioners to know exactly
what’s going on and to make on-the-spot adjusents to keep the project moving towards
the desired goals.

Service Delivery Handbook Page 3 of 12

6. SCRUM PROCESS FLOW

 Requirements are documented in a product backlog which is a prioritised list of

requirements.
 Requirements in a product backlog are broken down into multiple sprints or iterations.
The sprint backlog hence contains a list of requirements that can be delivered in that
sprint
 A Sprint is ideally recommended to be of 30 calendar day duration. However this duration
can vary from project to project and can range from 1 week onwards
 The sprint backlog is developed in the sprint and progress is tracked through daily scrum
meetings
 At the end of the sprint, a deliverable called as product increment is shipped out to the
customer.

7. CHARACTERISTICS OF A SCRUM METHODOLOGY

 It is a project management methodology

 It is a wrapper for existing engineering practices
 Scrum works with XP, RUP and any other engineering practice you have adopted
 Scrum believes in empowering the development team
 Scrum advocates working in small team (7-9)
 It consists of only three roles
 Scrum expects to track the progress on daily basis.

8. SCRUM ROLES & REPONSIBILITIES

There are three roles in this methodology viz. Product owner, Scrum Master and the team.
8.1 PRODUCT OWNER
• Product Owner is the person responsible for managing Product Backlog so as to
maximize the value of the project.
• He/ She represents all stakeholders in the project
• He/ She owns product log and prioritizes
Service Delivery Handbook Page 4 of 12
 • He/She directs the project, Sprint by Sprint,
• He/She manages ROI through prioritization and release plans

Typically in , Customer, customer proxy (onsite person, business analyst) will be the
product owner.
8.2 SCRUM MASTER
•Scrum Master is the person responsible for the Scrum Process, its correct
implementation, and the maximization of its benefits.
• He/She helps the team turn that backlog into functionality
• He/ She is responsible for enacting Scrum values and practices
• His/her main job is to remove impediments
• He/She fosters team communications
• He/She improves engineering practices and tools
• He/ She is responsible for improving productivity of development team
• He/She organizes and facilitates ‘scrum meetings’
In context , the Project Manager may act as the Scrum Master

8.3 TEAM
• Is a cross functional group of people that is responsible for managing itself to develop
software every sprint.
• Has the full authority to do anything to meet the sprint goal
• Estimates deliveries
• Commits and deliver user stories
• Produces quality code

In , the entire project team members will constitute the Scrum Team. Typically, a Scrum
team has 7-9 members. If the project team is big, then Scrum of Scrums is used. Refer
Sec 9.4.

9. SCRUM PRACTICES

 The Sprint Planning Meeting

 The Sprint
 The Daily Scrum
 The Sprint Review Meeting
 The Sprint Retrospective

9.1 SCRUM PLANNING MEETING:

Service Delivery Handbook Page 5 of 12

Sprint Planning Meeting is a one-day meeting time-boxed to 8 hours that initiates every
Sprint. It consists of following activities:
• Product Owner describes highest priority features to the Team.
• Team decides what they can commit to delivering in the Sprint.

Sprint Planning Meeting comprises of two segments of four hours each:

• Segment One: Four hours

• The Product Owner selects the ideal backlog for the coming Sprint and
communicates its meaning and importance to the team.
• Team may ask questions.

• Segment Two: Four hours

• The Team decides
• on the sprint goal (a short theme for the sprint)
• how much it can commit to delivering in the coming Sprint.
• The Product Owner answers questions but does not direct the team’s choices.
• The outcome is the Sprint goal and the Sprint Backlog

The Team decides how to turn the selected requirements into an increment of potentially
shippable product functionality. The Team devises its own tasks and figures out who will
do them. This is based on “Accepted responsibility” principle of Agile. The Scrum Master
doesn’t allocate tasks to the team members. In fact the team members themselves decide
and sign up for the tasks individually..

9.2 SPRINT:
• Strictly time boxed to 30 consecutive calendar days: it’s more important to fall short than
to slip the date
• Activities are visible through the Sprint Backlog and Sprint Burndown Charts
• The Product Owner refrains from tinkering with priorities
• Within the sprint, there are many possible engineering practices!
• Changes
• Team adds new tasks whenever they need to in order to meet the sprint goal
• Team can move unnecessary tasks
• But : sprint backlog can only be updated by the team
Service Delivery Handbook Page 6 of 12
• Estimates are updated whenever there is new information. For more information on
estimates, please refer ITS-S-G007H Agile Guidelines, Section on Agile estimation.

9.3 SCRUM MEETINGS:

Daily scrum meetings are held by the team to check the status on work being done as per
following:

• Parameters
• Daily
• 15-minutes
• Stand up
• Not for problem solving

• Three questions are answered by each team member

• What did you do yesterday?
• What will you do today?
• What obstacles are in your way?

• Scrum master leads the meeting and assesses the responses from each person

Purpose of Scrum meetings:

• Help the team to uncover potential problems as early as possible.
• Daily meetings lead to knowledge socialization and promotes self organizing team
structure

9.4 SCRUM OF SCRUMS

Scrum advocates team size of 7-9 members. If teams are of larger size then, Scrum of
Scrums is done as per following.

• Large teams are broken down into smaller teams

• Scrum meeting team happens daily for each team. After this, team leads of each team
have a Scrum meeting among themselves daily.
• Following is discussed
• What did my team do yesterday to advance the objectives of the Sprint
• What will my team do today
• What are the barriers that could keep my team from meeting its commient to the
Sprint
• This meeting takes place after daily SCRUMs
• When more than one Scrum team works simultaneously on a project, it is referred to as a
“scaled project”, and the mechanisms employed to coordinate the work of these teams are
called scaling mechanisms.
• The process of defining and prioritizing the non-functional requirements for scaling is
called staging.

Service Delivery Handbook Page 7 of 12

Service Delivery Handbook Page 8 of 12
 9.5 SPRINT REVIEW MEETING
The purpose of the Sprint review is for the Team to present to Product Owner and
stakeholders functionality that is done as per following:
• Team presents what is accomplished during the sprint
• Team demonstrates product increment to product owner’s satisfaction.
• Time boxed to one hour of preparation and four hours of meeting.
• Informality is encouraged.
• Functionality that isn’t done cannot be presented
• 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.
• At the end of the Sprint review, the Scrum Master announces the place and date of the
next Sprint review to the Product Owner and all stakeholders.

9.6 SPRINT RETROSPECTIVE

• A retrospective is a ritual gathering of a community at the end of a project to review the
events and learn from the experience
• It can be done at end of sprint/iteration/ release or any specific event/situation requiring a
re-look.
• It is time boxed to three hours.
• Following are the activities:
Service Delivery Handbook Page 9 of 12
 • Team, Scrum Master, and (optionally) Product Owner review the last Sprint
• Teams get together to discuss the following
 What did we do well
 What did we learn
 What should we do differently the next time
 What still puzzles us
• Actionable items are presented to the Product Owner for prioritization as non-
functional requirements.
• Sprint retrospective template is used to capture information of the same.

What a Retrospective is NOT

• Retrospectives are NOT about blame

• Problems (opportunities) arise. The focus is on what we can learn from what
happened
• Retrospectives are NOT a witch hunt
• Retrospectives are NOT about gathering specific information
• They are a free-flowing brainstorm on opportunities and ways to resolve them

Sprint retrospective details can be logged in Retrospective worksheet of ITS-E-T061E

Iteration Metrics Template.

10. SCRUM ARTEFACTS

10.1 THE PRODUCT BACKLOG

 Product backlog is a list of all desired work on the project. It is a prioritized list of
project requirements or features that provide business value for the customer
 Usually a combination of
 Story based work
 Task based work
 List is prioritized by the Product owner
 Items can be added to the backlog at any time (this is how changes are introduced)
 This activity is not intended to analyze the system, merely to scope and list its
requirements and not to how it would be done
 The product backlog consists of three types of items:
 Product functionality - what functions could the system perform to deliver
the value anticipated in the product vision.
 Non-functional requirements - for the product to deliver the necessary
value, what operational aspects must it demonstrate, such as performance,
security, reliability, and cost requirements
 Environmental requirements - what capabilities and environments must be
in place for the product to be developed and delivered
 In , Product backlog is maintained as per ITS-E-T026C Product backlog template.
 ITS-E-T036A User Story template and ITS-E-T061B Use case template are used
for effective estimation, prioritizing requirements. Refer ITS-E-G036A User Story
Guidelines.

Service Delivery Handbook Page 10 of 12

 10.2 THE SPRINT BACKLOG
 The Sprint Backlog is the list of tasks that the Scrum Team is committing that they
will complete in the current Sprint.
 Scrum team takes the sprint goal and decides what tasks are necessary
 Selected by team at outset of Sprint
 Scrum master maintains the sprint Backlog by updating it to reflect which tasks
are completed and how long the team thinks it will take to complete those that
are not yet done
 Changes during Sprint as information is discovered
 Okay to use other engineering practices (stories, micro-iterations), but progress
must be reported in the backlog
 Managers don’t make decisions for the team
 Time estimates must be updated daily
 In , Sprint backlog is maintained as per ITS-E-T026D Sprint backlog template.
 ITS-E-T036A User Story template and ITS-E-T061B Use case template are used
for effective estimation, prioritizing requirements.
10.3 THE SPRINT BURNDOWN CHART
 The estimated work remaining in the Sprint is calculated daily and graphed
resulting in a Sprint Burndown chart
 The burn-down chart is emotionally powerful because there is a special feeling
about hitting the number zero that helps people get excited about completing their
work and pressing forward
 In , Sprint Burndown chart is maintained as per ITS-E-T026D Sprint Burndown
chart template

10.4 THE PRODUCT INCREMENT

 At the end of every Sprint the team should have delivered a production quality
increment of the system.
 The Product Increment is what is demonstrated to the users and stakeholders -
working software rather than mock-ups, documents or hand waving. Delivers
measurable value
 Product Increment should be “Potentially Shippable”. The process can be halted
after every Sprint and there will be some value, some ROI
 It must be a product, no matter how incomplete

11. AMENDMENT HISTORY

Ver Date Author(s)/ Approved by Nature of Changes

Function
I1.0 21 Jul 2006 GA,MK(QMG) Ananthan (CH, First Issue
QMG)

Service Delivery Handbook Page 11 of 12

Service Delivery Handbook Page 12 of 12