Scrum Framework

Empiricism
• Empiricism says knowledge comes from experience and
• Making decisions based on what is known.

Transparency
• Everyone has a common understanding of what is happening.
• By sharing updated information – Scrum teams create transparency.
• Transparency is with respect to:
o Product Backlog – which lets anyone know what are the requirements that are part of this
Project or Product – which evolve dynamically.
 Scrum Teams use Backlog refinement (an activity) to work on future Backlog Items –
adding more detail, understanding them better, coming up with what is the work
needed to deliver them, if possible, doing an estimation etc.
o Sprint backlog – owned by Developers – the work that Developers will be doing in the Sprint.
 Developers select which backlog items they can work in the Sprint from Product
Backlog based on the order (or priority) set by the Product Owner
 Sprint Backlog evolves as the Sprint progresses – at any time, backlog items can be
added to it by Developers, more tasks can be added as they discover more.
 Sprint Backlog should be used in Daily Scrum – every 24 hours Developers plan what
they are going to do to get closer to Sprint Goal
o Increment – what is delivered in this Sprint + whatever was delivered earlier
 Definition of Done – a checklist that helps Scrum Teams to know what all the work
they have to do to produce a usable increment. This includes various levels of
testing, documentation, focus on Non-Functional Requirements (security,
performance, scalability etc.)

Inspection
• Frequently checking what is happening
• Each Scrum Event is an opportunity to inspect and adapt.
• Never skip any Scrum event.

Adaptation
• Adjusting the work (project) so it is back on track.
• For ex:
o In Daily Scrum, Developers discover that one particular backlog item has not received
Security approval. Without this approval, the Increment is not Done. There is a possibility
that this approval may come after the Sprint.
o They negotiate with PO on what to do:
 Can they carry this item to Next Sprint and complete it?
 Can they work on some other Backlog Item in this Sprint?
o This must be updated in Sprint Backlog for transparency.

Complex Projects/Product Development

• For you to understand Scrum better – consider Product mindset instead of Project mindset.

Project Mindset Product Mindset

• Project is temporary with an end date. • If the Product has demand, it will be there in
the market.
• Project will complete by some time, then to • If Product has demand, a Scrum team works
maintain or support the deliverable, support on it to enhance it, support it, maintain it etc.
projects are launched.

Created by Raju K ([email protected]) to complement Scrum.org trainings 1

 • Stacey matrix explains what complexity all is about: (Image credit: from Internet)

Core elements of Scrum

Accountabilities or Events Artifacts Rules and others
Roles
• SM 1. Sprint • Product Backlog • Empiricism
• PO 2. Sprint o Product • 5 Scrum
• Developers Planning Goal Values
• Scrum Team 3. Daily Scrum commitment • Timeboxes
includes SM, 4. Sprint • Sprint Backlog • Self-
PO, and Dev Review o Sprint Goal management
• Size of Scrum 5. Sprint Retro commitment • Cross
Team: 10 or • Increment functional
fewer o Definition of team
Done
commitment
Differences in ways of working b/n Non-Scrum & Scrum
Non-Scrum In Scrum
Project A temporary endeavor/work Uses Product concept. As long as the
with an end date and an Product exists, Scrum Teams would
objective to meet continue to
support/enhance/maintain it as
needed.
Project Team Team members who work on Scrum Team – PO + Dev + SM only
producing Project Output
Team members Usually called by skill, role (BA, In Scrum – anyone who is developing
QA, SW Engr, Sr SW Engr, value and part of team is called
Consultant, System Admin, DBA Developer. So even BA, QA etc. will
etc.) be called Developers.

Created by Raju K ([email protected]) to complement Scrum.org trainings 2

 Project Sponsor Who invests in the Project, who This is PO’s responsibility.
brings funding and budget to
the project
Project Manager A dedicated role focused on Each role does its own management –
managing the Project there is no need for a dedicated
Project Manager
Stakeholder Primarily done by PM Should be done by PO, but
Engagement Developers can interact with
Stakeholders as needed (for ex:
understanding a requirement,
showing a demo, clarifying on a bug
etc.)
Scrum Master
• Ensure that the team follows Scrum as defined in Scrum Guide.
• SM serves the Scrum Team:

•
• SM serves the PO:

• SM serves the Org (outside the Scrum team):

Created by Raju K ([email protected]) to complement Scrum.org trainings 3

 Stakeholder Engagement
• SM can coach the PO about Stakeholder engagement following this example approach:

Certain things that SM should avoid:

• Assigning backlog items to team members (because Developers pick the backlog items themselves)
• Providing solutions to Developers
o First SM should allow Developers to explore on their own (because they are self-managing,
they should try first from their end)
o If it doesn’t work then SM can intervene, help them to find solution and support it
• SM is not a Project Manager.
o Each role in Scrum does its own management.
 PO  Scope management, Cost management, Stakeholder engagement
 Dev  Work management (who is going to work on what – they will decide)
 PO + Dev  Quality Management
 SM  w.r.t. to Scrum: Process Management, Communications Management

Product Owner
• Like your Project Sponsor, Business SPOCs (Single point of Contacts who takes necessary decisions
regarding project/module/functionality etc.), Application or Service Owner (from customer who will
own an entire application like SAP MM, IT service Desk, CRM Application etc.)

Primary Responsibilities
• Requirements management
o Ensuring that requirements are stored in Product Backlog, available to Developers with
required details
o Ordering the requirements – which one should be done first
 Few techniques
• Value

Created by Raju K ([email protected]) to complement Scrum.org trainings 4

 o Ex: For a subscription model, if we rollout this enhancement, how
much value we are delivering to our customers?
 If each subscription is $10, if we get 100 subscribers,
value is $1000
• Risk
oWhich is high risk item – given higher priority
oEx: there is a regulation or law which we must meet. So, it is given
higher priority. For ex: GDPR implementation.
• Time criticality
o Ex: Valentine’s day is coming – so those deals are more important
at this point of time (written on 11-Jan)
o Connecting Dev to required Stakeholders
 Ex: for arranging Job shadowing so developers know how the work is done, helping
them in testing etc.
• Monitoring the progress towards Product Goal
o Product Goal – end objectives that we are trying to achieve.
 Template: https://www.romanpichler.com/blog/product-goals-in-scrum/

o In Sprint Planning for each Sprint – PO collaborates with Dev and SM to create a Sprint Goal
[Important: Sprint Goal is created by all 3 roles- PO + SM + Dev]
 Product Goal is product objective whereas Sprint Goal is objective for each Sprint.
Sprint Goal is a steppingstone towards Product Goal
o In Sprint Review, provides updates about Budget, what is happening in the market, customer
feedback, CSAT scores etc.
• Product Backlog management

PO and BA Differences
Product owner Business Analyst
• Key Scrum accountability & Role • Part of Developers
• Accountable for Delivering (or maximizing • Accountable for documenting
value) requirements, helping Developers
understand requirements, may do
functional testing

Created by Raju K ([email protected]) to complement Scrum.org trainings 5

 • Typically comes from Business (i.e., your • Typically, may come from offshore supplier
customer like Business Owner, Application teams (from Customer they can be known
owner, SPOC etc.) as SMEs)
• Main activities: • Main activities:
o Coming up with Product vision and o Documenting scope
product goal o Creating User stories (one
o Getting budget for the Project example)
o Engaging with Stakeholders for o Connecting Developers with
their requirements, sharing them Stakeholders
Project progress, inviting them for o Doing functional testing
Sprint Review etc. o Help the PO to come up with
o Ordering Product Backlog Product Vision and Goal
o Communicating backlog items o Facilitate Customer Journey
clearly to Developers mapping etc. to understand
o Deciding on Release requirements better
o Sign off on requirements
• Common things between PO and BA:
o Create User stories (anyone can create user story)
o Connect Devs to Stakeholders
o Doing functional testing
o Help the Devs to understand the requirements better
Developers
• A group of people – team – that has all the skills required to deliver Project output (Product)
• Cross functional team – as a team they have all the skills required
• Self-managing – developers decide how to work, no task assignment by someone
• No titles – Testers, Business Analysts, Team leads etc. are not used.
• No sub-teams. For example, a dedicated QA Team which does only testing is an anti-pattern.

Scrum Events
Example 2-week Sprint cycle – events
Mon Tue Wed Thu Fri
Sprint Planning Daily Scrum Daily Scrum Daily Scrum Daily Scrum
Sprint N

Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum
Sprint Review
Sprint Retro
Sprint Planning Daily Scrum Daily Scrum Daily Scrum Daily Scrum
Sprint N + 1

Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum
Sprint Review
Sprint Retro
Sprint
• Container in which all the remaining 4 events take place.
• Sprints always run back-to-back i.e., no gaps in between Sprints.
“Time, tide and Sprints wait for none”
• Each Sprint must produce some value. The value need not be in production (when to release PO takes
final call, but Scrum Team should make sure that each Sprint they have something that is ready to be
used)
• Running dedicated Sprints like these is NOT Scrum
o Sprint 0 – project kickoff only for onboarding, requirement gathering, initial design,
architecture and infra setup, any procurements if required etc.
o Hardening Sprint – only for integration and testing

Created by Raju K ([email protected]) to complement Scrum.org trainings 6

 o Release Sprint – only for release
• Do not extend the Sprint beyond timebox.

Factors influencing Sprint Length

• Maximum duration of a Sprint is 1 month.
• The amount of risk acceptable to the Product Owner
• The team’s ability to produce an usable increment
• To be in sync with Business requirements (for ex: release schedules)

Sprint Planning
Participants Inputs Event Outputs

Scrum Team (all 1. Developers • PO shares WHY this • Sprint

Sprint Planning

3 roles) Capacity Sprint is valuable (PO can Backlog

mandatory 2. Ordered share Product Goal) (Backlog
product • WHAT - All 3 roles create items +
If needed, backlog Sprint Goal Tasks)
technical 3. Team’s past • HOW – ONLY Developers • Sprint Goal
architects, SMEs performance plan how to work (All 3 roles)
(Velocity or
throughput)
4. Improvement
items from
prev. Sprint
Retro
5. DoD
Sprint Goal
• A commitment towards Sprint Backlog
• It answers WHY the Sprint is valuable and WHAT the team is trying to achieve.
• Crafted by all 3 roles, doesn’t change during the Sprint
• If due to any reason, the team can’t meet the Goal:
o In Retro – the Scrum Team should analyze why they were not able to meet the goal
o What they can do to achieve it in next Sprint
• If the Goal becomes obsolete (useless) only PO can decide to cancel the Sprint.
o Ex: in one of a Project, the Scrum Team was trying to incorporate Bitcoin and Digital
currency payments into their e-commerce platform. During the Sprint, Local Government
banned the digital currency. Now this Sprint Goal is obsolete. PO decides to cancel the
Sprint and start a new one with a revised goal.

How to craft an effective Sprint goal:

• Sprint Goal doesn’t reflect all Sprint Backlog items – it should reflect the most important ones
selected for the Sprint that must be delivered. PO can use MoSCoW Prioritization (Must have, Should
have, Could have [nice to have], Won’t have [now, may be later])
• Sprint Goal must focus on functionality but not individual backlog items.
o Ex – bad Sprint Goals – In Sprint 5, deliver PBI# 89, 76, 54. Fix Defects# 8, 90. Instead of such
goal, arrive at this one – In Sprint 5, we deliver Chat Bot functionality for Service Request
module enabling self-service with AI and ML.
• Sprint Goal must be used during the Sprint:
o Daily Scrum – use to check if it can be achieved or not
o Sprint Review – check if it is met or not
o Sprint Retro – how to meet it if we have not met

Created by Raju K ([email protected]) to complement Scrum.org trainings 7

 • Sprint Goal – template https://www.romanpichler.com/blog/sprint-goal-template/

Daily Scrum
• For Developers to assess their progress towards Sprint Goal
• Plan for next 24 hours

Participants Inputs Event Outputs

ONLY for 1. Sprint • Developers assess • Updates to

Daily Scrum

Developers Backlog their progress towards Sprint

(updated, Sprint Goal Backlog
If SM and/PO transparent) • Earlier version of • Updates on
are also doing 2. Impediment’s Scrum Guide there Impediments
some tracker were 3 questions.
Development, 3. Sprint Goal • SM should ensure that
they can team has this event
attend. every day, it is
Otherwise, completed in 15
NO. minutes
• Any discussions, trying to find solutions for problems etc. should be done after
Daily Scrum – NOT during Daily Scrum.
• Daily Scrum is NOT a Status meeting.
• Allowing outsiders of team (Architect, Managers etc.) is an anti-pattern.
Doing effective Daily Scrum
• Do it in front of Sprint Backlog or Scrum Board
o Physical co-located team – they do in front of the Board or share the screen
o For virtual – do it with screen sharing or all Dev looking at their Backlog on their machines
• Keep it only for updates on Sprint Backlog items – no problem solving, no discussions etc. These can
be had after 15 minutes.
• Developers can look at the trend of Sprint Backlog items progress and discuss.

Created by Raju K ([email protected]) to complement Scrum.org trainings 8

 o Example – trend is shown in () with + or -. Example Illustration from a project

Names
are
masked

o Use CFD (Cumulative Flow Diagram)

• Daily Scrum without 3 questions: https://www.youtube.com/watch?v=VhOPIWmRU0g
• Another visualization for Daily Scrum: https://www.amazon.com/Visualization-Examples-Jimmy-
Janl%C3%A9n/dp/9188063011
• Work Item age – (flow – Kanban) metric tells you how many days these backlog items are with
teams. The longer it is, the longer team is spending time with them. In Daily Scrum, WIA can be used
to know which item they can focus today.

Sprint Review
• For Scrum Team and Stakeholders (invited by PO) to review the increment, arrive at what to do next

Participants Inputs Event Outputs

Scrum Team 1. Current • Stakeholders and • Updates to

Sprint Review

and Increment - Scrum Team (all 3 Product

Stakeholders. Deliverable roles) collaborate on Backlog
2. Market what was done and
Conditions by what to do next
PO
3. Customer
feedback by
PO
4. Latest
Product
Backlog
• Sprint Review is more than a Demo
• An event where outside team members can participate (Stakeholders are
invited by PO)
• PO can talk about market conditions, customer feedback, budget etc.

Created by Raju K ([email protected]) to complement Scrum.org trainings 9

 A Graphical way to look at Review: (Image courtesy: Scrum.org)

Example Agenda – 3-part meeting

Sprint Retrospective
• For the Scrum Team (ONLY all 3 roles) to evaluate how did they perform as a team in last Sprint

Participants Inputs Event Outputs

ONLY for 1. Current • All 3 roles to see how • Identified

Sprint Retro

Scrum Team process they can improve improvement

(3 roles) 2. Working • How they can do items for
agreements better in next Sprints future sprints
3. DoD
4. Sprint
Backlog and
Goal
• No one outside Scrum team is allowed here
• Several techniques exist to do Retro.

Created by Raju K ([email protected]) to complement Scrum.org trainings 10

 Handling incomplete Backlog Items in a Sprint
• First Developers re-estimate them for remaining work
• They are presented with PO – PO decides
o Whether to continue these incomplete items in next Sprint
 If yes, they are added to next Sprint Backlog (Spillover items)
o They are not of priority now, they can be completed later
 Added to Product Backlog

All events at a glance

• TIMEBOX shown here is for 1 month. For shorter Sprints, they are shorter.

Timebox
• Maximum amount of time an event can take place
• Do not exceed this time
• All event’s timebox is shown next

Artifacts
Product Backlog
• Contains complete scope i.e., requirements of the Product or Project
• Enhancements, Change Requests, Defects etc. can be part of Product Backlog
• Owned by PO, ordered by PO, anyone can add Product Backlog items (for Sprint Backlog, only
Developers can add)
• Items on top are high ordered when compared to lower-level items
• Items on the top should have enough details so Developers can work on them
• In traditional Project Management: BRD, SRS, Project Scope Statement of PMP®, Project Product
Description of PRINCE2® All are equal to Product Backlog

Created by Raju K ([email protected]) to complement Scrum.org trainings 11

 • Product Backlog evolves as we progress. There is no need to do complete Requirement gathering at
the beginning of the Project/Product Development itself in Scrum.

Sprint Backlog
• Selected Backlog Items (and may include Tasks) – a plan for Developers how to work in the Sprint
• Only Developers can add, move content – even PO, SM, Stakeholders etc. (for example even a CEO) –
approaches the Developers to add something into Sprint Backlog
• For scope changes during the Sprint, Developers will negotiate with PO

Increment
• Deliverable from Sprint which is well integrated with all earlier increments.

Created by Raju K ([email protected]) to complement Scrum.org trainings 12

 Product Backlog and Sprint Backlog comparison

WHAT – By Dev
How – by Dev ONLY
(Priority by PO)

Other elements
5 Scrum Values CCFOR
• Courage
• Commitment
• Focus
• Openness
• Respect
o All these are behaviors

3 Commitments
• Product Goal
• Sprint Goal
• Definition of Done

Initial Sprints for a Project as per Scrum Guide

• Initial Sprint – Scrum Team selects few backlog items that can help them to demonstrate usable value
i.e., increment along with working on necessary architecture and design
• In each Sprint, you should balance Value Delivery with Infrastructure etc. work

Handling architecture and Infra structure work in each Sprint

• XP (eXtreme Programming – another agile method) Practice of Spike – Developers dedicate some
time in Sprint (or more than one Sprint) to learn, experiment, demonstrate new technology or tool
etc.

Created by Raju K ([email protected]) to complement Scrum.org trainings 13

 o Example: your team wants to demonstrate Chatbot to customer. So, your team wants to
build a PoC or Prototype to show this. Team will dedicate some time each Sprint for this and work on
this. This is called Spike.
• You can create backlog items or Stories for all this architecture and infra work. Scaled Agile calls these
as Enablers:

• Refer: https://www.scaledagileframework.com/story/

Handling Architecture and Infrastructure in Scrum

• Unlike Non-Scrum, Architecture is not finalized before Sprints
• In Scrum, as per theory, Architecture evolves along
with the product
o So, start with just-enough architecture to
support the increment in 1st Sprint
o Gradually scale and add more architectural
components

But in each Sprint, you must deliver some value

Created by Raju K ([email protected]) to complement Scrum.org trainings 14

 Definition of Done
• Generic for all backlog items part of Increment

Creating the Definition of Done

• Product Development (Projects) are typically executed between two parties (a customer and a
supplier/vendor). The Supplier/Vendor (may be called as Development Organization) may provide
initial DoD that can be derived from its contract with Customer and/or any other practices (for ex: ISO
Standards that the vendor follows) that are practiced
o For example, imagine “BlahCustomer” is a company that produces some Products. They have a
requirement for a new Product “NewBlah”. This Product will be developed by the company
“VenSupp”.
o “VenSupp” may define initial DoD for this Product Development based on its contractual
requirements with “BlahCustomer”
• If the Development Organization doesn’t provide one, Scrum Team creates DoD. This is very
important and please remember. Scrum Team creates the DoD – i.e. all 3 Accountabilities SM, PO and
Dev together create the DoD.

Updating the Definition of Done

• Scrum Team can update their DoD as they progress in their Product Development.
• Typically this is done in Sprint Retrospective.

Acceptance Criteria and DoD Difference: One example –

• You want to recruit a JAVA Developer for your project.
o Acceptance criteria (for this particular position) – role specific for ex: Must have 6+ years exp
in Java, expert in ReactJS Framework etc.
o Definition of Done (all employees in Your Company) – BG Verification, Induction ceremony,
submission of documents, reference checks etc.

Product Backlog Refinement

• Activity to arrive at Backlog items with enough details for upcoming Sprints
• Spend some time in current Sprint, adding details (for ex: Finalizing Screen, Finalizing Business Logic,
arriving at Database Table structure etc.) for backlog items that may be picked up in upcoming Sprint

Created by Raju K ([email protected]) to complement Scrum.org trainings 15

 • Add these to Backlog Items – DOVE

• One example Sprit with Backlog Refinement – 2-week Sprint

Week Mon Tue Wed Thu Fri

1 Sprint Planning Daily Scrum Daily Scrum Daily Scrum Daily Scrum
Backlog
refinement
2 Daily Scrum Daily Scrum Daily Scrum Daily Scrum Daily Scrum
Backlog
refinement
• Example 1:
o Backlog refinement for Order Management module – on Tuesday,
Backlog Refinement for Service Request module – on Fridays etc.
• Example 2: for a global application
o Backlog refinement for North America region – Tuesday
o Backlog Refinement for EU Region – Wednesday
o Backlog Refinement for APAC Region – Friday

Handling Nonfunctional requirements in Scrum

• NFR’s are capabilities of the system – scalability, reliability, performance, security, availability etc.
• To handle them there are 2 approaches:
o Approach 1:
 Create Backlog items for each NFR, Add them to Product Backlog (in consultation
with PO)
 In each Sprint take some NFRs and deliver
o Approach 2:
 If the NFRs impact several or all backlog items (ex: Security, encryption, page load
times etc.) DoD can contain NFRs

Created by Raju K ([email protected]) to complement Scrum.org trainings 16

 Scrum Teams – Formation
• Important factors to consider when creating Scrum Teams:
o Ensure that all teams are cross functional i.e., as a team they have all skills required to
produce the Increment in each Sprint
o Minimize dependencies

Feature Team
• Team will have all the skills required to deliver Business
functionality

• Value will be delivered quickly

• Difficult to form

Component Team
• Team created on technical skillset
• Dedicated in working one technical layer
• For example:
o DBA Team
o React JS Team

• Easy to form
• You might need extra time for integration so
value will be delivered late.

• You can have a mix of feature and component

teams as per your project needs

• Team members decide to which team they belong.

No management or HR assigns team members

Impact on Productivity and Velocity when team composition changes

• Situation – two new members are added to Scrum team
• Productivity and velocity will initially decrease due to KT involved, later they will increase

Team health check: https://engineering.atspotify.com/2014/09/16/squad-health-check-model/

Created by Raju K ([email protected]) to complement Scrum.org trainings 17