THE SCRUM

GUIDE
2018

Designed by Scrumversity

www.scrumversity.org
232, OLD Connecticut Path, Wayland, MA 01778-3149, USA | Email - info@scrumversity.org
Scrumversity
Table of Contents
Scrum Summery .........................................3
Uses of Scrum ............................................3
Scrum Theory .............................................3
Transparency ..............................................4
Inspection ...................................................4
Adaption .....................................................4
Scrum Values .............................................5
Commitment ...............................................5
Focus .........................................................5
Openness ...................................................5
Respect ......................................................6
Courage .....................................................6
Scrum Roles ..............................................6
Scrum Master .............................................6
Responsibilities of Product Owner .............7
Responsibilities of Development Team ......7
Responsibilities of Organization .................7
Responsibilities of Community ...................7
Scrum Master is not Responsible ...............8
Development Team .....................................8
www.scrumversity.org
Page 2
Product Owner ...........................................9
Product Owner Roles & Responsibilities ....9
Product Owner can't Held responsible ......10
Scrum Events ............................................10
The Sprint ..................................................10
Sprint Planning ..........................................11
Daily Scrum Meeting .................................12
Sprint Review ............................................12
Sprint Retrospective ..................................13
Product Backlog ........................................14
Sprint Backlog ..........................................15
Sprint Burn-Down Chart ............................16
Scrum-Estimation ......................................16
Scrum Estimation Techniques ...................16
Planning Poker Techniques .......................17
Benefit of Planning Poker Estimation ........17
Expert Opinion ..........................................17
Analogy .....................................................17
Disaggregation ..........................................18
Conclusion ................................................19
Scrumversity Page 3

Scrum summary
Scrum is a subsidiary of Agile. It is a lightweight and most prevalent framework for agile
development. Scrum being an agile process allows us to focus on delivering the maximum
business value in the least time possible and scrutinize the actual working software (every
fortnight to a month).

A “process framework” is a specific set of criteria which must be pursued for a process to be
balanced with the framework. (For instance, the Scrum process framework entails the use of the
XP framework that requires pair programming, development cycles called Sprints etc.)

“Lightweight” means that the process is kept concise to secure the maximum amount of
productive time available for getting valuable work finished.

Uses of Scrum:
Scrum was created in the early 1990s to develop and manage products. It has been used all over
the world to:

1. Explore and recognize feasible markets, product potential and technologies;

2. Expand products enhancement;
3. Products launch and refinement as consistently as many times per day;
4. Advance and preserve Cloud (online, secure, on-demand) and other functional surroundings
for product use; and,
5. Retain and refurbish products.

Scrum has been employed to augment programming, equipment, self-reliant vehicles, schools,
government, advertising, and systems of collaborating capacity. It also deals with the task of asso-
ciates and almost everything we consume in our everyday lives as individually and several hierar-
chies.

Scrum Theory
There are three cornerstones of Scrum Theory. They are as follows:

1. Transparency
2. Inspection
3. Adaptation

www.scrumversity.org
Scrumversity Page 4

Transparency:
It’s a crucial part of Empirical Process Control principle that is implemented is Scrum. Transparen-
cy means the various aspects of the process that affect that outcome must be conspicuous to
everybody involved in the project accomplishment. The group of people involved with the project
is referred to as stakeholders. Because of transparency, all the features of any Scrum procedure
can be perceived by anyone that encourages a simple and lucid flow of information throughout the
organization and creates an open work culture. We proudly boast a Project Vision Statement in
Scrum which can be seen by all stakeholders and the Scrum Team. An open Product Backlog with
prioritized User Stories, both within and outside the Scrum Team, is discernible. Scrum boards,
Burndown Charts, and other project health indicators called information radiators are made avail-
able in the project workspace to create a transparent and collaborative environment assisting Em-
pirical Process Control. Daily Standup Meetings are conducted to make sure everyone’s aware of
everything. The Scrum Team exhibits the potentially shippable Deliverables at the end of iteration
in which all the stakeholders are invited to the Sprint Review Meetings. In contrast to a meticulous
process, Scrum accentuates simple values such as transparency and self-managing teams to
reinforce empirical process control.

Inspection:
It necessitates assorted aspects of the process to be probed enough so that the unacceptable
variances can be spotted. Inspection in Scrum is depicted through the use of a common Scrum
board; compilation of feedback from the customers as well as other stakeholders; and analysis of
advance-
the Deliverables. The Scrum process upholds regular examination of the Artifacts and advance
ment to recognize and correct undesirable variations. Inspection occurs during the Daily Scrum,
Sprint Planning Meeting, Sprint Review, and Sprint Retrospective – collectively referred to as the
Scrum Events.

Adaptation:
It ensues when the Stakeholders and Scrum Core Team study through inspection. Then they
adapt by revamping the work they are doing. Scrum Team members (in the Daily Standup Meet-
ings) candidly discuss impediments to complete their tasks. They also seek help from other team
members. However, the risk identification is carried out and repeated throughout the project. The
developments can also result in Change Requests as discussed earlier. To offer guidance, the
Scrum Guidance Body interacts with Scrum Team members during the processes.

These three bedrocks of the Empirical Process Control ensure that the matters which endeavor in
the Traditional Waterfall scheme for actions don't transpire in Scrum Projects.

www.scrumversity.org
Scrumversity Page 5

Scrum imparts four renowned events for assessment and alteration. They are:

1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective

SCRUM Values:
There are five core values of Scrum which outline the base of our decisions and actions we exe-
cute.

1. Commitment
2. Focus
3. Openness
4. Respect
5. Courage

Commitment: IScrum team members must be committed to victory, willing to jot down
pragmatic goals, and follow them till the end no matter whatever it takes. You must participate
because it’s where you function as a team to meet and preferably beat your deadlines. The Scrum
model guarantees the authority and freedom to undertake that. Sprint is an event at the core of
scrum that requires explicitly defined goals set within deadlines. In this model, you can break down
these goals into the small bits of work possible so that you know what you’re stepping into. Know-
ing the realistic helps you set goals and reach your commitments.

Focus: Scrum is not only built around the theory of focus but to focus only on a few things
which results in a concrete role and goals. Your responsibility is to use your role as a springboard
and produce the results. Having made your aims straightforward earlier, now concentrate all your
energy into contributing your best.

Openness: There are no future surprises because everything in our project is crystal clear
and liable to inspection and improvement. The essence of scrum is the agile cornerstones of
empiricism: transparency, inspection, and adaptation. Information radiators (huge, visible charts)
and real-time intelligence allow for untrammeled action. The point is you’re not used to this level
of disclosure but after your organization catches on they won’t compromise.

www.scrumversity.org
Scrumversity Page 6

Respect: Each team member is handpicked for his strengths and along with them come their
weakness and opportunities to learn, adapt, and flourish. The rule within the realm of scrum is that
each participant must be respected and valued by everyone else. Harmony is created in a project
when all the roles are in sync which are linked by a progressive chain of development, the rhythms
of which oozes success. Because you operate as a team, if you see any chord out of tune, you
need to fix it, meaning if anyone isn’t matching the rhythm it’s in your best interest to help that
person and advance as one. It’s ingrained in people’s minds to produce good results so if you
seek positive, you shall find it just as you with the negative because respect is the cement of posi-
tivity which paves the road for a healthy and productive environment.

Courage: Scrum is all about the creativity and innovation. Even your best ideas in a scrum
model will be met by criticism and get challenged. Procedures done out of habit are not
entertained anymore so you will have to adopt a new process that is built on what the team see fit
to be victorious.

Scrum Roles – The Scrum Team

There are three roles laid out in Scrum:

1. Scrum Master
2. Development Team
3. Product Owner

Scrum Master: He makes sure that the team performs and follows on the excellence and
standards of Scrum on par with a mentor. The Scrum Master is a Servant leader who doesn’t have
control over the team, yet has authority over the process. No one reports to him, he only leads the
team.

Grasps the vision of a project and guides the team to work towards it.

Aids Product Owner in the explication of the product backlog. Tutor product owner on prioritization
techniques to help him give the product backlog precedence to incremental release.

Facilitate the sprint planning meeting. Help team work together to create sprint backlog and goal.
Help the team to inspect and adapt based on feedback from field and previous Sprints.

www.scrumversity.org
Scrumversity Page 7

Teach the team to self organize and help them solve hindrances. Protect them from external inter-
face. Lead them to achieve the sprint goal.

Facilitate the Daily Standup Meeting and to inspect the progress towards sprint goal and adapt
their plan.

Facilitate the Sprint Review and ensure that the focus is on integrated product increment.

Facilitate Sprint Retrospective and help team inspect and adapt the process. Ensures everyone is
heard and appreciated. Help the team to identify the actions to enact in the next Sprint.

Responsibilities towards the Product Owner:

Find the techniques for effective product backlog management.
Teach the Scrum Team for creating clear and concise product backlog items.
Understand long-term product planning in an experimental environment.
Communicate vision, goals, and Product Backlog items to the Development Team.

Responsibilities towards the Development team:

Help them becoming a self-organized and cross-functional team.
Illuminate and lead them for creating high-value products.
Remove the obstacles those come in the way of progress.
Enlighten them in managerial environments in which Scrum is not yet fully adopted and under-
stood.

Responsibilities towards the Organization:

Map out, lead, and coach the organization in its Scrum adoption.
Help the employees and stakeholders in understanding Scrum and empirical.
Increase the productivity of the Scrum Team by making changes in the product. Work with
other Scrum Masters to perk up the efficiency of the application of Scrum in the organization.

Responsibilities towards the Community:

Build and strengthen the Scrum community.
Help others understand and ratify Scrum.
Maximize the awareness towards Scrum by reaching outside the network where people don’t
know about Scrum.

www.scrumversity.org
Scrumversity Page 8

Scrum Master is not responsible for:

Managing the resources.
Cannot make any commitments on Schedule and Scope.
Cannot make any decisions on behalf of the Scrum team.
The most important of all is that Scrum Master can be made accountable for the outcome of
the project and is not responsible for the same.

Development Team: It is a self organizing, cross functional team. It is responsible for all
the work necessary to produce working, validated asset.

Comprehend the product vision and incorporate it.

Interpret the product backlog items and assist PO in keeping them ready.
Devote to Sprint goal. Create Sprint backlog. Create enough design.
Convert product backlog into product increment. Help each other and self organize to
achieve the committed sprint goal.
Demonstrate the progress to stakeholders and understand both verbal and non verbal
feedback.
Actively participate and identify process improvement to get better at delivering value.
Focus on technical excellence and engineering practices.
Give fundamental criticism to Scrum Master and Scrum Teams.
Update Release Plan and Prioritized Product Backlog.
Convey Product Releases and arrange this with the client.
Participate in Retrospective Sprint Meetings.
Ensure an unmistakable comprehension of Epic.
Agree with other Scrum Core Team individuals on the Length of Sprint.
Illumination on new items or changes in the current items, assuming any, in the refined
Prioritized Product Backlog.
Contribute to the Product Owner on configuration of User Stories.
Evaluate User Stories declared by the Product Owner.
Submits User Stories to be done in a Sprint.
Contribute to production of the Collaboration Plan and the Team Building Plan.

www.scrumversity.org
Scrumversity Page 9

Creates Task List in accordance with User Stories and conditions.

Assessments exertion for assignments distinguished and if essential, refreshes the Task List.
Make Deliverables.
Be alert of the dangers and manifest activities that alleviate peril, if any.
Reform Impediment Log and conditions.
Upgrade Burndown Chart, Scrum board, and Impediment Log.
Discuss topics looked by singular individuals and look for answers.
Motivate the team.
If there are any dangers, detect them.
Submits \ Change Requests, if needed.
Distinguish alter openings from the present Sprint and correspond on any striking augmenta-
tion for the following.

Product Owner: He is the Project's vital partner. The Product Owner usually will be the
important client of the product if nobody else has a command of who will be. Despite the aptitude,
the Product Owner does not decide how much function occurs in the Sprint cycles or revise the
objectives for that Sprint. Product Owners must be accessible and approachable to the team and
connect with it. The Product Owner addresses both the Team and different Stakeholders.

Product Owner Roles & Responsibilities:

Specify the Project Vision.
Create the Project Charter and Project Budget.
Finish Scrum Master for the task.
Recognize Stakeholder(s)
Handpick Scrum Team individuals.
Map out a Collaboration Plan.
Map out the Team Building Plan with Scrum Master(s).
Resolve User Stories.
Work with Scrum Team to submit User Stories.
Reveal the User Stories to the Scrum Team while making the Task List.
Direct and clarify to the Scrum Team in evaluating.
Exert for assignments.
Explain requirements to the Scrum Team while making the Sprint.

www.scrumversity.org
Scrumversity Page 10

Accumulation.
Explain business necessities to the Scrum Team.
Spruce up the Prioritized Product Backlog.
Acknowledge or reject Deliverables.
Provide fundamental analysis to Scrum Master and Scrum Teams.
Update Release Plan and schedule Product Backlog.
Convey Product Releases and arrange this with the client.
Take part in Retrospective Sprint Meetings.

What the Product owner can’t be held responsible for:

Cannot overrule the Team’s estimates
Cannot disobey the sprint commitments

Scrum Events
Scrum Process Framework is a chain of events and the matching relics. The scrum events are
clocked events, which state that in a project every scrum event has a limited duration. These
events facilitate clearness on the project process to everybody involved in the project. The impera-
tive events of scrum are:

1. The Sprint
2. Sprint Planning
3. Everyday Sprint Meetings
4. The Sprint Review
5. The Sprint Retrospective

The Sprint: A functional product Increment is created during a sprint. Its time span is of two
weeks or one month and this duration persists for all the sprints in the project since we cannot
have varying durations for the sprints in a project. A new sprint starts immediately after the wrap-
ping up of the preceding sprint.
The Sprint Goal is a goal for the sprint providing counsel to the team on why it is building the Incre-
ment which is created during the Sprint Planning meeting. The horizon of the sprint is clarified and
re-negotiated between the product Owner and the Team as more about the requirements is
learned. Therefore, each sprint is associated with it, a definition of what is to be built, a design, and
the flexible plan that will mentor in building it, the development work, and the resultant product
increment.
If the Sprint Goal becomes outdated, a Sprint should be called off. It happens if the organization
changes direction or if the situations of the market or technology vary. Though others have power
over how and when a sprint is conducted but only the product owner can call it off.

www.scrumversity.org
Scrumversity Page 11

It’s not sensible to cancel a sprint when it is going on because of its short duration and the
resources it consumes in order to getting it re-organized which is very rare.
If a sprint is called off and part of the work produced during the sprint is releasable, the Product
Owner accepts it. All the unfinished Sprint Backlog items are put back into the Product Backlog.

Spirit Planning: The planning of the work to be performed in the sprint is done in Sprint
Planning Meeting. The maximum duration of Sprint Planning Meeting is of four hours to two weeks
sprints and eight hours for one month sprints. The Scrum Master guarantees that the meeting
takes place, all the required attendees are present, and they understand the purpose of the sched-
uled meeting. The Scrum Master conducts the meeting to observe the sustenance of discussion
and the timely closure.

The following questions are aimed on Spirit Planning:

What is needed and can be delivered in the Sprint Increment?
How will the achievement of the work needed for the execution of Sprint be done?

The inputs of this meeting are:

The Product Backlog.
The latest product Increment.h
Projected capacity of the Team during the Sprint.
Performance of the Team in the past.

The Scrum Team confers the practicality that can be evolved during the Sprint. Product Owner
provides explanation on the Product Backlog items. The items of the Sprint are selected from the
Product Backlog by the team as they are the finest in assessing what they can achieve in the
Sprint. The team is incorporated of analysts, designers, developers, and testers. The work is
carried out in a mutual manner, hence, lessen the re-work.

The Scrum Team comes up with the Sprint Goal. The Sprint Goal provides guidance to the team
on why it is building the product Increment then the Team elects how it will build the selected prac-
ticality into a working product Increment during the Sprint. The Product Backlog items selected for
the Sprint and the plan for transporting them is called the Sprint Backlog.

The work estimated during a sprint planning might be of varying magnitude in terms of size and
effort. The work is divided into tasks of duration of one day or less by the end of the Sprint Plan-
ning which enables the ease of work allotment and tracking the completion. The team can renego-
tiate the selected Product Backlog items with the Owner of the Product if he reckons that there is
an overload of work or too little work. The team could also invite others who are not a part of
Scrum Team to attend the Sprint Planning meeting to get technical or domain advice or help in
estimation.

www.scrumversity.org
Scrumversity Page 12

Daily Scrum Meetings

This meeting of a quarter of an hour is held every day to understand the work and revise a plan
for the next twenty four hours. To avoid complications, this meeting is held at the same venue and
same time. This meeting is also called as Daily Stand up Meeting.
Each member has to:
Recount his yesterday’s contribution to the team that helped the Team reach the Sprint
Goal.
Explain his today’s input to help the meet the Sprint Goal.
Recognize obstacles he saw that prevent Team from reaching the Sprint Goal.

Daily Scrum is where you plan event even though it’s often confused to be with a status tracking
event.

In a meeting, the contribution must be channeled towards how the team is performing in achieving
the Sprint Goal and the production must always be a new or revised plan that ameliorates the
team’s combined efforts in meeting the Sprint Goal, which is the responsibility of the Team, even
though the Scrum Master organizes the Daily Scrum Meeting and makes sure that the goals of the
meeting are accomplished.

The advantages of the Daily Scrum Meetings are:

Better the communication within the team.
If there are any obstacles recognize them to smooth an early elimination of the same to
minimize effect on the Sprint.
Emphasize and encourage the importance of rapid decisiveness.
Better the skills of the Team level.

Sprint Review
After the completion of every Sprint, a Sprint Review is held to review the presentation of the incre-
ment that is getting released. The stakeholders in this meeting also collaborate to understand
what was performed in the Sprint. Based on this and the alteration to the Product Accumulation
during the Sprint, the attendees arrive at the next steps required that could enhance the value. So
the purpose of Sprint Review is to get feedback and advance together.

Usually, the Sprint Review is held for two hours in a span of two weeks and for four hours for a
month sprints.

www.scrumversity.org
Scrumversity Page 13

The Scrum Master enforces that:

The meetings are held.
The participants grasp the aim.
The meeting is focused on the requisite priority and is finished within the aforementioned
duration.
The features of the Sprint Review contain:
As invited by the Owner of the Product, the attendees include the Scrum Team and the
prospective stakeholders.
The Product Owner describes what Product Backlog items have been used up during the
sprint and what items are left.
The Team discusses and analyses what went well during the Sprint, what hindrances did
they face, and how did they fix them.
The Team shows the work that it has completed and answers if there are any questions
about the Increment.
The entire group discusses what next has to be done. Thus, the Sprint Review provides
valuable input to Sprint Planning of the next Sprint.
The Scrum Team reviews the timeline, budget, their potential, and marketplace for the sub
sequent thrilled release of the product increment.
The result of the Sprint Review is an updated Product Backlog which interprets the
prospective Product Backlog items for the next Sprint.

Sprint Retrospective
The Sprint Retrospective happens after the Sprint Review and before the succeeding Sprint Plan-
ning. This is around an hour meeting for two-week duration sprints and a three hour meeting for
one month duration Sprints.
The objectives of the Sprint Retrospective are to:
Coalesce what they have learned from the last Sprint with regard to people, relationships,
process, and tools.
Discern the major things that went well and be on the lookout for the potential
enhancements.
Create a plan for instigating the improvements to increase product value and its utility.

To optimize the next Sprint outcome, the Sprint Retrospective is an opportunity for the Scrum
Team to brainstorm within the Scrum process framework to make the subsequent Sprint outcome
more successful.

www.scrumversity.org
Scrumversity Page 14

The crucial information that the Scrum Team and the stakeholders need to be aware of for under-
standing of the product under development, the activities done, and the activities being planned in
the project is provided by the Scrum Artifacts.
The below Artifacts are defined in Scrum Process Framework:
Product Backlog
Sprint Backlog
Burn-down Chart
Increment
These are the least required artifacts in a scrum project while projects artifacts are not limited by
them.

Product Backlog: It is an ordered list of features that are required as part of the end
product and it is the only source where the requirements of the product can be met.
It catalogues all the features, functions, requirements, enhancements and fixes the changes to be
made to the product in future releases. Product Backlog items have the traits of a description,
order, estimate, and value. These items are terms as User Stories. Including its content, availabili-
ty, and ordering, the Owner of the Product is responsible for the product pile-up.
A Product Backlog is an ever-changing work of art. The initial version only sorts out the best
understood requirements. The Product Backlog advances as the product and the environment in
which it will be used to progress. It keeps making adjustments and modifications to incorporate the
need to enhance its optimization. It will exist as long as a product does and it enlarges as the prod-
uct is utilized and its value increases. The transformations and modifications in the business
requirements, market conditions, and technology prolong the Product Backlog’s value as an
artifact.
Sprucing up of Product Backlog means adding minute details, estimates, and priority order to the
Product Backlog articles which is a constant procedure performed by the Product Owner and the
Team. The Scrum Team determines how and when the sophistication of the Product will be done.
The Product Owner can update the Product Backlog articles whenever he wants.
The items that are in high demands in the Product Backlog are concise and condensed than prod-
ucts which are low in demands. Precise estimates account for the greater clarity and perfection-
ism. The lower the demand, the less focus will be spared to the details.
Items that are liable to fulfill the candidate requirements for the subsequent Sprint are perfected
so that they can be developed during the Sprint. Items that can be developed by the Team before
a Sprint are deemed to be equipped for selection in a Sprint planning meeting.

www.scrumversity.org
Scrumversity Page 15

Sprint Backlog
It is a set of chosen Product Backlog items and a plan for delivering the product Increment and to
bring about the Sprint Goal. It is the prediction by the Team about what practical use will be made
available in the next Increment and the work needed to deliver that quality as a working product
Increment. It’s more like a plan with enough details that can be understood and the Team to track
in the Daily Scrum. The Team transforms the Sprint Backlog throughout the Sprint and the Sprint
Backlog emerges during the Sprint. This happens as the Team follows though the plan and learns
more about the work needed to pull off the Sprint Goal.
The Teams adds it to the Sprint Backlog as new work is required and as the work is performed,
the anticipated remaining work is updated. But they are removed as the elements of the plan are
considered pointless. Only the Team has the authority to change its Sprint Backlog during a
Sprint. The Sprint Backlog is a conspicuous picture of the work that the Team plans to accomplish
during the Sprint and it belongs only to the Team.
Increment: It is the sum of all the Product Backlog items that are used up throughout the Sprint
combined with the increments of all the previous Sprints. After the completion of a Sprint, the new
Increment ought to be a functional product working properly which implies that it must be useable
and saleable. Whether the Product Owner wants to release it or not, it must be in a top-notch
condition.
A treaty on what is considered to be an Increment is needed by the Scrum Team which is verified
extensively per Scrum Team but team members must have a shared insight of what it means for
work to be complete. This assessment is done when the work is finished on the product
Increment.
The same theory leads the Team in having a clear perception of how many Product Backlog items
it can choose during a Spring Planning. Each Sprint has a goal to deliver releasable feasibility of
the product.
An Increment of product functionality is delivered every Sprint, which is useable so a Product
Owner might decide to launch it straight away. All Scrum Teams must follow it as a minimum if the
knowledge of an Increment is part of the conventions, standards, or guidelines of the development
organization. If the development organization is not a convention of the Scrum Team, it must
explain the definition of Increment suitable for the product. All the Increments can be added to all
the prior Increments and thoroughly tested to ensure they work together.
The blooming of the Scrum Teams accentuates the drastic increase in the measures of the
definition of Increments. The definition of any product validates the standards of the work done on
it.

www.scrumversity.org
Scrumversity Page 16

Sprint Burn-Down Chart

The total work remaining in the Sprint Backlog can be summed at any time in a Sprint which is
tracked by the Team for every Daily Scrum to scheme the possibility of achieving the Spring Goal.
The Team can supervise the progress it has made by the tracking the remaining work throughout
the Sprint.
Sprint Burn-Down Chart is a ritual for portraying the work expanded by the Scrum. It has been
proven to be a practical technique in monitoring the Sprint progress towards the Sprint Goal.

At every Sprint Review the Owner of the Product tracks this total work remaining. The Owner
weighs this amount against the work remaining at previous Sprint Reviews to evaluate progress
toward completing the projected work by the preferred time for the goal. This information is
revealed to all the stakeholders.

Scrum – Estimation
Estimation is done by the entire team in Scrum Projects during Sprint Planning Meeting. The main
goal of this Estimation is to regard the User Stories for the Sprint by Priority and by the Ability of
the team to deliver during the Time Box of the Sprint.
Product Owner guarantees that the scheduled User Stories are clear, can be subjected to estima-
tion, and they are brought to the Product Backlog.
The responsibility for the delivery of the product increment is on the Scrum Team. You must mind
to choose the User Stories for the Sprint based on the size of the Product Increment and the effort
is estimated by means of the past date. Productivity is defined by the effort per User Story Point.

Scrum Estimation Techniques

The level of difficulty for each of the User Stories is in term of the Scrum.
Estimation and a particular scale assesses the same.
Following are the various kinds of scales that are used in Scrum Estimation.

Numeric Sizing (1 through 10)

T-shirt Sizes (XS, S, M, L, XL XXL, XXXL)
Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.)
Dog Breeds (Chihuahua,………,Great Dane)

The way the estimation technique is chosen depends upon the familiarity the entire team has with
the scale’s values. The most popular technique is Planning Poker based on Fibonacci sequence.

www.scrumversity.org
Scrumversity Page 17

Planning Poker Technique

In this technique, the estimates for the User Stories are obtained by planning poker in which the
entire Team is involved and it results in quick but reliable estimates.

A deck is used to play Planning Poker. As Fibonacci sequence is used, the cards have numbers
– 1, 2, 3, 5, 8, 13, 21, 34, etc. These numbers represent the Story Points. Each estimator has a
deck of cards and when the team members hold up a card the number on the cards should be big
enough to be visible to everybody.
One of the team members is selected as the Moderator who reads the description of the User
Story for which estimation is being made. If the estimators have any questions, Product Owner
answers them.
Each estimator privately selects a card representing his or her estimate. Until all the estimators
have made a selection, the cards are not revealed and just then all the cards are simultaneously
turned over and held up so that all team members can see each estimate.
It is very likely that the estimations vary in the first round. The high and low estimators explain the
reason for their estimates. Nothing should be taken as offense as all the discussions are for the
purpose of understanding. The moderator ensue the same.
The team can discuss the story and their estimates for few more minutes.
When the specific story is developed the moderator can take notes which he finds helpful on the
discussion. After the discussion, each estimator re-estimates by picking a card again. Once again
the cards are kept private until everyone has estimated at that point they are turned over at the
same time.
Repeat the process till the estimates congregates to a single estimate that can be used for the
story. The number of rounds of estimation may vary from one user story to another.

Benefits of Planning Poker Estimation

There are three methods combined in the Planning Poker:

Expert Opinion : In this, an expert is asked how much time something will take or how big it
is. The expert provides an estimate relying on his instinct or experience.
Expert Opinion Estimation is fast and has much more accuracy compared to the other analytical
methods.
Analogy: It uses comparison of User Stories. The User Story is weighed against the similar
User Stories implemented earlier. Therefore, the estimation is based on proven data is accurate.

www.scrumversity.org
Scrumversity Page 18

Disaggregation: A User Story is broken down into smaller, easier-to-estimate User Stories.
The User Stories to be included in a Sprint take two to five days to develop. So the User Stories
that possibly take longer need to be split into smaller Use Cases. This tactic makes sure that many
stories are comparable.

The Burn-Down Chart is used to done the sprint tracking. It shows the remaining effort in day-wise
number of hours. For example, let us consider a two week sprint:

Sprint Duration: 2 Weeks

No. of Days per Week: 5
No. of Hrs. per Day: 6
No. of Resources: 6

Hence, total remaining effort at the beginning of sprint is 2*5*6*6 = 360 hrs.

So 36 hours of work gets reduced in the remaining work and the burn-down chart looks as
follows.

350
300
250
200
150
100
50
0
06-Oct-18
07-Oct-18

08-Oct-18

09-Oct-18

10-Oct-18
11-Oct-18
12-Oct-18

13-Oct-18
14-Oct-18

15-Oct-18

16-Oct-18

17-Oct-18

The scrum progress is almost aligned to the ideal bar if the sprint work is done as planned daily.

If the sprint work gets delayed and time commitment is not met, the burn-down chart looks as
follows:

www.scrumversity.org
Scrumversity Page 19

350
300
250
200
150
100
50
0
06-Oct-18
07-Oct-18

08-Oct-18

09-Oct-18

10-Oct-18
11-Oct-18
12-Oct-18

13-Oct-18
14-Oct-18

15-Oct-18

16-Oct-18

17-Oct-18
As the burn-down chart is drawn daily and the slippage is known early rectifying actions can be
taken to meet the Sprint time line. But suppose the team expands to meet the timeline, the
burn-down chart looks as follows:

350
300
250
200
150
100
50
0
06-Oct-18
07-Oct-18

08-Oct-18

09-Oct-18

10-Oct-18
11-Oct-18
12-Oct-18

13-Oct-18
14-Oct-18

15-Oct-18

16-Oct-18

17-Oct-18

The above chart shows that at any time in Sprint the total work remaining in the Sprint can be visu-
alized and the possibility of meeting sprint timeline can be improved.

Conclusion
Burn-down charts helps the Scrum team to keep track of their advancement and what the neces-
sary criteria to achieve the sprint goal.

www.scrumversity.org