Scrum

Master(CSM,PSM
)
Ajay Kumar Kataram
 WHAT IS AGILE?

MORE Powerful MINDSET

LESS Visible

VALUES

PRINCIPLES

PRACTICES (Like Scrum)

TOOLS
(Like JIRA)

MORE Visible
LESS Powerful
Agile
History
 Agile
Manifesto
Agile Manifesto
Cross Functional Teams
Agile Manifesto
Agile
Manifesto
•Individuals and interactions
over processes and tools v1
Working software over
comprehensive documentation
v2
Customer collaboration over
contract negotiation v3
Responding to change over
following a plan v4
AAgAgile Manifesto 12
 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.p1
 Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.p2
 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.p3
 Businesspeople and developers must work together daily throughout the project.p4
 Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.p5
 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.p6
 Working software is the primary measure of progress.p7
 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace
indefinitely.p8
 Continuous attention to technical excellence and good design enhances agility.p9
 Simplicity--the art of maximizing the amount of work not done--is essential.p10
 The best architectures, requirements, and designs emerge from self-organizing teams.p11
 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.p12
 Agile
Manifesto
Scrum
Master
Challenge
s
 Scrum
Master
Hand over
Guide
Sprint Review
1. Attendees include the Scrum Team and key stakeholders
invited by the Product Owner;
2. Members of the Scrum Team explain what Product Backlog
items have been “Done” and what has not been “Done”;
3. The Developers discuss what went well during the Sprint,
what problems it ran into, and how those problems were
solved;
4. The Developers demonstrate the work that it has “Done”
and answers questions about the Increment;
5. The Product Owner discusses the Product Backlog as it
stands. He or she projects likely target and delivery dates
based on progress to date (if needed);
6. The entire group collaborates on what to do next, so that
the Sprint Review provides valuable input to subsequent
Sprint Planning;
7. Review of how the marketplace or potential use of the
product might have changed what is the most valuable
thing to do next; and,
8. Review of the timeline, budget, potential capabilities, and
marketplace for the next anticipated releases of
functionality and capability of the product.
Daily Stand Up
Sprint Retrospective
1. The Sprint Retrospective concludes the Sprint. It is
timeboxed to a maximum of three hours for a one-
month Sprint. For shorter Sprints, the event is
usually shorter.
2. During the Sprint Retrospective, the team
discusses:
 What went well in the Sprint
 What could be improved
 What will we commit to improve in the next
Sprint ?
 Set a clear goal
 Create a safe and positive environment
 Use a structured format-Start-Stop-Continue model
 Generate and prioritize actions-measurable,
achievable, relevant, and time-bound (SMART)-
assign owners and deadlines for each action
 Celebrate and close-team celebrates their
achievements and recognizes their efforts
Responsibilities
10 Best Kanban Tools
Scrum Master Activities
Scrum Master Summary
 The basic sizes used in T-shirt sizing are:
 Extra Small (XS): Very small and straightforward tasks, requiring minimal effort.
 Small (S): Relatively small tasks, with moderate complexity.
 Medium (M): Tasks of average size and complexity.
 Large (L): Larger tasks, requiring more effort and potentially involving multiple components.
 Extra Large (XL): Very large and complex tasks, likely requiring significant resources and coordination.
 How T-shirt sizing works:
 Story Identification: Identify the user stories or tasks that need to be estimated.
 Size Categorization: As a team, discuss and categorize each story into one of the T-shirt sizes based on factors like complexity, dependencies, and uncertainty.
 Consensus Building: Facilitate a discussion to ensure that the team reaches a consensus on the size of each story.
 Refinement: If necessary, revisit and refine the estimates as more information becomes available or the project evolves.
 Advantages of T-shirt sizing:
 Simplicity: Easy to understand and apply, even for teams with limited experience in Agile estimation.
 Speed: Provides quick and efficient estimates, especially when detailed information is limited.
 Relativity: Focuses on relative effort rather than absolute time estimates, which can be more accurate in Agile environments.
 Flexibility: Can be adapted to different project contexts and team preferences.
 Limitations of T-shirt sizing:
 Subjectivity: Estimates can vary depending on the team's experience and perception of complexity.
 Lack of Precision: May not provide highly accurate estimates for very large or complex projects.
 Limited Granularity: May not capture nuances in effort or complexity.
 While T-shirt sizing may not be suitable for all projects or teams, it can be a valuable tool for providing initial estimates, fa cilitating discussions, and supporting Agile planning and
execution.
Sprint Planning -Topics
 Sprint Planning
Sprint Planning is the “Scrum Team” collaborates to Dev team can invite any SMEs to Maximum 8 Hours
first event in the Sprint understand the work of Sprint support them in Sprint Planning for a 1 Month Sprint

INPUTS APPROACH OUTPUTS

WHAT?
Team’s Past Performance
SPRINT
GOAL

Projected Capacity of Dev Team

HOW?
Latest
Product
Increment
SPRINT BACKLOG
Sprint Planning -following topics:

Why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then
collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the
end of Sprint Planning.
What can be Done this Sprint?
• Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The
Scrum Team may refine these items during this process, which increases understanding and confidence.Selecting how much can be
completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming
capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
How will the chosen work get done?
• For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done.
This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole
discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.The Sprint Goal, the
Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
• Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter
Sprint Planning -following topics:

INPUTS TO SPRINT PLANNING

 Sprint planning relies on a set of inputs that guide the development team in determining what value it can realistically deliver during the
sprint. These sprint planning inputs are as follows:
 Product Backlog. The highest priority PBIs should already be groomed, which typically means the PBIs have acceptance criteria, and have
been sized appropriately, estimated, and prioritized.
 Team Velocity. The team's historical velocity is one indicator of how much work is practical for the team to complete in a single sprint.
 Constraints. The team should have identified any business or technical constraints that could materially affect what the team's can deliver.
 Team Capabilities. The team should know which team members are available (and what their availability is) for this particular sprint, as well
as which skills each team member has.
 Initial Sprint Goal. The product owner should have identified the business objective he/she ideally would like to see accomplished during the
sprint.
OUTPUTS OF SPRINT PLANNING
 At the end of sprint planning, the development team communicates its commitment through the two sprint planning outputs: a finalized
sprint goal and a sprint backlog.
Scrum
Scrum
Devops CI CD (Project set up using
Jenkins)
Project on Devops ci-cd pipeline using Jenkins
 Step 1 → Setup Terraform and configure aws on your local machine
 Step 2 → Building a simple Infrastructure from code using terraform
 Step 3 → Setup Sonarqube and jenkins
 Step 4 → ci-cd pipeline to build and push the image to docker hub
 Step 5 → Update Image name In deployment repo
 Step 6 → EKS cluster creation
 Step 7 → Install Argo cd
 Step 8 → Deploy Application with ArgoCD
 Step 9 →Destruction
 project blog link ----> https://lnkd.in/gWjrH7ya
X Axis – shows Dates of all the sprints.

Y Axis – shows all the Estimation Points of the

selected sprint.

There are four defined areas shown in the

cumulative chart:

1. To Do (Blue area): All user stories that are

available in To Do status within a sprint.

2. In Progress (Orange area): All user stories

that are available within In progress status in
a sprint.

3. Completed (Green area): All user stories

that are available in Completed status within
a sprint.

4. Accepted (Teal area): All user stories that

are available in Accepted status within a
sprint.
Burndown Chart vs. Cumulative Flow Diagram (CFD)
Burndown Chart vs. Cumulative Flow Diagram (CFD)
Burndown Chart vs. Cumulative Flow Diagram (CFD)
Scrum V/S XP
Scrum XP

Focuses on management of work Focuses on programming and technology

Product Owner Onsite Customer

Scrum Master Coach

Sprint Iteration

Daily Scrum Daily Stand up

Does not insist engineering practices Engineering practices are a must

Typically 2 to 4 weeks Sprints Typically 1 to 2 week Iterations

Release planning is optional Release planning is must

Does not allow changes to Sprint backlog items Allows changes to the items that are not started

Not particular about order of execution in Sprint XP teams must work in same order of priority
Scrum Master
Scrum Master
 Agile
Developm
ent
Scrum/Kanban
Agile v/s
waterfall
Scrum Life
cycle
 PLAN OR VALUE?
Fixed

SCOPE

PLAN
Estimated Driven Estimated

1m 3m 5m 2m 1m TIME COST

ADC T U Fixed
VALUE Fixed
Driven

STOP SCOPE

Estimated 20% of FEATURES

Deliver
1 MONTH 80% of VALUE
 PROCESS CONTROLS

EMPIRICAL
PROCESS
DEFINED PROCESS
T
R I A
A N D
P S
N S
P
A
P
L A
P E
C
T
A
A E
R T
I
T
I
N
N C
O
N
O
N
Y

Make a coffee from a Make “THE BESTEVER”

vending machine coffee in the world
SIMPLE STATIC COMPLEX ADAPTIVE
PREDICTABLE UNPREDICTABLE
 Scrum Overview
RULES

5
Roles Artifacts Enhance
TRANSPARENCY

3 3
W
Events PRODUCT BACKLOG O
R
SPRINT BACKLOG K
PRODUCT INCREMENT VALUE
• SPRINT (Not More than 1 Month)
Scrum Team • Sprint Planning Helps create
• Daily Scrum Regularity and to
Inspect & Adapt
• Sprint Review
• Sprint Retrospective
 Scrum Values

High Performance
Teams

Inspection
o n
Tran tati
a p
spar Ad
ency
T
R
U
S
T

F O R C C
 Scrum Framework Flow
STAKEHOLDERS
OWNS
Product
Vision
Needs, Wants & Desires

Spr
ri nt tive Rev int
Sp pec iew
t ros
Re
SPRINT

T
PULL Not More than 1 Month

N
PBR
• ITERATIVE

E
Sprint • INCREMENTAL
Planning

P M
• TIMEBOXED
• PROTECTED Daily
Scrum
D
E V E L

O
NEXT SPRINT
 Product Backlog
Product Backlog Characteristics

O Ordered

P Progressively Elaborated
H F Features
H L I T Transparent
I O G R Requirements
G W H I Includes ‘FRIEND’s
H I Infrastructural
C V M Managed by Product Owner
R O A E Enhancements
I S
S T
L
N Non-functional I Incomplete
U
K
E
D Defects S Single source of REQs

E Estimated
D O V E
Desc Order Value Estimate
D Dynamic
 Product Backlog Refinement (PBR)

Continuous PLANNING through Product Backlog Refinement

EXECUTION through Iterative and Incremental (Sprints)

Initial PBR
 When to have Product Backlog Refinement?

Daily Daily Daily Daily

SPRINT Scrum Scrum Scrum Scrum

PLANNING
PBR
Here?
PBR
Daily Daily Daily Daily Daily
Scrum Scrum Scrum Scrum Scrum

PBR SPRINT
Here? REVIEW
SPRINT
RETRO

HOW, WHEN and DURATION of PBR

Will be Decided by the Scrum Team
 Sprint Planning
SPRINT BACKLOG
Product Backlog TO - DO DOING DONE
Add items to
Analysis 4 Test cases 3 UI 4 JS 3
cart Java code 8 DB coding 3 Code Rev 3
Change Qty

Modigy Billing
address
Modify
shipping
address
Pay through G
Pay
Pay through
PayTm
Pay through
VISA Card

My Orders

Cancel Orders

Wishlist

Refer a friend