A scrum is a way to restart

the game after an

interruption, where the
forwards of each side come
together in a tight formation
and struggle to gain
possession of the ball when it
is tossed in among them.
Scrum is one of the most popular Agile frameworks. It is an adaptive, iterative, fast,
flexible, and effective project delivery system designed to deliver significant value
quickly and throughout a project.

SCRUM
OVERVIEW OF SCRUM
  Adaptability
 Transparency
 Continuous Feedback
 Continuous Improvement
 Continuous Delivery of Value
 Sustainable Pace
 Early Delivery of High Value
 Efficient Development Process
 Motivation
 Faster Problem Resolution
 Effective Deliverables
 Customer Centric
 High Trust Environment
BENEFITS OF SCRUM Collective Ownership
 High Velocity
 Innovative Environment
FRAMEWORK OF SCRUM

Roles
•Product owner
•Scrum Master
•Team
Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts

•Product backlog
•Sprint backlog
•Burndown charts
 Scrum prescribes making decisions based on observation and experimentation
rather than detailed upfront planning.

 This principle emphasizes the core philosophy of Scrum based on the three main
ideas
 Transparency
 Inspection
 Adaptation

EMPIRICAL PROCESSES CONTROL

EMPIRICAL PROCESSES CONTROL
EMPIRICAL PROCESSES CONTROL
EMPIRICAL PROCESSES CONTROL
VALUE BASED PRIORITIZATION
 Prioritizing can be defined as determining the order and separating what must be done now, from
what needs to be done later.
 Scrum uses Value-based Prioritization as one of the core principles that drives the structure and
functionality of the entire Scrum framework
 Scrum aims at delivering a valuable product or service to the customer on an early and continuous
basis.
 While prioritizing, following three factors are considered:

 Thus, prioritization results in deliverables that satisfies the requirements of the customer with the
objective of delivering the maximum business value in the least amount of time.
  Scrum treats time as one of the most important
constraints in managing a project. To address the
constraint of time, Scrum introduces a concept called
'Time-boxing' which proposes fixing a certain amount
of time for each process and activity in a Scrum
project.
 This ensures that Scrum Team members do not take
up too much or too little work for a particular period
of time and do not expend their time and energy on
work for which they have little clarity.
 Some of the benefits of Time-boxing are:
 Efficient development process

TIME-BOXING  Less overheads

 High velocity for teams
TIME-BOX DURATION
ITERATIVE  The Scrum framework is driven by the goal of delivering maximum business value in the
least time. To achieve this practically, Scrum believes in Iterative Development of
DEVELOPMENT Deliverables.
 Each complex aspect of the project is broken down through progressive elaboration during
the Groom Prioritized Product Backlog process.
 The Create User Stories and the Estimate, Approve, and Commit User Stories processes are
used to add new requirements to the Prioritized Product Backlog. The Product Owner’s task
is to ensure increased ROI by focusing on value and its continuous delivery with each Sprint.
 The Product Owner should have a very good understanding of the project’s business
justification and the value the project is supposed to deliver as he drafts the Prioritized
Product Backlog and thereby decides what deliverables and hence values are delivered in
each Sprint. Then the Create Tasks, Estimate Tasks, and Create Sprint Backlog processes
produce the Sprint Backlog which the team uses to create the deliverables.
 Some of the benefits of Iterative Development are:
 It allows for course correction as all the people involved get better understanding of
what needs to be delivered as part of the project and incorporate these learning in an
iterative manner.
 The time and effort required to reach the final end point is greatly reduced and the team
produces deliverables that are better suited to the final business environment.
  Organization
 Core Roles
 Product Owner
 Scrum Master
 Scrum Team
 Non-core Roles
 Stakeholder(s)
 Scrum Guidance Body
 Vendors
 Chief Product Owner
 Chief Scrum Master
 Business Justification
 Quality
 Change
 Risk

SCRUM ASPECTS
SCRUM ORGANIZATION STRUCTURE
STEPS TO DETERMINE BUSINESS JUSTIFICATION
  In Scrum, quality is defined as the ability of the completed product or deliverables
to meet the Acceptance Criteria and achieve the business value expected by the
customer.
 To ensure a project meets quality requirements, Scrum adopts an approach of
continuous improvement whereby the team learns from experience and
stakeholder engagement to constantly keep the Prioritized Product Backlog
updated with any changes in requirements.
 The Prioritized Product Backlog is simply never complete until the closure or
termination of the project. Any changes to the requirements reflect changes in the
internal and external business environment and allow the team to continually work
and adapt to achieve those requirements.
 Since Scrum requires work to be completed in increments during Sprints, this
means that errors or defects get noticed earlier through repetitive quality testing,
rather than when the final product or service is near completion.
 Moreover, important quality-related tasks (e.g., development, testing, and
documentation) are completed as part of the same Sprint by the same team-this
ensures that quality is inherent in any deliverable created as part of a Sprint. Such
QUALITY deliverables from Scrum projects, which are potentially shippable, are referred to
as 'Done.'
 Thus, continuous improvement with repetitive testing optimizes the probability of
achieving the expected quality levels in a Scrum project.
  Every project, regardless of its method or framework used, is exposed to
change. It is imperative that project team members understand that the Scrum
development processes are designed to embrace change. Organizations
should try to maximize the benefits that arise from change and minimize any
negative impacts through diligent change management processes in
accordance with the principles of Scrum.
 A primary principle of Scrum is its acknowledgement that a) stakeholders
(e.g., customers, users, and sponsors) change their minds about what they
want and need throughout a project (sometimes referred to as 'requirements
churn') and b) that it is very difficult, if not impossible, for stakeholders to
define all requirements during project initiation.
 Scrum projects welcome change by using short, iterative Sprints that
incorporate customer feedback on each Sprint's deliverables. This enables the
customer to regularly interact with the Scrum Team members, view
CHANGE deliverables as they are ready, and change requirements if needed earlier in
the Sprint.
 Also, the portfolio or program management teams can respond to Change
Requests pertaining to Scrum projects applicable at their level.
SAMPLE CHANGE APPROVAL PROCESS
  Risk is defined as an uncertain event or set of events that can affect the objectives
of a project and may contribute to its success or failure.
 Risks that are likely to have a positive impact on the project are referred to as
opportunities, whereas threats are risks that could affect the project in a negative
manner. Managing risk must be done proactively, and it is an iterative process that
should begin at project initiation and continue throughout the project's lifecycle.
 The process of managing risks should follow some standardized steps to ensure
that risks are identified, evaluated, and a proper course of action is determined and
acted upon accordingly.
 Risks should be identified, assessed, and responded to based on two factors: the
probability of each risk's occurrence and the possible impact in the event of such
occurrence.
 Risks with a high probability and impact value (determined by multiplying both
RISK 
factors), should be addressed before those with a relatively lower value.
In general, once a risk is identified, it is important to understand the risk with
regard to the probable causes and the potential effects if the risk occurs.
  Initiate Phase
1. Create Project Vision
2. Identify Scrum Master and Stakeholder(s)
3. Form Scrum Team
4. Develop Epics
5. Create Prioritized Product Backlog
6. Conduct Release Planning
 Plan and Estimate Phase
7. Create User Stories
8. Approve, Estimate and Commit User Stories
9. Create Tasks
SCRUM PROCESSES
10. Estimate Tasks
11. Create Sprint Backlog
  Implement Phase
12. Create Deliverables
13. Conduct Daily Standup
14. Groom Prioritized Product Backlog
 Review and Retrospect Phase
15. Convene Scrum of Scrums
16. Demonstrate and Validate Sprint
17. Retrospect Sprint
 Release Phase
18. Ship Deliverables
SCRUM PROCESSES 19. Retrospect Project
 Process Activity
Create Project Vision Review the Project Business Case and create a
Project Vision Statement.
Identify Scrum Master and Use Selection Criteria to identify Scrum Master
Stakeholder(s) and Stakeholders.
Form Scrum Team Identify Scrum Team members.
Develop Epics Use Project Vision Statements to develop Epics.

Create Prioritized Product Refine and Elaborate Epics into User Stories and
Backlog prioritize in PPB. Add NFR’s to PPB. Establish
Done Criteria.

User Story Estimation Planning Poker

Conduct Release Planning Review User Stories in PPB and develop a Release
Planning Schedule. Determine Sprint Length.

INITIATE PHASE
  The Plan and Estimate phase consists of processes related to
planning and estimating tasks, which include Create User
Stories; Approve, Estimate, and Commit User Stories;
Create Tasks; Estimate Tasks; and Create Sprint Backlog.
 As part of this phase, the Scrum Core team creates,
approves, estimates, and commits User Stories, creates and
estimates tasks, and creates the Sprint Backlog.

PLAN & ESTIMATE PHASE

 Process Activity
Create User Stories Create User Stories and their related User Story Acceptance Criteria.

Approve, Estimate and Commit User Product Owner approves User Stories for a Sprint. Scrum Master and
Stories Scrum Team estimate the effort for each user story and commit to
deliver them.
Create Tasks User Stories are broken down into specific tasks into a Task List in a
Task Planning Meeting.
Estimate Tasks Scrum Core Team estimates the tasks in Task Estimation Meetings to
create an Effort Estimated Task List.
Create Sprint Backlog Scrum Core Team holds Sprint Planning Meetings to create a Sprint
Backlog listing all tasks to be completed in the Sprint.

PLAN & ESTIMATE PHASE

 The Implement phase includes the execution of the tasks
and activities to create a project’s product.

Process Activity
Create Deliverables Scrum Board and Impediment Log are used to
track work being done and issues faced.

Conduct Daily Standup 15 minute Daily Standup Meetings are held to

track progress and discuss typical impediments
faced. Discuss Communication challenges of
distributed teams.

Groom Prioritized Product PPB Review Meetings are held to groom the PPB.
Backlog

IMPLEMENT PHASE
  The Review and Retrospect phase is concerned with reviewing the
deliverables and the work that has been done and determining
ways to improve the practices and methods used to do project
work.
 In large organizations, the processes in the Review and Retrospect
phase may also include the Scrum of Scrums.

REVIEW & RETROSPECT PHASE

REVIEW & RETROSPECT PHASE
Process Activity
Convene Scrum of Scrums Scrum Team Representatives Convene Scrum of
Scrums Meetings to track progress, impediments
and dependencies across multiple Scrum Teams in
a large project.

Demonstrate and Validate Scrum Team demonstrates the Sprint Deliverables

Sprint to the Product Owner in a Sprint Review Meeting.
The PO may accept or reject the User Stories
demonstrated based on each USAC.

Retrospect Sprint Scrum Master and Scrum Team discuss the lessons
learned in the Sprint. This may result in Agreed
Actionable Improvements and Updated Scrum
Guidance Body Recommendations.
  The Release phase emphasizes delivering the Accepted Deliverables
to the customer.
 It also involves in identifying, documenting, and internalizing the
lessons learned during the project.

RELEASE PHASE
 Process Activity
Ship Deliverables Accepted Deliverables are delivered or transitioned
to the relevant Stakeholders. A formal Working
Deliverable Agreement documents successful
completion of the Sprint.

Retrospect Project Stakeholders and SCT members assemble to

internalize the lessons learned. Agreed Actionable
Improvements form this may be used on future
projects.

Metrics & Documentation Team to display metrics collected and the

documentation for the Project.

RELEASE PHASE
 • Product Owner prioritizes features
• Identifies key external milestones and business commitments
• Resource capacity plan is developed for the project
• Each backlog item is estimated
• High-level estimates (+/- 50% accuracy)
• Team selects items from the product backlog they can commit to
completing
• Effort is compared to resource capacity and an initial burndown is
projected

SPRINT PLANNING MEETING

  This is a well-established technique popularized by
Mike Cohn, and variations on his Planning Poker
cards can be found in offices across the world.
 A typical Planning Poker set has cards with the
following numbers: ½ 1 2 3 5 8 13 20 40 100. Nerds
will observe and be irritated by the fact that this is
roughly (but not quite) in line with the Fibonacci
sequence.
 It is like a game that team members can play during
planning meetings to make sure that everybody
participates and that every voice is heard.
 Through this process, everybody on the team learns
more about what’s involved in estimating stories both
inside and outside of their specialties, increasing
knowledge sharing across the entire team.

PLANNING POKER
  The Planning Poker is a consensus based technique and is
used to size the stories (in terms of story point) or effort
estimate (in terms of days).
 It is a non-liner scale of estimation technique.
 Fibonacci series is used while playing the planning poker
with higher numbers rounded off (0, 0.5, 1, 2, 3, 5, 8, 13,
20, 40, 60, and 100).
 For example: You have been asked to provide your
estimate for a Story, your estimates have to be rounded
off to one of the number of the Fibonacci series.
 If you feel the task will take 10 days to complete, the
estimate you give will have to be either 8 or 13.

PLANNING POKER
  Each team member takes a deck of cards and estimates the
effort independently for each story.
 The stories are wall mapped and arranged relatively with respect to
small story which can be coded and tested in a day – taken as a
reference.
 All the stories are arranged relatively with respect to small story
from left to right.
 The parameters on which the stories are estimated are complexity,
ideal time taken (in days) and uncertainty.
 It is always a good idea to break the bigger stories into small ones
to make them fit into a Sprint. 
 With Planning Poker, the numbers are significant.
 A story estimated as a 2 should be about one fourth as difficult as a
story estimated as an 8.
 Stories estimated at 20 or higher may be so large that they need to
be broken up into smaller stories before they can be attempted.
 Stories estimated at 0 may not even be worth tracking.

PLANNING POKER
  An identical hand of cards is given to each team member.
Each team member will have a set of cards with numbers as
pseudo-Fibonacci (1, 2, 3, 5, 8, 13, 21…).
 The Product Owner describes the piece of work to be
estimated in detail. Normally this is a user story with
acceptance criteria.
 Team discusses the work involved and asks questions to the
Product Owner
 Each team member mentally estimates the size of it on the
scale. They can ask the Product Owner questions to clarify
any points, but for the moment they will keep their estimate
to themselves.
 Each team member selects a poker card that reflects their
estimate of the effort required for that story and places the
card that corresponds to their mental estimate face down in
front of them.

How to play Poker Planning

  At the facilitator’s instruction - usually the Scrum Master
- the team turn their cards over.
 Everyone estimates individually without getting
influenced by others.
 Everyone reveals their estimates simultaneously.
 In an ideal case the cards will all have the same value,
suggesting that the team have a common understanding of
the requirements and the likely effort that will be
involved.
 Team members who voted with the lowest and highest
estimates explain their reasoning behind their estimation
and any misunderstanding of scope is neutralized.
 They need to understand each other’s thinking, and from
that reach a consensus. It may be necessary to replay the
cards several times before agreement is reached.

HOW TO PLAY POKER PLANNING

  After discussion, the team members reselect the
cards to reflect their estimates based current
discussion.
 Take the agreement of final number as the team
estimate.
 Repeat the process for all the stories in the Sprint
backlog.
 By convention, estimates are written on the corner of
a User Story card before being placed on a Scrum
board.

HOW TO PLAY POKER PLANNING

 • Parameters
• Daily
• Max. 15-minutes
• Not for problem solving
• Only team members, Scrum Master, product
owner, can talk
• Helps avoid other unnecessary meetings

DAILY STANDUP
EVERYONE ANSWERS 3 QUESTIONS

1.What did you do yesterday?

2.What will you do today?

3.Any impediments?
  Team presents what it accomplished during
the sprint
 Typically takes the form of a demo of new
features or underlying architecture
 Chicken & pigs are invited
 Pigs, who are totally committed to the
project and accountable for its outcome.
Example Product Owner, the Scrum
Master and Development Team.
 Chickens, who consult on the project and
are informed of its progress. Example
customers and executive management.

SPRINT REVIEW
  Typically 15–30 minutes
 Done after every sprint
 Whole team participates
 Scrum Master
 Product owner
 Team
 Discuss on what went well and what did not go well and
action items for the same.

SPRINT RETROSPECTIVE
  The Backlog Refinement Meeting lacks an
official name and has also been called “Backlog
Grooming,” “Backlog Maintenance,” or “Story
Time.”
 In the Backlog Refinement Meeting, the team
estimates the amount of effort they would
expend to complete items in the Product
Backlog and provides other technical
information to help the Product Owner prioritize
them.
 A skilled ScrumMaster can help the team
identify thin vertical slices of work that still
have business value.

GROOMING MEETING
  PBI represents a customer-centric feature, usually
requiring several tasks to achieve definition of done
 Often written in User Story form
 Has a product-wide definition of done to prevent
technical debt
 May have item-specific acceptance criteria
 Effort is estimated by the team, ideally in relative
units (e.g., story points). Effort is roughly 2-3 people
2-3 days, or smaller for advanced teams.
 Ideally expressed such that each item has value to the
users or customers of the product
 Prioritized by the product owner
 Reprioritized at the start of each sprint

PRODUCT BACKLOG ITEM - PBI

  A subset of Product Backlog Items, which define the
work for a Sprint
 Consists of committed PBIs negotiated between the team
and the Product Owner during the Sprint Planning
Meeting
 Visible to the team
 Referenced during the Daily Scrum Standup Meeting
 Each Item has it’s own status
 Should be updated every day
 Is created ONLY by Team members
 If a task requires more than 16 hours, it should be broken
down
 Sprint Backlog is often represented with an “information
radiator” such as a physical task board.

SPRINT BACKLOG
PB VS RB VS SB
SCRUM BOARD
 The sprint burn down chart is a publicly displayed chart showing remaining
work in the sprint backlog. Updated every day, it gives a simple view of the
sprint progress. It also provides quick visualizations for reference.

A SPRINT BURN DOWN CHART

 • A User Story is a brief statement of intent that describes
something the system needs to do for the user.

• User stories are sketched out by Product Owner.

• A user story is a very high-level definition of a

requirement, containing just enough information so that
the developers can produce a reasonable estimate of the
effort to implement it.

USER STORIES
SAMPLES FROM A TRAVEL WEBSITE

As a [user role] I want to [goal] so I can [reason]

 As a user I want to cancel a room reservation.

 As a user I want to reserve a hotel room.
 As a frequent flyer, I want to rebook a past trip, so that I can save time
booking trips I take.
 As a customer, I want to be able to create an account so that I can see
the purchases I made in the last year to help me budget for next year.
  Epics are large user stories, typically ones which are too
big to implement in a single iteration and therefore they
need to be disaggregated into smaller user stories at some
point.
 It is essentially a large user story that can be broken
down into a number of smaller stories.
 It may take several sprints to complete an epic. 
 If you write a user story that has a singular goal, and that
goal takes an extended time to realize, then the user story
is an Epic. For example, if you write a user story around
increasing awareness of certain brand attributes, you’re
not likely to accomplish this in 2-4 weeks.

EPICS
EPIC VS USER STORY EXAMPLE 1
EPIC VS USER STORY EXAMPLE 2
  Acceptance criteria complement the story’s
narrative.
 They allow you to describe the conditions that
have to be fulfilled so that the story is done.
 The criteria enrich the story and make it more
precise and testable, and they ensures that the
story can be demoed or released to the users
and the other stakeholders.
 As you decompose epics into smaller stories,
remember to add acceptance criteria.
 As a rule of thumb, use three to five criteria
for detailed stories.

ACCEPTANCE CRITERIA
  The Given/When/Then format is helpful way to
specify acceptance criteria:
Given some precondition When I do some
action Then I expect some result
 When we write acceptance criteria in this
format, it not only provides a consistent
structure, but we are also helping testers
determine when to begin and end testing for that
specific work item.

ACCEPTANCE CRITERIA FORMATS

  The team agrees on, and displays
prominently somewhere in the team room,
a list of criteria which must be met before
a product increment "often a user story" is
considered "done".
 Failure to meet these criteria at the end of
a sprint normally implies that the work
should not be counted toward that sprint's
velocity.
 We define two aspects of the Definition of
Done – Completion Criteria and
Acceptance Criteria.
DEFINITION OF DONE
DONE CRITERIA
ACCEPTANCE CRITERIA VS DOD

 For a user story or feature to be “potentially shippable” it needs to meet

the expectations of the Product Owner and be of the agreed quality.
 The Product Owner’s expectations are phrased as acceptance test criteria.
Acceptance test criteria are conditions of satisfaction specific for each
individual user story.
 The user story’s (internal) quality is defined in the “Done” statement. The
“Done” statement is applicable to all user stories in the project.
 The “Definition of Done”(DoD) is the team/project’s quality statement
for a user story or feature and ensures that a feature is 100% developed
and tested. It is a statement that no more work is left to be done on this
piece of functionality (90% done doesn’t count!) and that it works
without errors.
 What do we consider an impediment?
Anything  that holds the PBI work from moving forward

When do we log impediments?

If something doesn’t get addressed within 24 hours (Experimental and team
agreement)

Why do we even need to log them?

To see what /who is slowing us down and the fix those issues

IMPEDIMENT?
 1. Bad build deployed
2. Env not ready
3. Waiting on build
4. Waiting on code review
5. Waiting on IT
6. Waiting on PO
7. Bugs introduced by other teams
8. Waiting on design questions
9. Waiting on DB Review
WHAT KIND OF IMPEDIMENTS
CAN WE LOG?
AGILE VS TRADITIONAL METHODS
Approach Agile Waterfall
Emphasis People Process
Domain Unpredictable/Exploratory Predictable
Documentation Minimal-only as required Comprehensive
Quality assurance Customer centric Process centric
Process style Iterative Linear
Organization Self-organized Managed
Upfront Planning Low High
Perspective toward change Adaptability Sustainability
Prioritization of requirements Based on business value and Fixed in the project plan
regularly updated
Management Style Decentralized Autocratic
Leadership Collaborative, Servant Command and control
Leadership
Performance Measurement Business value Plan conformity
Returns on Investment Early/throughout project life End of project life