Certified Scrum Master-LeanPitch PDF

Let’s PlayScrum
Certified ScrumMaster
Workshop
You play or You don’t

Satisha K Venkataramaiah
satisha@leanpitch.com +91-9901622788 @satishakv satisha.venkataramaiah
© leanpitch Technologies Private Limited

© leanpitch Technologies Private Limited 2
Empirical Agile Scrum
Principles
Process and Values
Framework
Getting
Started with
Scrum Product
Scrum Roles Backlog
Scrum in Agile Scaling

Estimation
Action and Planning
Scrum
Empirical Process

What do we do when we are trying to
achieve a goal?
Changing Actions to achieve Goal?
Changing goals to benefit from our

actions?
We Inspect and Adapt

Speed of Iteration Beats Quality
Observe
Act Orient
Decide
http://managingmetrics.com/what-the-f-86-can-teach-us-about-software-dev
What do you think?
India vs Pakistan match

announced. Would Team
India settle on a total?
Now they also know that

its @ Mohali, India.
Would Team India settle
on a total?
What do you think?
Now they are batting

first? Would Team India
settle on a total?
They are 200/3 in 30

overs, Would they settle
on a total?

No!!!
They work as a team, look

at the current situation
and accordingly act, right?

What’s Empirical Process?
The empirical model of process
control provides and exercises control
inspection
through frequent
and adaptation for

processes that are imperfectly
defined and generate unpredictable
and unrepeatable outputs.
Why Software Development is hard?
Specifications will never be fully understood

The user will never be sure of what they want

until they see the system in production
Software evolves more rapidly as it

approaches chaotic regions

Software Development Process is
Complex
Far from agreement Requirements
Close to agreement
Certainty
Certainty
Far from
Technology
Close to
Source: Ken Schwaber (inventor of Scrum) who adapted it from Strategic Management and Organisational Dynamics, by Ralph D. Stacey
People are different and have different
capabilities
Dravid(128) and Sehwag(254): 1st Test: Pakistan v India at Lahore, Jan 13-17, 2006
Human imagination will always outpace
physics

Deming Cycle
Act Plan …is the core of Scrum
Check Do Inspect and

Adapt

Agile Principles and Values

What is Agile?
It’s a philosophy that uses
organizational models based on

Agile Manifesto
Image Source: http://udayanbanerjee.wordpress.com/category/agile

The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping
others do it. Through this work we have come to value
Individuals and interactions over Processes and tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a plan
That is, while there is value in the items on the right, we value the items on the
left more
Agile Principles :: Principle #1
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software.

What’s Value?
Value
What the customer wants the product
to do
Example:
Tell me how many license I should buy
Show me how am I utilizing my cluster
What’s Value Stream?
Value Stream
All actions required to bring project
from creation to completion
Types of actions
 Add value
 No value added, but unavoidable
 No value added, avoidable
What's waste?
Muda
Any activity that consumes resources,
but adds no value
Examples of waste
 Partially done work
 Extra processes
 Defects
8 Types of Wastes
• Navigating multiple
• Making or processing screens to input data
more than is needed
• Surgeon – Nurse
Overproduction
Unnecessary Motion
• Broken Light bulbs

• Rework
• Scratched appliances
• Entering same data
• Can’t Access the Home multiple times.
Page .
Defects • Learning Curve
Excess Processing
• Multiple applications
awaiting approval • On decisions
• Product in Warehouses. • On Systems
• Unnecessary document/data • On Equipment

storage Waiting
Excess Inventory
• Failure to use good

• Conveyance of material
ideas from anywhere
• Delivering Hard Copies
Transportation
© leanpitch Technologies Private Limited Unrealized Creativity 26
Welcome changing requirements, even
late in development. Agile processes
harness change for the customer's
competitive advantage

Yoder and Foote’s
Software Shearing Layers
Foote and Yoder’s advice for avoiding tangled,
hard-to-change software is to, “Factor
your system so that Artifacts that
change at similar rates are together.”

Agile Architecture
Base you architecture on

Requirements
Travel Light
Document just enough
Prove your architecture with

Concrete experiments 29
Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference to the
shorter timescale

Horizontal vs Vertical Architecture
Facade
Feature N
Feature 1
Feature 2
Entities
Business Process
Data Access

Database 31
Business people and developers must
work together daily throughout the
project.

Build projects around motivated
individuals. Give them the environment
and support they need, and trust them
to get the job done.

The most efficient and effective method
of conveying information to and within
a development team is face-to-face
conversation.

Working software is the primary
measure of progress.

Agile processes promote sustainable
development. The sponsors,
developers, and users should be able to
maintain a constant pace indefinitely.

Flow
Product is in motion at all time

Pull
No product is made until the customer

requests it
Requires a process that flows

Continuous attention to technical
excellence and good design enhances
agility.

Simplicity--the art of maximizing the
amount of work not done--is essential.

64% implemented features are
rarely or never used
Sometimes Rarely
16% 19%
Often
13%
Always
7%
Never
45%
Focusing on customer needs ensures:

the right features are built
not wasting effort (and resources) on
features that are not needed
Ref: Jim Johnson, Chairman of Standish Group, quoted in 2006 in:
http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS
Sample: government and commercial organizations, no vendors, suppliers or consultants
Agile Architect
Refactoring
YAGNI
Design
Spikes
Defer until last

responsible
moment
The best architectures, requirements,
and designs emerge from self-
organizing teams.

At regular intervals, the team reflects
on how to become more effective, then
tunes and adjusts its behaviour
accordingly.

Activity: Puzzle Game
Discuss on your tables how would you

play the puzzle game differently based
on what you learnt from Agile
Principles

Agile Methodologies
A G I L E
Scrum DSDM Atern

Lean Agile Unified Process (AUP)
Extreme Programming (XP)
Kanban
Lightweight Approaches Fuller Approaches (but still agile)

Why do companies adapt Agile?
Accelerate Time to Market

Manage Changing Priorities
Increase Productivity
Better Align IT/Business
Enhance Software Quality
Improve Project Visibility
Benefits Obtained from adapting Agile?
Ability to manage changing priorities

Improved project visibility
Increased Productivity
Improved team morale
Faster time to market
Better alignment between IT &
Business Objectives
Questions

Scrum Framework

What is Scrum?
A framework within which people can

address complex adaptive
problems while productively and
creatively delivering products of the
highest possible value”

Influences of Scrum
The New New

Product
Development Game
Lean
Smalltalk
Engineering
Tools
Scrum
Iterative and
Incremental
Development,
Timeboxes

The New New Product Development
Game
The New New Product Development Game

by Hirotaka Takeuchi and Ikujiro Nonaka
Built-in instability
Self-Organizing project teams
Overlapping development phases
Multilearning
Subtle Control
Organizational transfer of learning
Lean Principles
1.
Eliminate
Waste
7. See the 2. Amplify

whole Learning
6. Build
Lean 3. Delay
Integrity Committm
In ent
4.
5. Deliver
Empower
Fast
the Team

Framework doesn’t define interiors

Its an..
Empirical
Process
Transparency
Inspect
Adapt

Transparency

5 Scrum Values
Focus Commitment
Respect
Openness Courage
Scrum Framework : 3 Roles
responsible for
maximizing the value of
the product and the
work of the
Development Team
The SCRUM Team

Scrum Framework : 3 Roles
responsible for Responsible for

ensuring Scrum is converting the product
understood and backlog into releasable
enacted product increment
The SCRUM Team

Scrum Framework: 5 Events
the team meets

with the product
owner to choose a
set of work to
deliver during a
sprint
the heart of the scrum,

during which a “Done”,
useable, and potentially
releasable product
Increment is created.
the team meets each

day to synchronize
activities and plan for
the next 24 hours

the scrum team

demonstrates to the
stakeholders what it
has completed
during the sprint

the scrum team inspects

itself and create a plan for
improvements to be
enacted during next
sprint.

Timeboxing
Every event in
Scrum including the
Sprint is
Timeboxed.
This helps the team

in maintaining the
sustainable pace. 70
Scrum Framework: 3 Artifacts
An ordered list of everything that
might be needed in the product and
is the single source of requirements
for any changes to be made to the
product.

set of Product Backlog items selected for

the Sprint plus a plan for
delivering the product Increment and
realizing the Sprint Goal
required result of every

sprint. It is an
integrated version of
the product, kept at
high enough quality to
be shippable
Additional Artifacts
The Product Owner looks at the amount of work

remaining at the end of every Sprint and the
trend to assess progress toward completing
projected work by the desired time for the goal.
Release burndown or burnup can be used for this
purpose
Additional Artifacts
The Development Team compares the amount of
work remaining daily to the time they have to
project the likelihood of achieving the Sprint Goal.
Sprint burndown or burnup can be used for this
purpose

Who uses Scrum?
 Google  Lockheed Martin

 Oracle  Philips
 Salesforce.com  Siemens
 Toyota  Capital One
 BBC  Time Warner
 Nokia  Yahoo
 BMC Software
 Nielson Media 76
Questions

Getting Started with Scrum

Get everyone on the same page
Train your organization on

Scrum.
Make sure that everybody
understands the Scrum the
right way.

Split the Organization into smaller
teams
Self-Organizing
Team of Motivated Cross-functional

Individuals
Split your work into Smaller
Deliverables

Split the Release into Shorter Iterations

Get your teams together
Same building, same floor

and next to each other
Invest on high quality

video conference for
exceptional cases of
distributed teams
Change rewarding system
STOP rewarding
individual contributions
START rewarding team

contributions

Questions

Scrum Roles

3 Roles
The SCRUM Team

Product Owner [PO]
Maximize the value of the product backlog and

the work of the Development team.
Create Product’s Vision
to build a place where

people can come to
find and discover
anything they might
want to buy online.

Drive Product’s Success

Manage Product Backlog
The PO is the sole responsible person for
managing the Product Backlog.
The PO may be assisted by others to manage the backlog but PO

remains accountable.
Work with all the stakeholders
The PO decides what goes in a release

after consulting all the stakeholders.

Plan the release

Create and maintain Product
Backlog. Organize it into
incremental releases
Be available to answer
questions
Create Product Vision

Demonstrate the product to
stakeholders and evaluate the
product for release readiness
Review the work done by the team

to ensure that its done as per the
acceptance
Contribute in identifying the criteria
improvement needs and help
Define sprint goal and prioritize
team inthe
planning to enact
work for the team to ensure higher
them.
value is gained out the work done
by the team
Scrum Master is a Change Agent
Gathers support from everyone to

make sure that the change is accepted
Scrum Master is a Coach
Train, mentor and make the team speak

the same language
Scrum Master is a Protector
Protects the team from the

outside interferences
Scrum Master is a Problem Solver
Unblocks impediments so that the

team can achieve the sprint goal
Scrum Master is a Process Owner
Teach Scrum to everyone and ensure that

the right things are done the right way
Scrum Master is a Servant Leader
Lead the team to success by serving the

team to become knowledge-wealthy,
self-organizing and autonomous
Scrum Master Responsibilities
Towards the Product Owner

• Finding techniques for effective Product
Backlog Management
• Clearly communicating vision, goals, and
Product Backlog items to the Development
Team
• Teaching the Scrum Team to create clear and
concise Product Backlog items;
• Understanding long-term product planning in
an empirical environment;

Towards Development Team

• Coaching them to become self-organized
and cross-functional team
• Teaching and leading them to create high
value products
• Removing impediments to progress
• Coaching them in organizational
environments in which Scrum is not yet
fully adopted and understood.

Towards Organization
• Planning, leading and coaching the
organization in its Scrum adoption
• Helping employees and stakeholders
understand and enact Scrum and empirical
product
• Causing change that increases the
productivity of the Scrum Team
• Working with other Scrum Masters to
increase the effectiveness of the
application of Scrum in the organization
SM Responsibilities
Towards the Community

• Build the Scrum community
• Help others in the community understand
and enact Scrum.
• Maximize the Scrum awareness by reaching
outside the network where people don’t
know about Scrum.

Help PO in defining and
maintaining the product
backlog
Facilitate DSM and help

teams inspect and adapt
Understand the product

vision and lead the team to Facilitate. Ensure that the
work towards it. focus is on integrated product
increment. Help the team
inspect and adapt.
Coach team to self-organize and
help them solve impediments.
Facilitate and help team inspect and
Protect them from external
adapt the process. Ensure everyone
interferences. Lead them to achieve
is heard and appreciated. Help the
the sprint goal.
team identify the actions to enact in
the next sprint.
Facilitate the Sprint Planning
meeting. Help team work together
to create Sprint backlog. Help the
team inspect and adapt

Activity: Self Organizing Team
• Goal: Produce 200 Steps

• Rules:
• Each table is a team. One manager and rest
all workers.
• The manager can give the commands: Go,
Stop, Right, Left, Slower, Faster
• The manager needs to manage each
employee and count steps.
• The workers must follow manager’s
instructions
The Development Team
The Development Team is :
A cross-functional team
Self-organizing
Empowered and autonomous
Co-located
Collectively responsible for converting product
backlog into product increment

Development Team Size
The communication channels

increase exponentially
1 3 6 10 15
Most commonly used
development team size is 7 ± 2
Responsibilities
The Ultimate Goal

The Development Team
Self-Organize to collectively deliver

product increment every sprint
Help PO in defining and
grooming the product backlog
Update each other of the

progress and plan for next 24
hours. Inspect and Adapt
Understand the product

vision and internalize it. Demonstrate the work done
and understand both verbal
and non-verbal feedback.
Convert product backlog into

product increment. Help each other
Actively participate and
and self-organize to achieve the identify process
committed sprint goal. improvements to get better
at delivering value
Understand and commit to sprint

goal. Create sprint backlog. Create
Just enough design for the sprint
goal

Product Backlog

What is the best way to understand the
requirements?

Requirements are a communication
problem
The written requirements
 can be well thought through, reviewed and edited
 provide a permanent record
 are more easily shared with groups of people
 time consuming to produce
 may be less relevant or superseded over time
 can be easily misinterpreted

Requirements are a communication
problem
The verbal requirements
 instantaneous feedback and clarification
 information-packed exchange
 easier to clarify and gain common understanding
 more easily adapted to any new information known
at the time
 can spark ideas about problems and opportunities

A picture is worth
a thousand words

Product Backlog
An ordered and emerging list

of user needs plus anything
else that is required to fulfill
the Product Vision.
Each item in the product is called Product

Backlog Item [PBI]

A good product backlog is
Detailed enough
Emergent
Estimated
Prioritized
Product Backlog is emergent
Fine grained with details and

ready to be pulled in next sprint.
Coarse-grained requirements
The amount of detail that each PBI has depends on

its position in the product backlog.
Why is it emergent?
The product backlog starts with a

vision statement
Build a website that fulfils

every need of a traveller

The details get added over period of
time
Build a website that fulfils

every need of a traveller
Flight Hotel Taxi Travel

Booking Booking Booking Needs
Modify
Booking Cancellation Re-booking
Booking

How does the product backlog emerge?
Ideas as the working Feedback from the

software is used stakeholders and customers
Conversations Grooming Sessions

Product Backlog Item [PBI]
Each PBI is a
Frequent flyer can re-  User’s need

book the last journey  Feature description
 Planning item
 Token for conversation
 Mechanism for deferring
the conversation

What gets added to PBI’s as they
emerge?
Acceptance
Criteria Additional
Documents
Mockups
Algorithms Data points

PBI should cut across all the layers
User Interface
Presentation Logic
Feature 1
Feature 2
Feature 3
Feature 4
Business Logic
Persistence
Infrastructure
The architecture evolves secondary to the value created
by early regular releases of working software
Estimating Product Backlog
Scrum doesn’t prescribe any estimation

techniques. Instead it promotes
empiricism.

Problem with Planning & Estimates
Wishful Delay
Accumulation
Thinking Student
Syndrome
Perfectionism Planning Fallacy
Parkinson's Law
Optimism Bias
Procrastination

So what do I do about estimates?
Use whatever technique your team is

comfortable with. Scrum provides more
opportunities to inspect and adapt

What are we estimating?
How far is it?
How long does it

take?

What we estimate is
- How big are the Product Backlog
items based on the complexity,
uncertainty and the work involved.
- Not how long does it take to
implement them.

Relative Sizing
1 – Goa
3 – Tripura
12 – Punjab
6 – Kerala
40 – Orissa
50 - Karnataka

Which one is Complex?
10 piece Jigsaw Puzzle

1000 piece Jigsaw Puzzle

Which one is Complex?
Links to PM Portal, JIRA, Helpdesk,

HRIS etc.
Single Sign on to Pm Portal, JIRA,
Helpdesk, HRIS etc.

Planning Poker*
- The whole scrum team

participates but estimates
are given by the
development team
- Everyone estimates overall
size of the item (not just part
of the work)
* Planning Poker is not part of core scrum but a practice widely used by Scrum teams.
Planning Poker: Mechanics
 Create a common understanding of the User Story.
 Choose a reference card.
 Estimate size in relation to reference – but don’t tell
yet
 Show your cards at the same time
 Discuss differences
 Repeat estimation until consensus
 Estimated user story becomes new reference
Triangulation
Find three stories as reference:
smaller, larger and equal sized
1 2 3 5 8 13 20 …
A user A user A user A user A user A user A user Break the

can… can… can… can… can… can… can… stories
A user A user A user A user A user and re-
can… can… can… can… can… estimate
A user A user A user
can… can… can…
A user
can…

How is it ordered?
Its ordered based on
 Business Value
 Customer satisfaction
 Risk
 Opportunity cost
 Budget etc.

MuSCoW Prioritization(from DSDM)
Must Have: Minimum Usable SubseT
Should Have: Expected in this release
Could Have: Possibly have them in this

release
Won’t Have: Out of Scope for this
timeframe
Requirements that cannot be de-scoped without causing the project to fail
Requirements that can be de-scoped as a last resort to keep the project on track
Requirements that can be de-scoped without causing significant problems
How does the product backlog gets
groomed?
Customer Interaction with

feedback the stakeholders
The product backlog gets groomed
continuously
Grooming
Conversations Meeting
Product Backlog Grooming
- It is the act of adding detail, estimates, and
order to PBI
- On going process of collaboration between

PO and the Development Team
- It’s a part-time activity during the sprint and

how and when is decided by the Scrum Team

Product Backlog Grooming: Activities
- Enrich PBI with new details
- Split large PBIs
- Write new PBIs
- Estimate PBIs.
- Re-prioritize PBIs as needed.

Scrum in Action

Sprint
- It’s a timebox of one month or less and is a
Deming cycle
- Its an iteration in which the team produces a
shippable product increment
- There will be no change in the Sprint duration or
Sprint Goal

During the Sprint
Sprint Sprint
Goal Duration
However, the scope may be
clarified and re-negotiated
Team
Composition

All the classic SDLC activities happen
during the Sprint
Analyze and Design
Feature A Implement
Test
Feature B
..but continuously
and all the time
Feature C (not as a mini-
waterfall)
Sprint

Sprint Goal
- An objective that will be met within the Sprint
through the implementation of the Product Backlog
- It provides a guidance to the Development team on
why its building the increment
- may be a milestone in the larger purpose of the
product roadmap

When is a PBI is done?
Definition of Done[DoD]
- A shared understanding within the Scrum Team on
when a PBI is considered as “Done”.
- A checklist of valuable activities required to produce
releasable product increment.
 Fully implemented
 Tested
 All Acceptance Criteria fulfilled.
 No known issues etc.
Adverse Effects of undone work.
The technical debt

increases and pulls
down your velocity.
You will end up with

hardening sprints.

The Sprint Planning
…..Planning for the Game

Sprint Planning Overview

Sprint Planning Part I: “What”
1. The product owner presents the ordered PBIs to the
Development Team.
2. The Development team Pulls and discuss PBIs, ask
clarifying questions and understand the acceptance
criteria. Select the PBI for Sprint.
3. Continue 2 until Sprint backlog is full
4. The Scrum team crafts the sprint goal.

What details are discussed in part I?
Acceptance Demonstration
Criteria
Mockups
Algorithms, Data points

workflows
Sprint Planning Part II: “How”
Discuss how to achieve the Sprint goal and

deliver the product increment
1. Discuss the rough architecture
2. Make design decisions
3. Identify tasks the team needs to do
The team may renegotiate

the Sprint Backlog items
with Product Owner
Creating a rough design
 Identify components and interfaces
 Identify dependencies
 Identify the external integration points
 Identify Data to be used and data sources
 Discuss Architectural patterns to be applied
 Discuss Testing strategy

How team members understand user
stories and estimate

Sprint Backlog
Feature Tasks Estimate 1 2 3 4 5

Custom Create custom actions tab with 2
Actions the list of actions performed on
the job with the status
Custom Create stdout and stderr viewer 10
Actions in custom actions tab
Custom Create dynamic Input Dialog with 4
Actions input parameters configured
The Product Backlog items
with app associated with the
selected job selected for this Sprint plus
Submission Basic data model for job 3
Form submssion form the plan for delivering
Submission
Form
them
service to get application
definition [M2]
is5called the Sprint
Backlog
Sprint Burndown Chart(Based on PBI)
Sprint Burndown
60
50 50
50
40
40
32
work left
30
20
10
0
1 2 3 4 5 6 7 8 9 10
Days

Sprint Burndown Chart(based on tasks)
Sprint Burndown Chart

200
180
160
140
Work left
120
100
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10
Days
Expected Burndown Actual Burndown

Life of a Product Backlog Item in a
Sprint

The Daily Scrum
…..Planning for the Moment

Daily Scrum Meeting
Duration: 15 minutes
Attendees:
– Scrum Master (Facilitates)
– Development team
– Product Owner
Purpose:
For Development team to synchronize the activities
and create plan for next 24 hours
Inspect and adapt
Are we there yet?
 Ensure that you update the sprint
backlog and Sprint Burndown as
you want to know where you
stand before starting the DSM.
 The focus of DSM should only be “Are we

there yet?” and “What we need to get
there?”. Discuss the details of “How” outside
the DSM.

Why should we meet everyday?
Helps you focus by creating an “anticipating
culture”
Promotes “Openness” as everyone shares
information
Helps team to respect each other for their

knowledge
Reinforces commitment
Provides enough data so that you can face tough

situations
What DSM shouldn’t be?

Sprint Review Meeting
Duration: 4 Hour for One-month

Sprint
Attendees:
- Scrum Master (facilitates)
- Product Owner,
- Development team
- Stakeholders
Purpose:
Inspect the product increment and adapt the product
backlog

Sprint Review
Focus on Work done. PO identifies the

work done and what has not been
done.
Development team discusses how the

last Sprint went and demonstrate the
working product increment.
PO discusses Product Backlog as it stands

and project the likely completion dates
based on the progress to date.
Sprint Review Overview

Release Burndown Chart

The Sprint
Retrospective
…..how did we do?

Retrospectives bring out the real
problem
At the end of India tour At the end of India tour of
of England and 0-4 loss Australia and 4-0 loss
“Pitches were not helpful” “Pitches were not helpful”
At the end of England

tour of India and 1-3 loss
“God, I shouldn’t have

skipped retrospectives”
“Pitches were not helpful” 171
Sprint Retrospective Meeting
Duration: 3 hours for one month sprint
Attendees:
• Scrum Master (facilitates)
• Product Owner,
• Development team
Purpose:
 Inspect how last sprint went with regards to people,
relationship, process, and tools
 Identify and order the major items that went well and
potential improvements
 Create a plan for implementing improvements to the way
the Scrum Team does its work
Good one to have!

Retrospective Prime Directive
“Well, we gave our best. There are lots of positives

to take home. We will certainly need to work on
bowling and batting departments”
Retrospective Prime Directive
Kerth's Prime Directive:

“Regardless of what we discover, we must
understand and truly believe that everyone did
the best job he or she could, given what was
known at the time, his or her skills and abilities,
the resources available, and the situation at
hand.”

Retrospective Steps*
I. Setting the Stage

II. Gather Data
III. Generate Insights
IV. Decide What to Do
V. Close the Retrospective
*This is one of the ways of doing retrospective and its not prescribed by scrum

Setting the Stage
 Set the Agenda

 State the Purpose
 Set Focus
 Set Rules

Set the Stage
“In this session, we’ll discover where we added the

most value during our last iteration and plan for
increasing the value we add during the next
iteration”
State an affirmative goal for the

session

Focus
Focus on Focus off

Inquiry rather than Processes and tools
Dialogue rather than Debate
Conversation rather than Argument
Understanding rather than Defending

Gather Data
 Review available data: Burndown charts,

Velocity Trend etc..
 Create a common view

 Discuss what happened during last
Sprint
 Mood Timeline
 Plus/Delta
 Four Square
 Brainstorming etc.
Generate Insights
 Generate insights on what could have

caused the plus/delta
 5 whys
 Fishbone diagram
 Brainstorming + Silent Grouping

Appreciative Futurespective
 If we could time travel to the end of the next
release and converse with our future selves, we
hear that it was the most productive, most
satisfying effort we’ve ever worked on. What do
you see and hear in that future time?
 Ask: “What changes did we implement now that
resulted in such productive and satisfying work in
the future?”
 Write down all the answers / Silent Brainstorming
 [Silent] Grouping
Decide what to do
 Discuss solutions and SMART goals
 Create backlog of action items
 Prioritize the backlog based on:
 “What are we best positioned to try next?”
 “What do we really want to try (or sustain)?”
 Make sure each backlog item has volunteer

owner.

Close the Retrospective
 Summarize the results
 Agree on action items
 Appreciate the results achieved from earlier
retrospectives

Let’s Retrospect our first Sprint
 Review the first sprint with

regards to process, tools, people
and relationships.
 Identify the improvements and

action items

Agile Estimation and Planning

The Release Planning
…..Planning for the Season

Release Planning*
Product
Backlog
Just Enough
Design *Release Planning is not prescribed by Scrum. This is one
of the practices used in the community
Updated
Product
Technical Backlog
Dependencies and
Risks 188
Release Planning Steps
Estimate Product Backlog
 Go through the backlog and estimate each

item.
 Use Poker Planning or any other method
 If required split the stories

Decide the Sprint length
 The most common Sprint length is two weeks

 The automation infrastructure and how long
you need to deliver valuable software dictates
the length
 Remember that at the end of the sprint you
deliver releasable product increment
Choose the Velocity*
Velocity is how much product

backlog that the team can handle in
a Sprint.
*Velocity is not a Scrum term but used widely in Scrum
community

Velocity
Sum of story points associated with

work done in a Sprint.
Used to calculate approximate cost of
release and track release progress
Velocity doesn’t include bugs and

rejected stories.
Velocity
Velocity of two teams are not

comparable
Velocity is not productivity:
Velocity changes with team
composition.
Velocity increases with team’s tenure

Calculate the number of Sprints
Best Case : Size of Product Backlog/ Max Velocity
Worst Case : Size of Product Backlog/ Min Velocity
Most Likely Case : Size of Product Backlog/ Avg. Velocity

Fixed Scope
100
Story
points

Fixed Date

You got the release date now

Fixed Scope and Fixed Date
100
Story
points
You are expected to burn at the same rate,

which is next to impossible
Technical Debt
Technical
Debt
Planned Forecasted
Release Date Release Date

Call me @ 9901622788 any time you need help
Write to me @ satisha@leanpitch.com
You can download all the materials used in the

class from www.playscrum.com
Building leaner pitches for your efficiency games
Agile Collaboration Tool

Agile Coaching
Transformation Development
& Training
Services Services
We also offer Need a

Coach, Call
Certified ScrumMaster  Writing Effective User Stories us
 Agile Estimation and Planning
Certified Scrum Product Owner  Agile Project Management Using JIRA +
GreenHopper
Certified Scrum Developer  Collaboration Tools for Agile Teams
 Software Configuration Management for Agile
Teams using Perforce
Contact Us: www.leanpitch.com | curators@leanpitch.com | #309, 4th B Cross, HRBR Layout, III Block Bangalore-560043
+91-80-41614192

Certified Scrum Master-LeanPitch PDF

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

Certified Scrum Master-LeanPitch PDF

Uploaded by

Copyright:

Available Formats

Let’s PlayScrum

You play or You don’t

© leanpitch Technologies Private Limited

Scrum in Agile Scaling

© leanpitch Technologies Private Limited 4

Changing goals to benefit from our

We Inspect and Adapt

India vs Pakistan match

Now they also know that

Now they are batting

They are 200/3 in 30

© leanpitch Technologies Private Limited

They work as a team, look

© leanpitch Technologies Private Limited

and adaptation for

Specifications will never be fully understood

© leanpitch Technologies Private Limited

The user will never be sure of what they want

Software evolves more rapidly as it

© leanpitch Technologies Private Limited 13

Far from agreement Requirements

© leanpitch Technologies Private Limited 16

Act Plan …is the core of Scrum

Check Do Inspect and

© leanpitch Technologies Private Limited 17

© leanpitch Technologies Private Limited 18

© leanpitch Technologies Private Limited 19

Image Source: http://udayanbanerjee.wordpress.com/category/agile

Individuals and interactions over Processes and tools

Working Software over Comprehensive Documentation

Customer Collaboration over Contract Negotiation

Responding to Change over Following a plan

© leanpitch Technologies Private Limited 22

• Broken Light bulbs

• Product in Warehouses. • On Systems

• Unnecessary document/data • On Equipment

• Failure to use good

© leanpitch Technologies Private Limited 27

© leanpitch Technologies Private Limited 28

Base you architecture on

Prove your architecture with

© leanpitch Technologies Private Limited 30

© leanpitch Technologies Private Limited

© leanpitch Technologies Private Limited 32

© leanpitch Technologies Private Limited 33

© leanpitch Technologies Private Limited 34

© leanpitch Technologies Private Limited 36

© leanpitch Technologies Private Limited 37

Product is in motion at all time

© leanpitch Technologies Private Limited 38

No product is made until the customer

Requires a process that flows

© leanpitch Technologies Private Limited

© leanpitch Technologies Private Limited 40

© leanpitch Technologies Private Limited 41

Focusing on customer needs ensures:

Defer until last

© leanpitch Technologies Private Limited 44

© leanpitch Technologies Private Limited 45

Discuss on your tables how would you

© leanpitch Technologies Private Limited 47

Scrum DSDM Atern

© leanpitch Technologies Private Limited