Professional_Scrum_Master - Notes.

xlsx

Key Description Notes

 Framework for developing, delivering, sustaining complex products
 Framework within which to address problems, deliver products of the highest possible value
k  Process framework used to manage work on complex products
or
Fr rum
ew

Scrum is NOT a process, technique or definitive method but is a framework within which we can employ
am
Sc


processes and techniques
 Scrum Framework consists of Scrum Teams, their roles, events, artifacts and rules
 Lightweight + Simple to understand + Difficult to master
Scrum is free
Scrum rules, events, artifacts, rules are immutable
Scrum

Implementing parts of Scrum is possible but result is NOT Scrum

Scrum exists in its entirety and is a container for other techniques, methodologies and practices
 Developed by Ken Schwaber & Jeff Sutherland, until 1995
Products, product capabilities, viable
 Initially developed for managing and developing products
markets, knowledge transfer
1 Develop and Release products and enhancements
2 Sustain and renew products
Uses of Scrum 3 Develop and sustain cloud and operational environments for product use
4 Research and identify viable markets, technologies and product capabilities
 Effective in iterative and incremental knowledge transfer
 Now, widely used for products, services and management of the parent organization
 Scrum teams develop, release, operate and sustain work and work products
 Founded on empirical process control theory, aka Empiricism Only past is certain.
Decisions are based on experience,
Empirical Asserts that knowledge comes from experience AND making decisions based on what is known. experimentation, observation.
Scrum employs TIA approach to optimize predictability and control risk
 3 pillars of empiricism upheld in every implementation of empirical process control: TIA
T Transparency 3 Pillars = Transparency + Inspection +
rs
lla
Scrum Theory / Pillars

Adaptation
Empirical Process Control

I Inspection
Pi
3

A Adaptation
 Those responsible for outcome must have visibility into different aspects of the process
 Those aspects must be defined by a common standard to ensure common understanding
Transparency  common language referring to the process must be shared by all participants
*common definition of "Done" between doers and inspectors

*DoD must be shared by those doing the work and those inspecting the resulting increment
 Frequently inspect Scrum artifacts and progress towards Sprint Goal to detect undesirable variances
Inspection  Inspections shouldn't be too frequent that they get in the way of work
 Most beneficial when done by skilled inspectors
Inspectors determines that aspects of a process deviate outside acceptable limits and that the resulting

product will be unacceptable
Adaptation
 There must be an adjustment to the process or material being processed
 Adjustment must be made ASAP to minimize deviation
 Scrum team's success depends on becoming proficient in 5 Scrum values: <<CanCun FORever >> Scrum Values = Commitment +
Scrum Values

Courage + Focus + Openness +

Commitment C Commit to achieving goals of the Scrum Team
Respect
Courage C Courage to do the right thing and work on tough problems (CanCun FORever)
Focus F Focus on work of the Sprint and the goals of the Scrum Team, by everyone
Openness O (scrum team + stakeholders are) Open about all the work and challenges with performing the work
Respect R Respect each other to be capable, independent people
Product Owner Scrum Team = SM + PO + DEV Team
Scrum Team Development Team
Scrum Master
Self organization and cross functional
Self-organizing: choose how to best accomplish their work, rather than being directed by those outside scrum teams

l
nc g,
na

*know best how to do the work

-fu zin
tio
ss ni
Team

ro a

Cross-functional: have all competencies needed to accomplish work without depending on those outside
C -org


scrum
lf
Se

 Scrum teams are self-organizing and cross-functional

 Team model optimizes flexibility, creativity and productivity
Iterative and incremental delivery
l
ta

 Delivers products iteratively and incrementally, maximizing feedback opportunities

en

Focus on feedback
m

Because of Incremental deliveries of DONE product, a useful version of working product is always
re


c
In

available
 PO is the only person responsible for managing Product Backlog PO =
Product Owner

Manage Product Backlog + Maximize

 Responsible for maximizing value of the product. How to do so varies
product value +
 PO is one person not a committee; Change priority
PO
 Changing backlog item's priority lies with PO
Entire organization must respect PO's decisions, which are visible via content and ordering of Product

Backlog
DEV Team = Deliver releasable
DEV Team delivers releasable Increment of DONE product at the end of each Sprint
DEV Team increment
Structured/Empowered by Organization to organize and manage their own work

Professional Scrum Master Notes Prepared by Jasleen Matharu 2020-07-15 Page 1 of 10

 Professional_Scrum_Master - Notes.xlsx

Key Description Notes

Self-organizing: No-one (incl SM) tells them how to turn Product Backlog into Increments of potentially Dev team = Self organization and cross
functional
releasable functionality
Development Team

s
tic
Cross-functional: Have all the skills are team to create a product Increment
is
er

Scrum recognizes no titles for DEV team members (regardless of work being done), no sub-teams DEV team has no sub-teams, no titles
Scrum Team

ct
ra

(QA/BA/Ops)
(regardless of domains i.e. QA, BA, Ops, Architecture)
ha
C

Members may have specialized skills/areas of focus but accountability belong to DEV team as a whole
Between 3-9 is optimal, PO + SM not included in this count UNLESS they are executing work of the Sprint DEV team=3-9 people + SM + PO if
doing Sprint Backlog work
Backlog
Should be small enough to remain nimble, large enough to complete significant work in a Sprint
ze

<3 - decreases interaction, smaller productivity gains. Skills constraints leading to inability to deliver potentially
Si

releasable Increment
>9 - too much coordination. Too complex for empirical process to be useful (T.I.A)
Responsible for promoting and supporting Scrum by helping everyone understand Scrum theory, practices, SM =
rules and values Help everyone understand Scrum
er -
ad t
le van

Facilitate Scrum events

SM is servant-leader for Scrum Team
er

Lead, coach, plan Scrum

=S

Helps those outside Scrum Team understand which of their interactions are helpful and which aren't. Remove roadblocks
SM

Also, help change interactions to maximize value created by the Scrum Team Help with tools, techniques
Ensure that goals, scope, product domain are understood by entire Scrum Team Help manage external interactions

Find techniques for effective Product Backlog management

PO

Help Scrum Team understand need for clear and concise backlog items
to

Understanding product planning in an empirical environment

Scrum Master

e
ic

Ensure PO knows how to arrange backlog to maximize value

rv
Se

Understanding and practicing agility

Facilitating Scrum events
Coaching in self-organization and cross-functionality
Help them create high-value products
am
Te o
EV t

Removing impediments to progress

D vice

Facilitating Scrum events

r
Se

Coaching in organizations where Scrum isn't adopted and understood

Leading and Coaching in Scrum adoption
Planning Scrum implementations
n
io
an to
at

Helping employees and stakeholders understand and enact Scrum and empirical product development
rg e
iz
O rvic

Causing change that increases Scrum Team's productivity

Se

Work with other SM to increase effectiveness of application of Scrum in the organization

4 formal Scrum Events for inspection and adaptation: <<PSRR - Please Say RiRi>> 4 Scrum Events = Sprint Planning +
Sprint Review + Sprint Retrospective +
Sprint Planning
Daily Scrum
s

 Sprint Review
t
en
ev

Sprint Retrospective
m

Daily Scrum
ru
Sc

 Create regularity and minimize need for meetings not defined in Scrum
4

 All events are time-boxed events, each has a max duration

Sprint is a container for all events Sprint = container for all events
Create done, useable, releasable
Each event (other than Sprint) in Scrum is formal opportunity to inspect and adapt something
product Increment
Once a Sprint starts, it's duration is fixed
Sprint
Consistent durations throughout development effort
New Sprint starts immediately after conclusion of previous Sprint
Sprint includes 4 Scrum events + development work
time-boxed to <= 1 month
* If too long: Definition of what's being built may change, Complexities arise, Risk may increase
Duration * Enable predictability by ensuring Inspection + Adaption towards Sprint Goal occurs at least every
month
Scrum Events

* Limit risk to one calendar month of cost

Purpose Create a DONE, useable, potentially releasable product Increment
No changes made that would endanger Sprint Goal
Rules Quality goals do not decrease
Scope may be clarified and re-negotiated between PO & DEV team
Sprint

Each Sprint may be considered a Project:

*Has a goal of what is to be built
Sprint~ project *a design and flexible plan that will guide building it
* the work
* resultant product Increment
Sprint can be cancelled before time-box is over
Only PO has authority to cancel Sprint; may be influenced by DEV team, SM, other stakeholders
Cancel Sprint if Sprint Goal becomes obsolete:
- changes in market, technology, company direction may cause it
Due to short duration of Sprints, cancellation rarely makes sense. Very uncommon
n
t io

Cancellations consume resources since everyone regroups in another Sprint Planning to start another
lla

Sprint
ce
an
C

Professional Scrum Master Notes Prepared by Jasleen Matharu 2020-07-15 Page 2 of 10

 Professional_Scrum_Master - Notes.xlsx

n
t io
lla
Key Description Notes
ce
an
If cancelled Cancel Sprint = Based on Sprint Goal
C

being invalid : Review done items to

* Review completed or DONE items to assess releasability.
check if releasable + re-estimate not-
* If part of work is releasable, PO accepts done items and add to backlog
* Incomplete items are re-estimated and put back in Product Backlog
Work done on items depreciates quickly and must be frequently re-estimated
Artifacts represent work or value to provide transparency and opportunities for inspection and adaptation
Designed to maximize transparency so that everyone has same understanding of the artifact 3 artifacts = Product Backlog + Sprint
ts
ac

1. Product Backlog Backlog + Increment

if
rt
A

2. Sprint Backlog
3. Increment
Ordered list of everything known to be needed in the product Product Backlog =
Product Ordered list of work to be done
Single source of requirements
R.E.F.F.F (Requirements.
Backlog PO is responsible for Product Backlog (incl content, availability, ordering) Enhancements. Fixes. Features.
Multiple Scrum teams can work on same product / backlog Functionality)
Product Backlog is never complete! Never complete since requirements
never stop changing
Product Backlog is dynamic and constantly changes- it evolves as product & it's environment evolves (to be
appropriate, competitive and useful)
ic

Product Backlog is a living artifact as the requirements never stop changing

am
yn

Changes in business requirements, market conditions, technology, feedback based on product usage add to
D

the backlog
If a product exists, it's Product Backlog also exists
Lists all features, functions, requirements, enhancements and fixes for future releases
<<R.E.F.F.F>>
Product Backlog Item has
Production Backlog items have - <<V.O.T.E.D.>> Order,Estimate, Description, Test
*Description, Order, Estimate, Value Description, Value
*test description for DONE to prove completeness Team indicator, if multiple Scrum teams

Multiple Scrum teams can work on same product, in which case a product backlog attribute can be used to
e s

group items
ut
b
tri

Higher ordered:
At

*clearer and more detailed

*More precise estimates since greater clarity and detail
Lower ordered:
*Less detailed
DEV Team is responsible for all estimates (people performing the work make the final estimate) DEV team responsible for estimates
*PO can influence DEV teams in understanding and making trade-offs but does not estimate
Refinement: Getting items to ready
Product Backlog Refinement: Act of adding detail, estimates and order to the items in the Product Backlog state. Add details, order, estimate.
Ongoing process where PO and DEV Team collaborate on Backlog item details
Items are reviewed and revised
Scrum Team decides how and when refinement is done Scrum team does refinement
Product Backlog

Consumes less than 10% of DEV Team capacity

Backlog items can be summed and updated at any time by the PO
*Backlog items that will occupy DEV Team for upcoming Sprint are refined so that any one item can be
reasonably be DONE within the Sprint
Backlog items that can be DONE in one Sprint are READY for selection in Sprint Planning
*Backlog items can be updated at any time by PO
*Backlog items that will occupy DEV Team for upcoming Sprint are refined so that any one item can be
en g

reasonably be DONE within the Sprint

em lo
t
in k
ef ac

Scrum Team decides how and when refinement is done

R tB

Multiple Scrum teams can work on same product / backlog

c
du
o

PO manages Product Backlog and is the sole person responsible for managing it:
Pr

* Clearly express backlog items

* Order the items to best achieve goals & missions
* Optimize value of work that Development Team performs
* Ensure backlog is visible, transparent, clear to all
* Backlog shows what the Scrum team will work on next
* Ensure Dev Team understands items in the backlog to the level needed
*Backlog items can be updated at any time by PO
*PO can influence DEV teams in understanding and making trade-offs but does not estimate
PO may do above work for managing backlog OR have Development Team do it. Product Backlog:
Managed by PO
PO remains accountable for managing backlog
Reviewed at Sprint Review
DEV Team is responsible for all estimates (people performing the work make the final estimate)
PO tracks and monitors Product Backlog
PO tracks Product Backlog remaining every Sprint Review, at the least
Amount of work can be story points or
At any point, total work remaining to reach a goal can be tracked and summed task hours
Product backlog monitors progress towards Goals
Scrum Artifacts

w
ie
ev
tR
rin
Sp

Professional Scrum Master Notes Prepared by Jasleen Matharu 2020-07-15 Page 3 of 10

@
a ck
Tr
 Professional_Scrum_Master - Notes.xlsx

Key Description Notes

Scrum Artifacts

Progress forecast using projective practices like burn-downs, burn-ups or cumulative flows Burn-down: work remaining

w
ie
Burn-up: work done
ev
tR *Burn-down chart: amount of work remaining. Can be story points or task hours. Will fall over time. Shows
work remaining in Sprint backlog and product backlog.
rin
Sp

*Burn-up chart: amount of work done. Can be story points or task hours. Will rise over time. The plotted line
@

of burn-up chart will approach the in-scope line as work is completed.

a ck

These do not replace empiricism: what will happen is unknown; only what has already happened can be
Tr

used for forward-looking decisions

PO tracks total work remaining at least every Sprint Review; compares this to work remaining in previous
Sprint Review to assess progress towards completing projected work by desired time for the goal -->
Transparent to all stakeholders
Set of Product Backlog items selected for Sprint + a plan for delivering (the product Increment and realizing Sprint Backlog=
Sprint Backlog Managed by DEV Team.
Sprint Goal) + Managed by DEV Team
Forecast of functionality in the
Sprint Backlog is a forecast by DEV Team about : Increment.
1) what functionality will be in the next Increment (Forecast of functionality - product backlog items Product backlog items selected + Plan
What + How
selected by DEV team to be implemented in a Sprint) to deliver.
2) the work needed to deliver that functionality into a DONE Increment DEV work needed to meet Sprint Goal.
Include one process improvement from
Process SPRINT BACKLOG Must include at least ONE high-priority process improvement identified in previous last Sprint (Retrospective).
Improvement Retrospective meeting (to ensure continuous improvement) Technical debt can be defined as the
Visibility Makes visible ALL the work that DEV Team identifies as necessary to meet the Sprint Goal longer term consequences of poor
Sprint Backlog

design decisions.
Level of detail Sprint Backlog is a plan with enough detail that changes in progress can be understood in Daily Scrum
Scrum board can be used to manage
Modified by DEV Team throughout the Sprint and it emerges during the Sprint Sprint Backlog but are optional
As the team works through the plan and learns more about the work needed to achieve the Sprint Goal Velocity : Optional indication of the
As new work is required, the DEV Team adds it to the Sprint Backlog amount of Product Backlog turned into
m

an Increment of product during a sprint.

a

Only DEV Team can change it's Sprint Backlog during the Sprint
Te

Tracked by DEV Team for use within

EV

Add, remove, update elements of the plan as work is completed or deemed unnecessary Scrum Team
D

Highly-visible, real-time picture of the work that DEV team plans to accomplish during the Sprint
Belongs solely to the DEV Team
DEV Team tracks Sprint Backlog
ru ily

At any point in a Sprint, total work remaining in a Sprint Backlog can summed
Sc Da
m

DEV team tracks Sprint Backlog every Daily Scrum, at the best
@

This projects the likelihood of achieving the Sprint Goal

ck
a
Tr

Manage progress by tracking remaining work

Increment is the sum of all Product Backlog items completed during a Sprint + value of increments of all Increment = work done by DEV team in
a sprint
previous Sprints Sum of all Increments = Product
Increment Increment: body of inspectable, done work that support empiricism at end of the Sprint
Increment

Increment is a step towards a vision or goal

Must be in a useable condition regardless of whether PO decides to release it
DONE Increment: must be in a usable condition and meet Scrum Team's Definition of DONE
Once Sprint ends, new Increment must be DONE
e
on
D

DONE Increment is required at Sprint Review

Scrum relies on transparency
Decision to optimize value and control risk are based on state of artifacts
Artifact Transparency

If artifacts are not completely transparent, decision can be flawed, value may diminish and risk may increase
SM to work with PO, DEV Team, others to ensure artifacts are completely transparent
If not then SM must help everyone apply most appropriate practices for coping with incomplete
transparency
r
te
as

SM can detect transparency by : inspecting artifacts, + sensing patterns, + listening closely to what is
M
um

said and + detecting difference between expected and real results

r
Sc

SM job is to work with Scrum Team and org to increase transparency of artifacts
Transparency involves learning, convincing and change. Transparency is a path.
DoD is used by Scrum Team to assess when work is complete on the product Increment Definition of Done:
Managed by DEV Team
DoD may vary per Scrum Team, but members have a shared understanding of what it means for work to
Shared understanding of what would
be complete make Increment releasable

This definition guides DEV Team in knowing how many Backlog items it can select during Sprint Planning
Purpose of each Sprint is to deliver Increments of potentially releasable functionality that adheres to
Definition of
Definition of Done

Scrum Team's current DoD

Done
DEV team delivers an Increment of Product functionality every Sprint
Increment delivered is usable and PO may release it immediately
Each Increment is additive to all prior Increments and thoroughly tested, ensuring all Increments work
together
As Scrum Teams mature, their DoD will expand to include more stringent criteria for higher quality
As definition changes, it may uncover work in previously DONE Increments that needs to be done
If definition of DONE is part of organization's conventions, standards or guidelines then all Scrum Teams
follow it as a minimum
n
io

If there is no convention on DONE Increment then DEV Team must define a definition of Done
nt
ve

If multiple Scrum Teams working on system/product, the DEV teams on ALL Scrum Teams must mutually
on
C

define the definition of DONE

Professional Scrum Master Notes Prepared by Jasleen Matharu 2020-07-15 Page 4 of 10

 Professional_Scrum_Master - Notes.xlsx

Daily Scrum Sprint Planning Sprint Review Sprint Retrospective

Scrum Team collaboratively plans the work to be performed in the Informal meeting held at end of Sprint to inspect the Scrum Team inspects itself and creates plan
About A key inspect and adapt meeting
Sprint (Plan the Sprint + Set the goal) Increment and adapt the Product Backlog, if needed for improvements for NEXT SPRINT
Optimizes team collaboration & performance by
inspecting the work since last Daily Scrum and
forecasting upcoming Sprint work
Process Improvement, added to next Spring
Scrum team : Backlog
Increases probability that DEV team will meet Sprint Present Increment to elicit feedback and foster
inspects Product Backlog for most valuable work + Review/change DEFINITON OF DONE
Purpose Goal collaboration
+ designs that work into Sprint Backlog
+ update Product Backlog
+ sets SPRINT GOAL Occurs after Sprint Review but before next
Improves communication, eliminate other meetings,
Sprint Planning
identify impediments for removal, promote quick
decision-making, improve DEV team's level of
knowledge
15-min
Duration max 8-hour max 4-hour max 3-hour
(every day, same time, same place)

Attendees Development Team Scrum Team + those invited by DEV team (for technical/domain advice) Scrum Team + Key stakeholders invited by PO

*Structure is set by DEV Team

*Can be conducted in different ways (Qs or
Formal opportunity to focus on inspection and
discussion) Informal meeting, not a status meeting
adaptation
*Some teams can use questions, others are some
Structure discussion based
+ What did I do yesterday that helped the DEV team What can be done this Sprint? Inspect how the last Sprint went
Questions meet the Sprint Goal? (What can be delivered in the Increment resulting from the Sprint?) (w.r.t. people, relationships, process, tools)
to answer What will I do today to help the DEV team meet the How will the chosen work get done? Identify and order the major items that went
Sprint Goal? (How will the work needed to deliver the Increment be achieved?) well and potential improvements
Create a plan for implementing
Do I see any impediment that prevents me or the
improvements to the way Scrum Team does
DEV team from meeting the Sprint Goal?
the work
*Product Backlog
*Latest product Increment
*Projected capacity of DEV team
Input *Past performance of DEV team

*Backlog items that can be DONE in one Sprint are READY for selection
in Sprint Planning
Identified improvements for will be implemented
*Sprint Goal
Revised Product Backlog (probable for the next Sprint, next Sprint
*How to accomplish Sprint Goal and create the Increment
adjusted to meet new opportunities)
Output *Plan for the work that DEV team can do in the Sprint
Implementing improvements in next Sprint is the
*Work planned for first few days is decomposed to units of 1 day or
adaptation to the inspection of the Scrum
less by end of Sprint Planning
Team itself

*SPRINT GOAL is set by Scrum Team during Sprint Planning

*Usually, a business problem to address
*An objective set for the Sprint that's met thru implementation of Product
At least ONE high-priority PROCESS
Backlog
Sprint Goal IMPROVEMENT identified during Retrospective
*provides guidance to DEV team on WHY it's building the Increment
is added to the NEXT SPRINT BACKLOG
*Provides flexibility to DEV Team re functionality implemented in a Sprint
*Goal can be one coherent function that the selected product
backlog items deliver

Sprint *Sprint Backlog = Product Backlog items in this Sprint + Plan for
Backlog delivering them

PSM - Scrum Roles Event Prepared by Jasleen Matharu 2020-07-15 Page 5 of 10

 Professional_Scrum_Master - Notes.xlsx

Daily Scrum Sprint Planning Sprint Review Sprint Retrospective

Scrum Team + Stakeholders:
* collaborate about what was done in the Sprint + what
were changes to Product Backlog during the Sprint +
next things to do to optimize value
* Scrum Team collaboratively plans the work to be performed in the
*Collaborate on what to do next (So sprint review
Sprint *Plan ways to increase product quality by
provides valuable input to next Sprint Planning)
Scrum *Collaborates on understanding the work of the Sprint improving work processes or adapting the
Team *Set/create a Sprint Goal during Sprint Planning definition of DONE (if not in conflict with
*Review any changes to what is most valuable thing to do
product or org standards)
next, based on changes in marketplace or potential use of
*Team pulls work from Product backlog --> to Sprint Backlog
product

*Review timelines, budget, potential capabilities,

marketplace for next anticipated release of functionality or
capability of the product
Explain what Product Backlog items are DONE and not
Done

Discuss Product Backlog as it stands

*Discuss objective that Sprint should achieve
*Discuss Project Backlog items that, if completed, would achieve the Likely target and delivery dates based on progress to date
Product
Sprint Goal (if needed)
Owner
*Clarify the selected Product Backlog items
*Make trade-offs *PO tracks total work remaining at least every Sprint
Review; compares this to work remaining in previous
Sprint Review to assess progress towards completing
projected work by desired time for the goal --> Transparent
to all stakeholders

*Forecast the functionality that will be developed in the Sprint

*ONLY DEV Team can assess what it can accomplish in Sprint
*DEV team plans work for the next 24 hours *Select Product Backlog items for the Sprint
*Inspect progress toward Sprint Goal
*Inspect progress towards completing work in Sprint *DEV team decides HOW it will build a DONE product Increment
Backlog *Sprint Backlog = Product Backlog items in this Sprint + Plan for
delivering them
Discuss:
*DEV Team sets the structure for Daily Scrum *Design the system + work needed to convert Product Backlog into
*what went well during Sprint,
meeting Working Product Increment
*problems it ran into, and
*DEV Team is responsible for conducting the *DEV team forecasts what it believes it can do in the upcoming Sprint
*how those problems were solved
Developme Daily Scrum
+
nt Team *Re-negotiate items with PO if too much/little work or different than
Demo
*DEV team / members often meet immediately after expected
*DEV Team demonstrates the work that has been
Daily Scrum for detailed discussions or to adapt/re- *DEV team can invite other people for technical/domain advice
DONE
plan the rest of the Sprint's work *Explain to PO+SM on how to accomplish Sprint Goal and create the
*Answer questions about the Increment
Increment
*Every day DEV Team should understand how it will *DEV Team self-organizes to undertake the work in Sprint Backlog
work together as self-organizing team to during Sprint Planning and throughout the Sprint
accomplish Sprint Goal and create the anticipated
Increment by the end of the Sprint *Implements functionality and technology to meet the Sprint Goal
*Use Definition of DONE to know how many items to select for Sprint
*Select items without accruing Technical Debt

*Ensure that event takes place and attendees

*Ensure that the event takes place
understand the purpose
*Ensure that DEV team has the meeting
* Teach everyone to keep it within time-box
(but DEV team is responsible for conducting the
*Ensure that event takes place and attendees understand *Ensure meeting is positive and productive
Scrum Daily Scrum) *Ensure that event takes place and attendees understand the purpose
the purpose *Participate as a peer team member from the
Master *Teach DEV Team to keep it within time-box * Teach Scrum Team to keep it within time-box
* Teach everyone to keep it within time-box accountability over the Scrum process
*Encourage Scrum Team to improve within
*If non-DEV present then ensure they do not disrupt
Scrum framework, it's development process and
the meeting (as it is internal meeting for DEV Team)
practices

PSM - Scrum Roles Event Prepared by Jasleen Matharu 2020-07-15 Page 6 of 10

 Professional_Scrum_Master - Notes.xlsx

Key Description Notes

3-9 Scrum teams work on single Product Backlog to
Nexus = Nexus Integration Team + ~3-9 Scrum Teams deliver Integrated Increment
Nexus ~ Scaled Scrum
Nexus uses Scrum as it's building block
Binds together work of ~3-9 Scrum Teams on a single Product Backlog
Nexus Teams working together to build an Integrated Increment that meets the goal
Nexus: A relationship or connection between people or things
Framework for developing and sustaining SCALED product and software delivery initiatives
Framework of roles, events, artifacts, rules
Ken Schwaber and Scrum.org developed it
Process framework for multiple Scrum Teams working together to create an Integrated Increment
Nexus Framework Similar to Scrum but focus is on dependencies &
Difference from Scrum: more attention on dependencies and interoperation between Scrum Teams interoperation
Deliver one DONE Integration Increment every Sprint (at least 1)
Communication when developers are not collocated
Challenges Integration and testing of Integrated increment when working on different teams
Nexus

Working off same backlog and codebase for a product

Based on dependencies, team self-organize and select most appropriate members to do specific work
1)Requirements Dependencies: S.R.K = Software. Requirements.
Knowledge
Nexus Dependencies 2)Domain Knowledge Reduce dependencies by mapping to same Scrum
3)Software and Test Artifacts Team
[Nexus Dependencies ~ S.R.K]

Overlapping requirements scope

1)Requirements Sequencing of implementation of requirements can affect each other
Requirements overlap and sequencing affects ordering and selecting Product Backlog items
Teams have knowledge of business and computer systems
2)Domain Knowledge Distribute knowledge across teams so that they have knowledge on how to do their work
Share the knowledge of business/computer systems across Scrum Teams to minimize interruptions
3)Software + Test Artifacts Requirements are instantiated in software
Reduce dependencies by mapping requirements, knowledge and artifacts to same Scrum Teams
Reduce dependencies
These dependencies should drive the organization of DEV teams
This optimizes productivity
Nexus Integration Team = Product Owner + Scrum Master + Nexus Integration Team members
Accountable: Nexus Integration Team accountable to ensure DONE Integrated Increment is Nexus Int Team ensure Integrated Increment is done;
Nexus Integration Team produced at least once every Sprint but Scrum Teams actually deliver Increments
Responsible: Scrum Teams responsible to deliver DONE increments
coordinate, coach, supervise application of Nexus and operation of Scrum
Nexus Integration Team members are usually also members of individual Scrum Teams Nexus work is priority over Scrum team work
Priority is given to their work on Nexus Integration Team (if they are on a Scrum Team also)
Priority
Nexus Integration Team membership has precedence over Scrum Team membership
Nexus precedence ensures work to resolve issues impacting many teams takes priority
Composition of Nexus Integration Team can change over time
Work Work involves coaching, consulting, highlighting dependencies and cross-team issues
May also perform work from the Product Backlog
Nexus (NIT = PO + SM + NIT members | 3-9 Scrum Teams) Integration issues - addressed by Scrum Teams
Scrum Teams address integration issues within the Nexus
Nexus Integration Team

Issues Nexus integration team provide focal point of integration for Nexus
Integration include resolve technical and non-technical cross-team constraints that impede ability to
deliver a constantly Integrated Increment
Nexus Roles

Use bottom-up intelligence from Nexus to achieve resolution

Nexus has ONE Product Backlog and a Product Backlog has ONE PO
PO is responsible for maximizing the value of the product and work performed/integrated by Scrum
PO: Maximize value + Manage Backlog + 1 PO
Teams in a nexus
Product Owner PO is accountable for managing Product Backlog so that maximum value is derived from Integrated
Increment created by a Nexus
How to manage backlog varies across org, nexuses, scrum teams and individuals
PO is member of Nexus Integration Team
SM responsibility: ensure Nexus framework is understood and enacted SM: Help understand Nexus framework
Scrum Master
SM may be SM in one or more Scrum Teams in Nexus
professionals skilled in systems engineering
Ensure that Scrum Team - Nexus Integration Team members: Scrum team
understand tools/practices to detect dependencies + understands practices, tools, standards + frequently
frequently integrate all artifacts to definition of DONE integrates
Nexus Integration Team Nexus Integration Team members responsibility: coaching and guiding Scrum Teams to acquire,
Members implement, learn tools & practices
Coach Scrum Teams on development, infrastructural, architectural standards per org
Ensure development of quality Integrated Increments
If their primary responsibility is satisfied, they can work as DEV Team members in one or more Scrum
Teams

Nexus Notes Prepared by Jasleen Matharu 2020-07-15 Page 7 of 10

 Professional_Scrum_Master - Notes.xlsx

Key Description Notes

Artifacts represent work or value to provide transparency and opportunities for inspection and
Artifacts
adaptation
Single Product Backlog for entire Nexus and all of it's Scrum Teams 1 Product Backlog. 1 PO.
Indicators of which team work on Backlog Items in a Sprint are made transparent Team indicator added to Product Backlog
PO is accountable for Product Backlog incl content, availability and ordering
Product Backlog must be understood at a level where dependencies can be detected and minimized
Product Backlog
To support resolution, Product Backlog items are resolved to granularity called "thinly-sliced"
Decomposed till items are thinly-sliced
functionality
Product Backlog items are READY for Nexus Sprint Planning when Scrum Teams can select items
Item Ready - one team can do the work
with no or minimal dependencies with other Scrum Teams
assists with transparency during the Sprint
All Scrum Teams maintain individual Sprint Backlogs
All Scrum Team's selected Product Backlog items + any dependencies are made transparent via Nexus Sprint Backlog = Product Backlog item in Sprint
Nexus Sprint Backlog Nexus Sprint Backlog for all Scrum Teams + dependencies
Composite of Product Backlog items from Sprint Backlogs from Scrum Teams
Used to highlight dependencies and flow of work during Sprint
Updated daily as part of Nexus Daily Scrum
Nexus Artifacts

Combined work completed by Nexus

Represents current sum of all integrated work completed by Nexus
Integrated Increment Must be usable and potentially releasable
Must meet definition of DONE
Inspected at Nexus Sprint Review
Nexus is based on transparency
Transparency of artifacts is critical to decisions made
Incomplete information will lead to flawed or incorrect decisions
Impact of flawed/incorrect decisions can be magnified at the scale of Nexus
Technical debt can be defined as the longer term
Transparency consequences of poor design decisions.
Software must be developed so that dependencies are to detected and resolved before technical Can be recorded in your heads, in a technical debt
debt becomes unacceptable to nexus register or product backlog
Eg. poor design decisions” might be made for the
sake of expediency
Without transparency, Nexus cannot minimize risk and maximize value
Nexus integration team is responsible for definition of
Nexus integration team is responsible for definition of DONE DONE
DOD is applied to integrated Increment developed each Sprint
All Scrum Teams in nexus adhere to this DOD
Definition of Done
Definition of Done - ensure that the Increment
Increment is DONE only when integrated, usable and potentially releasable by PO integrated and releasable
Scrum Teams may have a more strict DOD within teams but cannot apply less rigorous criteria than
agreed for the Increment
Refinement is continuous throughout the Sprint, as needed Continuous throughout the Sprint

Refinement Decompose Product Backlog to identify, remove, reduce dependencies

Items refined into thinly-sliced pieces of functionality Decomposed till items are thinly-sliced
Identify the team likely to do the work
Identify Scrum teams likely to take backlog items
1) Identify which Scrum Teams that will deliver which Product Backlog Items (add Teams indicator to product backlog items)
Dual purpose of Refinement 2) Identifies dependencies across those teams
Refinement

Identify dependencies
This way teams and monitor and minimize dependencies
Number, frequency, duration, attendance of Refinement is based on dependencies and inherent Frequency, attendance, duration of Refinement based
uncertainty in the Product Backlog on dependencies & uncertainty
Nexus continues Product Backlog refinement until items are independent enough to be worked on Continue refinement until items can be worked on by
by a single Scrum team one Scrum team
Decomposition by Nexus
Product Backlog items go through decomposition of very large, vague requests to actionable work that a From large, vague items to actionable work by one
single Scrum can deliver in a Sprint Scrum
Product Backlog Refinement continues within each Scrum Team until the Product Backlog items Scrum teams keep refining before they select the
are ready for selection in a Nexus Sprint Planning items in a Sprint (at Nexus Sprint Planning)

Scrum Team (reps) select backlog items for each team

Nexus Sprint Planning
Review refined backlog
Each Scrum Team plans it's own Sprint Select backlog items
Discuss Sprint Goal (PO)
Set of Sprint Goals that align with overarching Nexus Sprint Goal Nexus Sprint Goal + Set of Scrum Team Sprint Goals
Output each Scrum Team's Sprint Backlog 1..n Replace Sprint Review
single Nexus Sprint Backlog..1
Purpose coordinate activities of all Scrum Teams in a Nexus for a single Sprint
PO Provides domain knowledge and guides selection and priority decisions
PO discussed Nexus Sprint Goal
Nexus Sprint Planning

describes purpose that will be achieved by Scrum Teams during Sprint

Is an objective set for the Sprint
Nexus Sprint Goal It is the sum of all the work and Sprint Goals of Scrum Teams within the Nexus
The functionality that Nexus completes to meet the Nexus Sprint Goal is demo'd at Nexus Sprint Review
to get stakeholder feedback
Product Backlog should be refined with dependencies identified and removed or minimized prior to Refinement + dependencies identified before Sprint
Prerequisite planning
Nexus Sprint Planning
Scrum Team (reps) validate and adjust ordering of the work that was created during Refinement
All members of Scrum Team should participate to minimize communication issues Entire Scrum Team participates
After overall Nexus work is understood, Nexus Sprint Planning continues with each Scrum Teams
Who performing their own Sprint Planning

Nexus Notes Prepared by Jasleen Matharu 2020-07-15 Page 8 of 10

 Professional_Scrum_Master - Notes.xlsx

Key
Who Description Notes
Nexus Sprint planning continues in Scrum Sprint
Nexus Sprint Planning is complete when each Scrum Team finished their individual Sprint
planning until all the Scrum Team's Planning is
Planning completed
Scrum Teams will continue to share any new dependencies with other Scrum Teams in the Nexus
Any new dependencies identified should be made transparent and minimized
Adjust the sequence of work across teams, as needed
Dependencies
Nexus Events || Nexus Process Flow

Adequately refined Product Backlog will minimized new dependencies being identified in Nexus Sprint
Planning
Nexus Sprint Backlog All Product Backlog items selected for Sprint and their dependencies are made transparent
Development Work All teams frequently integrate their work in a common ENV that can be tested to ensure integration
Each DEV Team's reps meet daily to identify integration issue DEV Team members attend
Focus on Integrated Increment and issues +
If integration issues exist, this is shared with each Scrum Team's Daily Scrum
Nexus Daily Scrum dependencies
Scrum Teams use Daily Scrum to create plan for day, sure toe address integration issues from nexus
daily scrum
Nexus Daily Scrum

Focus on inspecting current state of Integrated Increment, identify integration issues or new cross-team
dependencies/impacts
Focus
Focus on each team's impact on the Integrated Increment
Inspect progress towards Nexus Sprint Goal 3 questions: I.I.D. Integrated. Info. Dependencies
Was previous day's work successfully integrated? If not, why not? Was work integrated?
Questions What new dependencies have been identified? Any new dependencies?
What information needs to be shared across teams in the Nexus? Any new info to share across teams?
At least every Nexus Daily Scrum, the Nexus Sprint Backlog should be adjusted to reflect current state
Nexus Sprint Backlog Change Nexus Sprint Backlog every N.Daily Scrum
of Scrum Teams within Nexus
Scrum Teams take back issues and work from Nexus Daily Scrum to individual Daily Scrum for planning Take Nexus Daily Scrum issues to Scrum Team's
Individual Daily Scrum
the work Daily Scrum
All Scrum Teams meet with stakeholder to review Integrated Increment and provide feedback
All Scrum Teams meet at Nexus Sprint Review All should attend
Nexus Sprint Review Adjust Product Backlog
Nexus Sprint Review

Nexus Sprint Review replaces individual Scrum Team Sprint Reviews

Held at the end of Sprint
Demo Integrated Increment
Show DONE functionality that met Sprint Goal
To provide feedback on Integrated Increment that Nexus has built over Sprint + adjust Product Backlog Get feedback
Purpose
(if needed) Change Product Backlog at Sprint Review
Replace Scrum Sprint Review
Held at end of Sprint
entire Integrated Increment
Focus Cannot show all completed work in detail. Techniques may be necessary to maximize stakeholder
feedback
Output Result of Nexus Sprint Review is a revised Product Backlog
Process change
Nexus Retrospective 3 parts Bottom-up intelligence: 3 part
Identify shared challenges/issues (reps from each Scrum Team meet first)
Nexus Retro Scrum team reps meet to identify challenges
Meet and identify issues that impacted more than one team
Each Scrum Team has it's own Sprint Retrospectives
Scrum Sprint Retro Issues raised in first part of nexus retro are input for team discussions Each Scrum Team reviews and provides actions
Individual teams for actions to address the issues
Nexus Sprint Retrospective

Bottom-up intelligence: Reps from each Scrum Team meet again to discuss actions needed based on
shared challenges Scrum team reps meet again to review and track
Nexus Retro actions
Meet and agree on how to visualize and track identified actions
This enables whole Nexus to adapt
Formal opportunity for nexus to inspect and adapt itself + create plan for improvements for next Sprint to
About
ensure continuous improvement
1. Nexus Sprint Review
Sequence 2. Nexus Sprint Retrospective
3. Nexus Sprint Planning (next one)
3 Questions to address:
Was any work left undone? Did Nexus generate technical debt?
Were all artifacts successfully integrated frequently (esp. code, every day)
Scaling Dysfunctions to Was software successfully built, tested, deployed often enough to prevent unresolved dependencies?
address at every Retro If yes the address
Why did this happen?
How can technical debt be undone?
How can recurrence be prevented?

Nexus Notes Prepared by Jasleen Matharu 2020-07-15 Page 9 of 10

 Professional_Scrum_Master - Notes.xlsx

Nexus Daily Scrum Nexus Refinement Nexus Sprint Planning Nexus Sprint Review Nexus Sprint Retrospective
Nexus Daily Scrum --> Nexus Sprint Planning --> Individual No Individual Sprint Review. It Nexus Retro --> Individual Retro -->
About Refine before Sprint Planning
Individual Daily Scrum Sprint Planning is replaced. Nexus Retro

*Identify likely team (Forecast the team)

*Integrate *Review Integrated Increment
*Identify dependencies
*Information *Get feedback
Summary *Nexus refines till independent for 1 team 3-parts
*Dependencies *Change Product Backlog
*Scrum team refines till Ready for
*Change Nexus Sprint Backlog
selection at Nexus Sprint Planning

15-min
Duration (every day, same time, same Refinement is continuous max 8-hour max 4-hour max 3-hour
place)
Appropriate reps from each Scrum Team
Who+When+#sessions + How long -
meet to review backlog + select items All members of Scrum Team +
Attendees Reps from Development Team depends on dependencies & uncertainity Approriate reps from each Scrum Team
All members of Scrum teams should Key stakeholders invited by PO
in backlog
participate
Ask below questions + why it happened,
Discuss these 3 questions: how to resolve technical debt, avoid
recurrence?
Was last day's work Any work left undone? Did Nexus
Structure Identify likely Team
integrated? generate Technical Debt?
+
Questions All artifacts (Product Backlog, Sprint
to answer New dependencies identified? Identify dependencies Backlog, Increment) + code frequently &
successfully integrated?
Software built, tested, deployed often
Information to share with other
enough to prevent unresolved
teams in Nexus?
dependencies?
*Scrum Team Reps from team validate +
adjust ordering
1) Reps identify shared issues +
*Review refined Product Backog (Scrum challenges affecting more than 1 team
Team reps)
Check Integrated Increment Product Backlog refined before Sprint *Order items *Replaces Individual Sprint 2) Individual Team Sprint Retrospectives
Adjust Nexus Sprint Backlog Planning *Select items Review - Review + form actions to shared
Key daily at Daily Scrum Nexus continues refinement until item *Discuss Nexus Sprint Goal (PO) *Feedback on Integrated challenges (bottom-up intelligence)
Check progress towards Nexus independent enough for 1 Scrum Team & *Identify any new dependencies Increment
Sprint Goal Ready for selection for Sprint Planning *Adjust sequencing across teams *Adjust Product Backlog #) Appropriate reps meet again + agree
*All items selected + dependencies added on how to TRACK ACTIONS
to NEXUS SPRINT BACKLOG -create plan for improvements to be
*Each team plans it's own Spring and enacted next sprint
creates their own Sprint Goals and Sprint
Backlogs
*Nexus Sprint Goal
Create plan for improvements to be
Take issues back to Individual Thinly Sliced PBIs (Product Backlog *Nexus Sprint Backlog
Output Adjust Product Backlog enacted NEXT SPRINT to ensure
Scrum for planning Items) for ONE TEAM to work on *Individual Team's Sprint Goals
continuous improvement
*Individual Team's Sprint Backlogs

Nexus Events Prepared by Jasleen Matharu 2020-07-15 Page 10 of 10