Qguide 040

R Systems International Ltd.
C-40, Sector 59
Noida 201 307
(U.P.), India
http://www.rsystems.com/
SCRUM Guidelines
Document Id.: Qguide040
Version No.: 1.3
Released on: 31/03/20
This document of R Systems International Ltd. is for internal circulation. No part of this publication may be
reproduced, stored in a retrieval system, or transmitted in any form or by any means – recording,
Versionelectronics
photocopying, No 0.0 Pagewritten
and mechanical without prior 1 of 16permission of R Systems International
Release Date:
Ltd.
DOCUMENT CONTROL SHEET
Document History
Ver. Release DCR Description of Change Authored/ Reviewed Approved
No. Date Ref Revised By By By
1.0 10/03/11 DCR/324 Release Version Sanjay Rana SEPG SEPG Head
1.1 28/08/12 DCR/351 Reclassification of QMS QA Group SEPG NK Garg
documents- changed from
‘restricted’ to ‘internal’
1.2 01/01/14 DCR/373 RSI Logo Updated QA Group SEPG NK Garg
1.2 03/10/16 DCR/390 Reviewed as per ISO 9001:2015 QA Group SEPG NK Garg
requirements and no changes
made
1.2 03/10/16 NA Yearly review on 10/11/17 and QA Group SEPG NA

no changes made

no changes made

no changes made
1.3 31/03/20 DCR/406 Section 7.2.3 updated to update QA Group SEPG NK Garg
estimation process
Section 3 updated to include
Agile Estimation Form
(Form159)
no changes made
Notes:
• Only controlled hardcopies of the document shall have signatures on them.
• This is an internal document. Unauthorized access or copying is prohibited.
• Uncontrolled when printed unless signed by approving authority.
© R Systems International Limited 2020
Version No 1.3 Page 2 of 16 Release Date: 31/03/20

Table of Contents
1 PURPOSE ..................................................................................................................4
2 SCOPE .......................................................................................................................4
3 REFERENCES ...........................................................................................................4
4 ROLES & RESPONSIBILITIES ...................................................................................4
5 ENTRY CRITERIA ......................................................................................................5
6 INPUT .........................................................................................................................5
7 PROCESS ..................................................................................................................5
7.1 INITIATION: Maintain Product Backlog ................................................... 6
7.2 PLANNING: Plan Sprint ........................................................................... 7
7.3 EXECUTION: Develop Sprint ................................................................ 10
7.4 MONITOR & CONTROL: Review Sprint ................................................ 12
7.5 CLOSURE: Sprint Retrospective ........................................................... 13
8 COMMUNICATION ...................................................................................................14
9 EXIT CRITERIA ........................................................................................................14
10 OUTPUT ...................................................................................................................14
10.1 Velocity .................................................................................................. 14
10.2 Sprint burn-down chart .......................................................................... 14
10.3 Release burn-down chart....................................................................... 15
11 APPENDIX: Acronyms and Definitions .....................................................................16
11.1 Acronyms............................................................................................... 16
11.2 Definitions .............................................................................................. 16

©R Systems International Limited. Internal Qguide040
1 PURPOSE
The purpose of this document is to establish Scrum practices guideline at organization
level for the projects that follows Agile methodology. The Scrum practice
characterizes with:
• A process with a set of roles and practices for agile development
• An Iterative approach = time-boxed (sprints)
• Incremental approach = features added incrementally
• Continuous process improvements = retrospectives
• Uses generative rules to create an agile environment for delivering projects
2 SCOPE
This guideline is applicable for all type of projects - development, enhancement and
testing projects executed at RSI using Scrum practices.
3 REFERENCES
Document Document Title Document Reference
Category No.
On-line Project Tracking and Reporting (PTR)
http://psuite.india.rsystems.
systems com/psuite
Bug Tracking Tool and Reporting http://zerod.india.rsystems.c
(BTR) om/zerod/
Procedures
Guidelines
Forms/ MBR /PCBs Reports Format0001
Formats/ Goal Tracking Sheet
Reports Agile Estimation Form Form159
4 ROLES & RESPONSIBILITIES
The responsible person or group of people for carrying out various Scrum
ceremonies, tasks associated with it to produce desired product and artifacts with
respect to business needs are indicated below:
S. No. Task Responsibility
1 Define the product features and prioritize user stories Product Owner
2 Finalize the Sprint Goal Product Owner
3 Estimate prioritized user stories Team
4 Baseline Sprint Backlog ScrumMaster
5 Daily Scrum Meeting ScrumMaster
6 Sprint Review Product Owner

5 ENTRY CRITERIA
• Customer’s agreement for Agile methodology
• Contract type is Time & Material
• Organization’s set of standard processes defined & established
6 INPUT
• Product Backlog
• Sprint Goal
• Velocity
7 PROCESS
INITIATION: MAINTAIN PRODUCT BACKLOG Product Backlog

Product owner, Customer => Prioritized User stories)
PLANNING: PLAN SPRINT Sprint Backlog,

Estimated tasks
Involves Product owner, Scrum master, Team
EXECUTION: DEVELOP SPRINT Burn-down chart,

– Daily scrum meetings Task Impediments,
– Scrum Master to remove impediments Velocity
– Progress tracked with whiteboard, burn-down charts
Sprint feedback,
MONITOR & CONTROL: SPRINT REVIEW
Accepted or
– Demo, invite everyone including customer
Rejected deliveries
– Was the sprint goal met according to customer?
CLOSURE: RETROSPECTIVE Post Sprint

– What do we want to start doing? Analysis, Process
– What do we want to stop doing? Improvements
– What do we want to keep doing?

7.1 INITIATION: Maintain Product Backlog
The product backlog (or "backlog") is the requirements for a system, expressed as a
prioritized list of product backlog Items. These included both functional and non-
functional customer requirements, as well as technical team-generated
requirements. While there are multiple inputs to the product backlog, it is the sole
responsibility of the product owner to prioritize the product backlog.
INITIATION: MAINTAIN PRODUCT BACKLOG

Inputs:
• Defined User stories Product Backlog
• Prioritized User stories
Responsibility:
• Product Owner, Customer, Sponsor
A product backlog
• describes "what" will be built
• translates requirements into user stories
• consists of user stories = one or two sentences in language of customer
• contains rough estimates (in days) for each prioritized user stories
• indicates priorities of user stories, reprioritized after each sprint

7.2 PLANNING: Plan Sprint
Sprint is an iteration of work during which an increment of product functionality is

implemented. Sprints are time-boxed iteration. The duration is usually 2-4 weeks.
Task type could be - Design tasks, Coding tasks, Testing tasks, Documentation
tasks. The sprint starts with a one-day sprint planning meeting. Many daily Scrum
meetings occur during the sprint (one per day). At the end of the sprint, there is a
sprint review meeting, followed by a sprint retrospective meeting.
PLANNING: PLAN SPRINT

Inputs:
• Prioritized User stories
Sprint Goal,
• Team Capacity
Sprint Backlog,
• Sprint Velocity Estimated tasks
Responsibility:
• Scrum Team, Scrum Master, Product Owner
Method:
• Sprint Planning Meeting, Estimation
7.2.1 Sprint Goal
Sprint goals are the result of a negotiation between the product owner and the
development team. Meaningful goals are specific and measurable (instead of
"Improve scalability" try "Handle five times as many users as version 0.8). Scrum
focuses on goals that result in demonstrable product. The product owner is
entitled to expect demonstrable product (however small or flimsy) starting with the
very first Sprint. In iterative development, subsequent Sprints can increase the
robustness or size of the feature set.
While some specific product backlog items may not be done at the end of a sprint,
it should be very unusual for a team not to meet its sprint goals. Scrum requires
the team to notify the product owner as soon as it becomes aware it will not meet
its goals.
7.2.2 Sprint Planning Meeting
The product owner kicks-off the sprint with time-boxed one-day sprint planning
meeting with the stakeholders. During the sprint planning meeting, backlog items
are moved from the product backlog into a sprint, based on the product owner's
priorities. This process involves:
• Translate user stories into "how" a requirement is to be built,
• Estimate the user stories (planning poker) taking high level design into
consideration,
• Negotiate with the team for what to include in the sprint considering the team
capacity and the past performance (velocity).

7.2.3 Estimation Process
Planning Poker
The user stories are estimates using Delphi technique. It is performed during the
Sprint planning meeting.
The method involves:

– Entire team (pigs, chickens can be present) participates
– Everyone gets a deck of cards with numbers representing the number of
story points (number of cards and points to be determined)
– For each user story, everyone estimates the number of story points
individually
– While estimating the story points, the team members categorize the user
story based on different complexity (Extra Large, Large, Medium, Small
etc.)
– If a user story takes too long, break it down
– Show cards at same time
– Discuss discrepancies and arrive at an estimates
After the size of a story is determined effort is calculated by multiplying the

size with the range of velocity (determined from past data).
While planning for a sprint/release, estimated efforts for the entire

sprint/release is adjusted on the basis of influencing factors/buffers
Form159 is used to estimate the size and effort based on the above method
7.2.4 Sprint Backlog
Sprint backlog defines the work for a sprint, represented by the set of tasks that
must be completed to realize the sprint's goals, and selected set of product
backlog items. A sprint task (or task) is a unit of work generally between 4 and 16
hours. Team members volunteer for tasks. They update the estimated number of
hours remaining on a daily basis, influencing the sprint burn-down chart.

7.2.5 Engineering Practices
The scrum framework allows the team to use and evolve the engineering practices
that is needed to be performed to deliver the sprint goal. During the sprint planning
meeting, the team will discuss and negotiate with the product owner about the
definition of “Done”. The greed upon definition of “Done” will be input for defining
the basic engineering practices that the team will follow while working on the user
stories. It will also reflect in the sprint “velocity” and hence the sprint planning will
take this factor into account.
What all engineering processes will constitute the definition of “Done”? Whether it
will be just coding and unit testing? or will it also include system testing and other
testing? If any of the steps is not performed in the agreed upon definition of
“Done”, then it will be considered as “not done”. The product owner will keep a
track of the user stories in their product backlog as “Done” or “not done”. The
product owner will then re-prioritize the “not done” user stories in the subsequent
sprints.

7.3 EXECUTION: Develop Sprint
The Sprint backlog contains the detailed tasks that need to be worked to deliver the
working functionality. Anyone in the team can add, delete or change the tasks in the
sprint backlog. If work is unclear, sprint backlog items are added with a larger
amount of effort and break it down later. Tasks estimates are revisited and adjusted
as soon as enough clarity is available. Estimates revision is done on daily basis
until the task is done. A definition of ‘Done’ is established within the team and all the
stakeholders.
EXECUTION: DEVELOP SPRINT

Inputs:
• Sprint goal
Burn-down chart,
• Sprint Backlog Task Impediments,
• Detailed tasks Velocity
Responsibility:
• Scrum Team, Scrum Master, Product Owner (optional)
Method:
• Daily stand-up Meeting, Additional Meetings
Sprint tasks are never assigned to the team, rather individuals sign up for the work
of their own from the list of sprint tasks. The estimated work remaining (effort) is
updated daily to indicate the sprint burn-down. The work remaining (effort) is also
updated as and when more details on the tasks are available.
During the sprint, the team must not be interrupted with additional requests.
Guaranteeing the team won't be interrupted allows it to make real commitments it
can be expected to keep. Out of practical necessity, some teams choose to bend
this rule by declaring some team members 80 percent available at the outset so
they still have some cycles left for "Priority One" bugs and emergencies. But this is
a slippery slope and should be avoided whenever possible.
7.3.1 Daily Stand-up meeting
A 15-minute daily meeting should take place with the entire team including product
owner (customers and other also welcome but will not speak). Each team member
should answer three questions:
1. "What have I done since the last Scrum meeting? (i.e. yesterday)"
2. "What will I do before the next Scrum meeting? (i.e. today)"
3. "What prevents me from performing my work as efficiently as possible?
(i.e. impediments)"
The meeting is not a progress reporting and answers should not to be addressed
to scrum master, but to inform each other. The ScrumMaster ensures that the
meeting should not stretch the time limit and participants call sidebar meetings for
any discussions that go too far outside these constraints.

The Scrum literature recommends that the meeting should take place first thing
in the morning, as soon as all team members arrive. It should take place same
time, same location (punishment for tardiness).
7.3.2 Impediments
Anything that prevents a team member from performing work as efficiently as

possible is an impediment. Each team member has an opportunity to announce
impediments during the daily Scrum meeting. The ScrumMaster is charged with
ensuring impediments get resolved. ScrumMasters often arrange sidebar
meetings when impediments cannot be resolved on the spot in the daily Scrum
meeting.
7.3.3 Daily Tracking
Team assigns the user stories to themselves depending on their competency.

They analyze user stories and identify tasks. The tasks are added against the user
stories and estimates are revisited based on the identified tasks. Some tasks
could also be discovered later on if not identified in the initial analysis if the user
stories. The Sprint backlog is updated on daily basis in which tasks are added or
deleted, estimates are revisited. Team keeps on updating the remaining effort on
the tasks at least daily and as frequently as possible. The remaining effort will
reduce as the team continues to work on a user story. It might be possible that the
remaining effort may increases on a day due to the estimates revision and
discovered tasks. The sum of remaining effort of all task on any day indicate the
sprint status at the end of any day.

7.4 MONITOR & CONTROL: Review Sprint
At sprint review meetings, the team demonstrates the new feature that they have
completed during the sprint. The primary purpose of the demo is to inspect what
the team has delivered and gather feedback from the attendees to adapt the plan
for succeeding sprint.
MONITOR & CONTROL: SPRINT REVIEW

Inputs:
• Sprint goal Sprint feedback,
• Sprint Backlog Accepted or
Responsibility: Rejected deliveries
• Product Owner, Scrum Master, Scrum team
Method:
• Sprint Review
Sprint Review is much more than a demonstration. Usage of slides should be to

the minimum if cannot be avoided completely except for the Design or
Documentation type of tasks for the sprint. Anyone and everyone should be invited
for the demo or presentation. The feedback are collected and collated to analyze
whether or not the sprint goal has met which may lead to acceptance or rejection
of the deliveries.
Sprint review has many possible outcomes including cessation of the project. In
most instances, team is authorized to continue for another sprint and goal for next
sprint is set.

7.5 CLOSURE: Sprint Retrospective
The sprint retrospective meeting is the final meeting of the sprint. It follows
immediately after the sprint review. It is never omitted!
CLOSURE: RETROSPECTIVE
Inputs:
• Sprint feedback,
Post Sprint
• Burn down chart Analysis, Process
• Impediments Improvement
Responsibility:
• Scrum Master, Scrum team, Product Owner
Method:
• Retrospective Review of sprint
The sprint retrospective focuses on the process – the way scrum team is working
together including their skills, development process, tools etc. The meeting
participant is restricted to the scrum team - ScrumMaster, Product owner and
Team. Anyone from outside is included strictly on need based. The meeting
duration should not be more than 45 minutes and the discussion should be
focused to seek comments from each one on the 3 questions only:
1. What should the team continue to do?

It identifies the (best) practices that have worked well for the team, and
team should continue to do it in next scrum too.
2. What should the team stop doing?

It identifies the practices that have not worked well for the team, and team
should stop practicing it in next scrum or look for process improvements.
3. What should the team start doing?

It triggers the need of a process improvement opportunity.

8 COMMUNICATION
Meetings Frequency Duration Participants Outcome

Sprint Planning Sprint 4 hours Product Owner, Sprint Goal,
Beginning Scrum Master, Sprint Backlog
Scrum Team
Daily Stand-up Daily 15 Minutes Product Owner, Day’s updates,
(Time- Scrum Master, Next day plan,
boxed) Scrum Team Task Impediments
Sprint Review Sprint End 4 hours Product Owner, Delivery feedback,
Scrum Master, Accepted or
Scrum Team, rejected deliveries
Customer
Retrospective Sprint End 15-30 Product Owner, Post Sprint
minutes Scrum Master, Analysis
Scrum Team
9 EXIT CRITERIA
• Sprint goal is achieved

• Sprint duration expires
10 OUTPUT
10.1 Velocity
Sprint Velocity is a measurement of how much story points (size), the team can
handle in one sprint. It can also be established on a sprint-by-sprint basis, using
commitment-based planning. Once established, can be used to plan projects and
forecast release and product completion dates. Assuming the team composition
and sprint duration are kept constant, completion dates can be predicted using
velocity
10.2 Sprint burn-down chart

A sprint burn-down chart (or "sprint burn-down graph") depicts the total task hours
remaining per day. This shows you where your team stands regarding completing
the tasks that comprise the product backlog items that achieve the goals of the
sprint.
The graph can go up and down since the individual tasks (that are) being worked
on are re-estimated per day. Ideally the chart burns down to zero by the end of the
sprint. If the team members are reporting their remaining task hours realistically,
the line should bump up and down chaotically.

(X-axis represents days in the sprint;

Y-axis represents effort remaining, usually in ideal engineering hours)
As a best practice, the sprint burn-down chart should be displayed prominently to

motivate the team. It also acts as an effective information radiator. A manual
alternative to this is a physical task board.
10.3 Release burn-down chart

On a Scrum project, the team tracks its progress against a release plan by
updating a release burn-down chart at the end of each sprint. The chart indicates
the number of requirements left. Requirements can be added or removed, and
constantly prioritized.
(X-axis represents the sprints;

Y-axis represents the amount of work remaining at the start of each sprint)
On the above shown release burn-down chart, the team started a project that was
planned to be eleven two-week sprints. They began with 200 story points of work.
The first sprint went well and the chart indicates that they had around 180 story
points of work remaining after the first sprint. During the second sprint, however,
the estimated work remaining actually burned up. This could have been because
work was added to the project or because the team changed some estimates of

the remaining work. From there the project continued well. Progress slowed during
sprint 7 but then quickly resumed.
11 APPENDIX: Acronyms and Definitions
11.1 Acronyms
Abbreviation Description
PCB /MBR Process Capability Baseline/Metrics Baseline Report
BTR Bug Tracking & Reporting
RSI R Systems International Ltd.
PTR Project Tracking & Reporting
11.2 Definitions
Pig & Chicken

A pig and a chicken are walking down a road. The chicken looks at the pig and says,
"Hey, why don't we open a restaurant?" The pig looks back at the chicken and says,
"Good idea, what do you want to call it?" The chicken thinks about it and says, "Why
don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed but
you'd only be involved.”
Ham and Eggs - committed or just involved

• Pigs
– Product Owner - voice of the customer
– Scrum Master - enforcer of Scrum process, facilitates (removing
impediments) team to reach sprint goal
– Team - cross-functional (design, developer, test), usually 5-9 people who
does the work
• Chickens
– Users
– Stakeholders (Customers, Vendors)
– Managers

Qguide 040

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Qguide 040

Uploaded by

Copyright:

Available Formats

R Systems International Ltd.

Document Id.: Qguide040

Version No.: 1.3

Released on: 31/03/20

1.2 01/01/14 DCR/373 RSI Logo Updated QA Group SEPG NK Garg

1.2 03/10/16 NA Yearly review on 10/11/17 and QA Group SEPG NA

1.2 03/10/16 NA Yearly review on 03/12/18 and QA Group SEPG NA

1.3 02/12/19 NA Yearly review on 02/12/19 and QA Group SEPG NA

© R Systems International Limited 2020

Version No 1.3 Page 2 of 16 Release Date: 31/03/20

Version No 1.3 Page 3 of 16 Release Date: 31/03/20

4 ROLES & RESPONSIBILITIES

Version No 1.3 Page 4 of 16 Release Date: 31/03/20

INITIATION: MAINTAIN PRODUCT BACKLOG Product Backlog

PLANNING: PLAN SPRINT Sprint Backlog,

EXECUTION: DEVELOP SPRINT Burn-down chart,

CLOSURE: RETROSPECTIVE Post Sprint

Version No 1.3 Page 5 of 16 Release Date: 31/03/20

7.1 INITIATION: Maintain Product Backlog

INITIATION: MAINTAIN PRODUCT BACKLOG

Version No 1.3 Page 6 of 16 Release Date: 31/03/20

7.2 PLANNING: Plan Sprint

Sprint is an iteration of work during which an increment of product functionality is

PLANNING: PLAN SPRINT

7.2.1 Sprint Goal

7.2.2 Sprint Planning Meeting

Version No 1.3 Page 7 of 16 Release Date: 31/03/20

7.2.3 Estimation Process

The method involves:

After the size of a story is determined effort is calculated by multiplying the

While planning for a sprint/release, estimated efforts for the entire

7.2.4 Sprint Backlog

Version No 1.3 Page 8 of 16 Release Date: 31/03/20

7.2.5 Engineering Practices

Version No 1.3 Page 9 of 16 Release Date: 31/03/20

7.3 EXECUTION: Develop Sprint

EXECUTION: DEVELOP SPRINT

7.3.1 Daily Stand-up meeting

Version No 1.3 Page 10 of 16 Release Date: 31/03/20

Anything that prevents a team member from performing work as efficiently as

7.3.3 Daily Tracking

Team assigns the user stories to themselves depending on their competency.

Version No 1.3 Page 11 of 16 Release Date: 31/03/20

7.4 MONITOR & CONTROL: Review Sprint

MONITOR & CONTROL: SPRINT REVIEW

Sprint Review is much more than a demonstration. Usage of slides should be to

Version No 1.3 Page 12 of 16 Release Date: 31/03/20

7.5 CLOSURE: Sprint Retrospective

1. What should the team continue to do?

2. What should the team stop doing?

3. What should the team start doing?

Version No 1.3 Page 13 of 16 Release Date: 31/03/20

Meetings Frequency Duration Participants Outcome

• Sprint goal is achieved

10.2 Sprint burn-down chart

Version No 1.3 Page 14 of 16 Release Date: 31/03/20

(X-axis represents days in the sprint;

As a best practice, the sprint burn-down chart should be displayed prominently to

10.3 Release burn-down chart

(X-axis represents the sprints;

Version No 1.3 Page 15 of 16 Release Date: 31/03/20

11 APPENDIX: Acronyms and Definitions

Pig & Chicken