0% found this document useful (0 votes)
7 views

Scrum Mindmap v 1.2

The document outlines the roles and responsibilities of the Product Owner (PO) and the Development Team (DT) within a Scrum framework, emphasizing the importance of managing the Product Backlog and engaging stakeholders. It highlights the need for clear accountabilities, the significance of Scrum values, and the process of backlog refinement to ensure effective Sprint planning and delivery of a potentially releasable increment. Additionally, it discusses the implications of technical debt on velocity and value delivery, and the importance of maintaining transparency and collaboration within the Scrum Team.

Uploaded by

devashishc
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

Scrum Mindmap v 1.2

The document outlines the roles and responsibilities of the Product Owner (PO) and the Development Team (DT) within a Scrum framework, emphasizing the importance of managing the Product Backlog and engaging stakeholders. It highlights the need for clear accountabilities, the significance of Scrum values, and the process of backlog refinement to ensure effective Sprint planning and delivery of a potentially releasable increment. Additionally, it discusses the implications of technical debt on velocity and value delivery, and the importance of maintaining transparency and collaboration within the Scrum Team.

Uploaded by

devashishc
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Maximizing value delivered

Accountabilities
Managing Product Backlog

Ordering of Product Backlog items

This can be delegated, but PO remains Any one can create Backlog items,
Managing the Product Backlog accountable on Product Backlog But ONLY PO orders it

Works with them on their requirements, but will have a final say on Ordering of Backlog items

Invites Stakeholders for Sprint Review and collaboratively inspects the Increment with Scrum Team
Engages Stakeholders
If any Stakeholder or Manager wants to know Project progress, Product roadmap etc. they should
contact the PO first
Responsibilities
Comes up with Product Vision
Product Owner
Shares regular updates on Market conditions, Budget, customer feedback to Development Team

Seeks help from Scrum Master on Backlog ordering, managing the Backlog etc.

ONLY AUTHORITY to decide to cancel the


Sprint if Sprint Goal becomes obsolete May consider Dev Team inputs while doing this

Ensuring that Backlog Items are defined with


required clarity

Watch out for multiple POs for one team - as


PO should be one person, not a committee per Scrum Guide, that is NOT SCRUM

We should not have Proxies,- they are not empowered fully to take
decisions, so time will be wasted waiting for actual PO to take final
Proxy PO is an ANTI SCRUM Pattern call
Important things to note
One PO can support multiple teams on different projects as well
BUT keep in mind that for each team PO should be available when This can be also called as committed to the
they need PO's support, PO should participate in respective events - team when they need PO
Courage Availability Sprint Planning, Sprint Review and Retro, Backlog Refinement
I.e. not dedicated ONLY to ONE team
Commitment
This doesnt mean each member should have all
Focus There are 5 of them What are they Cross functional as a team skills. As a team, they should have all skills

Openness No one tells them how to work, they decide it Task assignment by some one (or Manager) is
themselves not SCRUM
Respect
PO can't force them to select
They will select Backlog Items for the Sprint
When Scrum Team exhibits behaviours related to Scrum Values, Empiricism
related to Sprint Goal
flourishes and Trust is created between Scrum Team members Why they are important? Self-organizing If Stakeholder approaches them directly, they
Any other Stakeholder also can't force them should direct the Stakeholder to PO
Scrum Values are behaviours to be exhibited by Scrum Team members while
working with Scrum. They should try to solve their problems and If these are beyond their capabilities, then they
How to use Scrum Values? conflicts on their own. should appraoch SM
Scrum Team should live by these values and practice them
Producing the Potentially releasable
Sprint Goal - DT Commits to deliver it Accountability Done Increment with required quality

Clear accountabilities for each role - Commitment to value For this they will look at their past performance
Commitment Scrum Values They will decide on Number of backlog items i.e. Velocity and forecasted capacity for the
Inspect and Adapt opportunities provided by each Event - Scrum Team Selecting backlog items for the Sprint to work in the Sprint Sprint
commits to deliver a releasable Done Increment in each Sprint
Watch out for the situation like this one: Your DT has to create
Sprint Goal - focus on delivering coherant functionality in the Sprint Technical Documentation. They don't have Technical writing skills.
Self-organizing towards converting these For example - they will create necessary So who will create Technical Documentation? DT has to create it.
Timeboxes - participants focus on the expected outcomes backlog items into Releasable Done increment documentation etc. NOT OUTSIDERS.
Focus
Ordered Product Backlog - what to focus next They will do estimates of Backlog items No body else will estimate on their behalf Even Managers will not estimate on their behalf
Responsibilities
Sprint Backlog - helps the DT to focus on how to produce the Working with PO and other stakeholders if they This can be done anytime and as required
releasable Done Increment in each Sprint need clarifications on Backlog items during the Sprint

During Daily Scrum, DT Members openly inspecting their progress Which Scrum Elements help which Scrum Initially this may be provided by Development
towards achievement of Sprint Goal Values? Organization
Openness Development Team
In Sprint Review, Scrum Team collaborating with Stakeholders They will create the Definition of Done
DT may discuss Definition of Done with PO for
openly on inspecting the Increment better clarity and understanding, transparency

Timeboxes create respect for the event and its expected outcome Less than 3 - they may not have required skill

Respect for each role's clear accountability and decisions made by that role Respect Small size 3 to 9 members
More than 9 - lot of co-ordination effort
required
Self-organization and cross-functionality creates Respect to other team members
Roles like Testers, Front End developers, DBAs, System
Empiricism provides opportunties to inspect and adapt, be courageous in exploring No titles Admins etc. all are called Dev Team members
various ways to reach the Sprint Goal, deliver a releasable Done Increment in each Roles
Sprint 1. They should make it transparent to PO
Courage
Retrospective is a courageous attempt by the Scrum Team to inspect itself and adapt 2. In each Sprint they dedicate some time to learn along with delivering value
for improvements Skills If the Dev Team doesn't have necessary skills
3. They seek help from someone who has that This skilled person can work with team as a consultant
skill
An activity carried out by Scrum Team Other team members pair up and learn from this skilled person
What is it?
Not a prescribed event like Sprint Planning The Developers themselves will decide how they can form
teams. NO ONE ASSIGNS TEAM MEMBERS TO TEAMS.
For example - there are 100 developers. How
PO, DT (and Stakeholders when needed) collaborate on Backlog Items you can form Scrum Teams?
by adding Description, Order, Value and Estimates What is done in this? They should consider the skills required to produce an integrated
releasable done increment in each Sprint (in a multi-team scenario)
It helps the Scrum Team to collaborate on making Backlog Items Team formation
ready for upcoming Sprint Then initially productivity will come down
Backlog Refinement (there could be KT, synchronization etc.)
It promotes transparency, helps in an effective Sprint Planning Why it is needed? When team composition changes For example a new team is added
Velocity also might be lower than current
It can be used to engage Stakeholders velocity (again due to KT, synchronization etc.)

Product Owner, Development Team Members, Stakeholders (when required) Who participates? Important things to note They will have ONE PO and ONE Product
Backlog
Not more then 10% time of Developement Team How much time it takes?
They will decide which team will work on which
An objective to be met in the Sprint Backlog item - again NO ONE ASSIGNS Additionally, these teams may go for Scrum of Scrums type event to keep all of them in Sync

Provides guidance to Development Team on why they are building the This is not SCRUM - as there is no value
Important: All teams must produce an Watch out for the scenario: Each team has its
Increment What is it? Multiple teams working on same Project delivered in the Sprint
INTEGRATED RELEASABLE INCREMENT in each own code branch and shows their increment
Sprint that is not integrated
It gives flexibility to Development Team on selection of related Each Sprint must produce an integrated
Backlog Items during Sprint Planning and Sprint releasable done increment

Scrum Team Who creates it? One of their main focus should be on how they
can minimize dependencies
Sprint Planning In which Event it is created?
Accountability How Scrum is followed and enacted
Throughout the Sprint
Sprint Goal Facilitating Scrum Events as requested or needed
By DT in Daily Scrum
In which Events it is Inspected? Helping everyone in the Scrum Team (and Stakeholders if necessary) to
Sprint Review understand how Scrum works
Responsibilities

Sprint Retrospective Removing Impediments that are beyond Development Team's capabilities

It helps to create Focus, Commitment What is its relation with Scrum Values? Coaching the DT on Self organization

ONLY PO can decide to cancel the Sprint if Sprint Servant Leadership means SM serves the DT+ PO+Organization and also leads in
Goal becomes obsolete. What is its role in cancellation of Sprint? Servant Leadership Scrum adaption i.e. how Scrum is used

Amount of functionality delivered in a Sprint What is it? SM should coach the PO (for Product Backlog), DT (for Sprint Backlog),
all Scrum Team (for Increment) on how to make the artifacts
For each Backlog Item, a relative sizing transparent
If artifacts are not at required level of
numeric (for ex: Story Points) are given
Artifact transparency SM is responsible for Artifact transparency transparency:
SM can teach, introduce methods/ways in
When the Backlog Item meets the Definion of How it is calculated? which artifacts can become more transparent
Done and has no work left, its Story Points are
added towards Velocity In such situations care must be taken that SM is
One SM - One team or multiple teams SM can be the SM for multiple teams available as per the team's needs
Their Story Points will not be counted towards
Velocity Scrum Guide doesn't prohibit this
What will happen to Backlog Items that are not
completed?
They will be re-estimated and added to SM playing PO and/or DT Role As soon as possible, get dedicated people to
Product Backlog for re-prioritization But if it is for Short term, may be OK play dedicated PO, DT roles
Important things to note
SM can play these roles
It is used by DT to forecast the number of Conflict of interest (on role) and
Scrum Master
Backlog items they can select in Sprint Planning accountabilities may cause issues
Velocity
It can be used by PO to arrive at when possibly Ask PO to check with DT directly
a feature or functionality can be delivered How it is used? PO approaching SM not happy about team's
Look at artifact's for transparency If not at required transparency, then
progress
It can be used by PO to arrive at what
functionality can be delivered in a release In the Retrospect, encourage team to see why such situation occured and
what can be done to avoid it in the future
No.
It is a reliable metric? Direct the Manager to PO (progress towards
It is useful only at Team level Vision, Product Roadmap etc)

As more is discovered about work to do, the Velocity may change Direct the Manager to check artifacts If they are not at required transparency, then
Manager approaching asking about progress
People approaching SM
As the team runs into Technical Debt, Velocity initially may increase, towards Product etc. If complimentary practice like Burndown chart
but later decreases are used, direct the Manager to these

The Story points can be inflated (for ex: for a smaller item instead of Check with Team if this Manager can be invited
2, 5 was quoted) creating illusion of higher value delivery to Sprint Review
What can cause Velocity to be unreliable? Other elements
Team composition changes can also cause Velocity to become SM should coach them on a) how Velocity is
unreliable due to required Knowledge acquisition, skill sets etc. team specific b) how it can be unreliable
Management is asking about increase in
Velocity
When a new team is added, initially Velocity would decrease due to SM can introduce better metrics like Customer Satisfaction Survey, Time
required Knowledge Acquisition. Productivity also may decrease to Market i.e. encouraging them to focus on Value delivery
initally. Later both may increase
Scrum Master is responsible for the way Scrum is understood and enacted within the organization
As per Wikipedia - " the implied cost of additional rework caused by choosing an easy While performing these, SM may act like a
(limited) solution now instead of using a better approach that would take longer" What is it? Manager (remember SM is not a Management Scrum Master is responsible for managing the Scrum Process
SM as a Manager position or Role)
Environments not in Sync Managing the team's health and culture

Poor architecture Managing the boundaries for self-organization

Duplicate code
4 formal events for Inspect and Adapt: Sprint Planning, Daily Scrum,
Legacy or Complex code
Acts as a container for all other events Sprint Review and Sprint Retrospect
What can cause Tech Debt?
Purpose
Lack of Proper documentation

Logic in wrong places


20
Each Sprint should produce a releasable Done Increment

Scrum Team
Participants
Lot of manual processes, testing
Stakeholders
Unreadable code
Timebox 1 calendar month maximum
Its relation with Velocity
Product Backlog, Current Increment, Current impediments, Budgets, Market conditions, Customer feedback,
Technical Debt
Inputs Team's improvement items etc.
Increment will not be transparent
Outputs Releasable done increment
Value delivered will be less Sprint
Its relation with Increment
Value delivered
There could be increase in maintenance costs
Few assumptions and decisions taken during the Sprint may be
New feature developement may take more time Outcomes
validated by customer feedback and usage of Increment
Code coverage
Possible Return on Investment
Cyclomatic complexity Few metrics like these can be used How to measure it?
Sprints always run back to back There should not be any gaps between Sprints
SQALE rating
Hardening Sprints - dedicated Sprints run only to integrate work done in previous Sprints
There is no concepts of
First declare it to create Transparency
Important things to note Sprint 0 - dedicated Sprint run at the start of the project for requirement gathering, design etc.
Analyze and create Backlog Items to track them
Short enough so that business risk is acceptable to the PO.
In each Sprint, dedicate some time to fix Tech How to handle it? Scrum Considerations for Sprint Length Short enough so that work can be synchronized with other business events.
Debt along with delivering value
Not more than one month
Introduce few engineering practices such as
Refactoring, TDD, BDD, Automation testing etc.
20

Purpose The Scrum Team collaboratively plans the work to be performed in the Sprint
Each team has all skills to turn Product Backlog into
Scrum Team
releasable Increments
Participants
SMEs, Technical architects etc. can be invited if required
They will do Vertical slicing; work is divided by end-user
functionality
8 hours for 1 month Sprint
Timebox
Work is integrated continuously within each Sprint
Shorter for shorter Sprints
Feature Teams
Value is delivered faster
Ordered Product Backlog, Team's past performance (for ex: Velocity), Team's current Capacity,
Pros:
Inputs One improvement item from Retro, current impediments
There is more transparency
Outputs Sprint Backlog, Sprint Goal
Difficult to build with cross functional skills and required domain knowledge
Cons:
Outcomes Scrum Team having clarity about what they will deliver during the Sprint and how to deliver
Longer learning curve when team composition changes Scrum Team formations
PO presents an ordered Product Backlog, discusses the objectives for the Sprint
Teams organized for technical layers or technical components
Dev Team forecasts the functionality that can be developed in the Sprint
They will do Horizontal slicing; work is divided by technical layer for ex: Database,
Part 1: What can be done in the Sprint
Business Logic, Front End etc.
Scrum Team collaboratively crafts a Sprint Goal
Easy to form Component Teams
Only Dev team can decide on number of PBIs it selects for the Sprint
Pros: What happens in the Event
Team composition changes will have lesser impact
Dev Team creates a Sprint Backlog with selected backlog items and a
plan to deliver them
Value delivery may be delayed (as some integration is required
to deliver working functionality) Cons: Part 2: How will the chosen work get done
Dev Team decides how they will build the done increment from
Sprint Planning selected backlog items

Framework (not process or method) What is Inspected? Product Backlog

Any industry and any domain projects Can be used for Sprint Backlog (Artifact)
What is Adapted? Sprint Goal (non artifact)
Iterative and incremental delivery
Sprint Backlog creates Transparency about what functionality will be delivered in the Sprint
Used for complex product development Transparency
Generic and common Sprint Goal creates Transparency about coherent functionality that will be delivered towards larger Product Roadmap
Taking decisions on what is known
a,

No, Every Sprint starts with Sprint Planning


Knowledge comes from experience
If we skip, we lose an opportunity to inspect and adapt
Common understanding Can we skip this event?
Based on Empiricism
Transparency If Sprint Goal is not there, team would lose focus and commitment
Mainly related to Artifacts towards value delivery

Frequent inspection of artifacts for identifying Team can spend about 10% of their time in the previous Sprint - doing Backlog Refinement - by
deviations Inspection 3 Pillars How to get Backlog items in Ready state for adding Details, Order, Value and Estimate to Backlog Items for upcoming Sprint
Sprint Planning?
Please note: when deviation is detected, act as There is no concept of Definition of Ready (as per Scrum.org)
soon as possible, DO NOT WAIT TILL Adjustments made to minimize deviations as
RETROSPECT soon as they are detected Adaptation First help the team to arrive at Sprint Goal

DT selects few related Backlog Items and


Almost all time is wasted, no agreement
A Placeholder i.e. Single Source for all of the Product's requirements creates Sprint Backlog
reached on Backlog Items, Arguments between
Stakeholders and PO, Product Managers and
It is dynamic and it evolves as the Product Development progresses What is it? Important things to note Do not extend the event beyond timebox
PO etc.

It contains Ordered Backlog Items Later, in Retro, discuss why this happened and
how to prevent it in future
Functional Requirements
Encourage team to practice Backlog
bi

Features Refinement in current Sprint for future Sprint

Non functional Requirements Nothing to worry


Sprint Goal is arrived at, Sprint Backlog is NOT
Product Enhancements and Change Requests Sprint Backlog evolves as we progress
fully arrived at

Bugs/Defects When Timebox expires, stop Sprint Planning


and start Sprint
Backlog Items
Description
Situations Encourage team to practice Backlog
Order Refinement in current Sprint for future Sprint
Attributes of Backlog Items
Value Lot of time is wasted in creating, discussing Later, in Retro, discuss why this happened and
Backlog Items in Sprint Planning, Time is not how to prevent it in future
Estimate sufficient
Do not extend the event beyond timebox
Anyone can create a Backlog Item
Who creates Backlog Items? When Timebox expires, stop Sprint Planning
What are its contents?
But only PO can order them and start Sprint

They are one way to represent Backlog Items Loss of focus, commitment
Impact:
DT's ability to inspect the progress and adapt is
Xe

They are not mandatory for Scrum (as per Scrum Guide) What are User Stories
lost
Sprint Goal is not crafted at all
Team can use which ever they are comfortable to capture Backlog Items
Coach the team on how to craft effective
They can be part of Product Backlog What to do: Sprint Goals
What about Use Cases?
A bigger Use Case can be broken down into smaller Backlog Items For Dev Team to inspect the progress towards Sprint Goal and adapt
Purpose itself towards remaining work for next 24 hours
Accountability lies with PO
Product Owner Who owns it? If others (like PO, SM, Manager etc.) want to
Management can be delegated by PO attend, they should be silent observers and not After the event, they can interact with DT as
Participants Only Dev Team interrupt DT needed
ONLY Product Owner Who orders it? Product Backlog
Maximum 15 minutes
Based on Size Timebox (irrespective of Sprint Length)

For ex: Return on Investment, New Business it Sprint Goal, Sprint Backlog, Definition of Done,
may bring in, Cost of Delay Based on Value Inputs current impediments

Based on Risk Outputs Updates to Sprint Backlog


What are they ways in which it can be ordered?
Business Value Poker DT's collective understanding on how they would meet the Sprint Goal and
Outcomes what they are going to do for next 24 hours
http://www.innovationgames.com/buy-a-feature/  Buy a Feature from Innovation Games
They may use some set of questions
http://www.innovationgames.com/2020-vision/  20/20 Ordering from Innovation Games Few techniques
This can be done by looking at Tasks for Backlog Items and assessing whether
DT inspects their progress towards
http://tastycupcakes.org/2012/10/thirty-five/  Thirty Five They may use their own ways which works for they can be completed or not, what support is needed to compelte them +
What happens in the event? achievement of Sprint Goal
them meet Sprint Goal, what are impediments
http://www.liberatingstructures.com/14-min-specs/  Min Specs Liberating Structures
The event happens at same place and same
During the Sprint Daily Scrum time To reduce complexity

Sprint Planning Sprint Backlog (Artifact)


In which Events it is Inspected? What is Inspected? Sprint Goal, DoD, Current Impediments
Sprint Review
What is Adapted? Sprint Backlog (it gets updated)
Backlog Refinement activity
When Sprint Backlog is updated with adaptations from Daily Scrum, common
During the Sprint Transparency understanding is created for DT (and Scrum Team)

Sprint Planning If we skip, DT loses an opportunity to inspect and adapt


In which Events it is Adapted? Can we skip this event?
Events
©

Sprint Review Progress towards achievement of Sprint Goal will not be transparent

Backlog Refinement activity If we skip, DT loses an opportunity to inspect and adapt


Can we do this event once in two or three days
High ordered items have more details and are on top than low ordered items instead of every day? Progress towards achievement of Sprint Goal will not be transparent

It is frequently adapted i.e. updated to reflect new Business requirements, changes, customer feedback etc. Impediments may take longer to be identified and resolved

Backlog Items have attributes (Description, Order, Value and Estimate) clearly and well defined Daily Scrum is not for discussions, So these should be avoided
How it can be made Transparent?
Discussions are happenning during the event
PO regularly discusses these with the DT SM can coach on purpose of the event, help DT
and timebox is exceeding
on how to effectively Daily Scrum
Team utilizing Backlog Refinement to have conversations, add details to Backlog Items
Important things to note
Timebox must be respected. When 15 minutes over, event should stop
It is available and visible for Scrum Team and relevant Stakeholders
PO and/or Stakeholders may not know what is
A Placeholder for selected Backlog Items for the Sprint and a Plan to deliver them happenning - resulting in less trust with DT
What is it?
It is dynamic and evolves as the Sprint progresses Impact:
Progress towards achievement of Sprint Goal
DT members are not updating Sprint Backlog will not be transparent
Selected Backlog Items for the Sprint regularly - thinking its waste of time
SM should coach the team on how timely adaptations to Sprint
It changes as more work is discovered during the Sprint A Forecast What to do: Backlog would be beneficial to both themselves and others

DT negotiates with PO throughout the Sprint as needed when Scope changes Called as Forecast because SM can coach the entire team on Scrum Values - Openness and
What are its contents? Some DT Members not opening up and sharing Respect. Provide some pointers to DT on how effectively every
It gives Flexibility in connection with Sprint Goal's achievement
Artifacts their impediments, task progress honestly DT member can participate

The Tasks and Estimates are done by Development Team members ONLY Scrum team and stakeholders collaborate on what was done during the Sprint and arrive at
Backlog Items are broken into Tasks A Plan Purpose next things that could be done to optimize value
No one assigns these Tasks to Development Team members
Scrum Team
Development Team ONLY Who owns it? Participants
Stakeholders invited by PO
Development Team ONLY Who orders it?
Sprint Backlog 4 hours per 1 month Sprint
During the Sprint Timebox
Shorter for shorter Sprints
During Daily Scrum
In which Events it is Inspected? Latest Increment, Product Backlog, Sprint Backlog
Sprint Review Inputs
Defects, Customer Feedback, Budgets, Market Conditions
Sprint Retrospective
Outputs Adapted Product Backlog
Throughout the Sprint
Scrum Team and Stakeholders getting insights on value delivered and more importantly what
During Daily Scrum In which Events it is Adapted? next can be done to optimize value

Sprint Retrospective (** for NEXT Sprint's Backlog) Outcomes Scrum Team and Stakeholders getting a fair idea on are they delivering right value as expected or not

Selected Backlog Items are broken down into Tasks Some assumptions that went into building the increment may be validated

Frequently updated as more work is discovered during the Sprint The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”

DT using it in Daily Scrum to inspect their progress towards achievement of Sprint Goal How it can be made Transparent? The Development Team discusses what went well during the Sprint, what problems it ran into, and how those
problems were solved
Using Backlog Item's attributes - Description, Order, Value and Estimate
The Development Team demonstrates the work that it has “Done” and answers questions about the Increment
DT regularly updating Tasks and Backlog Items with their latest Status
The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of
based on progress to date (if needed)
all previous Sprints What happens in the event? From Scrum Guide
What is it? Sprint Review
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent
Its a step towards realizatoin of Sprint Goal and Product Vision
Sprint Planning
Sum of all Product Backlog Items completed during the Sprint and all previous Sprints What are its contents?
Review of how the marketplace or potential use of the product might have changed what is the most valuable thing
to do next
The Scrum Team
Who owns it?
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of
Accountability of producing a releasable Done Increment lies with Development Team
functionality or capability of the product
The Increment i.e. the Backlog Items meet Scrum Team's Definition of Done
Latest Product Increment, Product Backlog, Sprint Backlog (Artifacts)
What is Inspected?
There is no pending work on the increment What is meant by "Done"?
Defects, Customer Feedback, Budgets, Market Conditions
It is in a releasable state i.e. usable state
What is Adapted? Product Backlog (updated with Review decisions, findings, customer feedback reactions etc.)
PO ONLY Who decides to release it?
When Product Backlog is updated with adaptations from Sprint Review, Scrum Team and Stakeholders will get a
Transparency common understanding on what will/may be done next
NO. Its PO's call when to release it Is it that it must be released in each Sprint?
No. Sprint Review is more than a demo
NO. It can be ready in a potentially releasable state anytime during the Sprint Is it that it must be ready by end of Sprint ONLY?
Increment Is Sprint Review a Demo? Its an opportunity to discuss about customer feedback, current market conditions, budgets etc.
Sprint Planning
What should be done next is also discussed and arrived at
During the Sprint
Each event is an opportunity for inspect and adapt
Daily Scrum In which Events it is Inspected?
Impact:
Misisng this event, Scrum Team loses the opportuntiy to inspect Customer Feedback
Sprint Review
and decide on what best to do next
Team has not developed an Increment.
Sprint Retrospect Can they skip this event?
SM can coach on purpose of the event, help Scrum Team on how to effectively
During the Sprint do Sprint Review, faciliate as required
In which Events it is Adapted? Important things to note What to do:
Sprint Review In subsequent Retro, team should discuss why they were not able to develop the
Increment and how to avoid it in the future DT may revise their current Definition of Done if required
By using a Definiton of Done
Is it that Increment should be ready by Sprint
When it is in a releasable i.e. usable state Review? No, Increment can be build iteratively during the Sprint - anytime before the Sprint Review

When it is collaboratively inspected by Scrum Team and Stakeholders in Sprint Review An opportunity to inspect and adapt is lost.
Impact:
How it can be made Transparent? An interaction with Stakeholders and opportuntiy to inspect customer feedback may be lost
When it is NOT impacted by Tech Debt
PO is not available, Can the team skip doing If this is one off incident, do the Review without PO
When there are no show-stopper kind of
the Review?
defects
Ensure that PO is having time commitments
In a multi-team scenario - it is fully integrated with all the team's work (in this Sprint and all previous Sprints) towards Scrum Events Coach the PO on these if required
What to do:
If it becomes a regular affair, then see what help is needed for PO to get time to attend the event. Treat this
as impediment and seek Management/Leadership support

This would create delays in decisions to be


Do not encourage Proxies to stand for PO taken

Purpose For the Scrum Team to inspect how the last Sprint went and arrive at improvements if any

Participants Scrum Team

3 hours per 1 month Sprint


Timebox
Shorter for shorter Sprints

Sprint Backlog (Artifact)

Inputs People, Process, Relationships, Tools Team Working agreements

Definition of Done

One of these will goto NEXT Sprint's Backlog

Team's may use a Improvement or Action Items tracker (eg: a shared Spread Sheet, Trello board etc.)
Outputs Improvement Items
Team's Working Agreements may be updated

Definition of Done may be revised

Scrum Team coming to an understanding on how they are performing as a team, are they able to meet their Sprint Goal,
are they able to deliver Value, how they can improve their processes etc., what is blocking or constraining them and
Outcomes how to overcome these

Teams may use their own techniques on looking at how the last Sprint went

What happens in the event? 1. What went well

One example - Team members openly sharing: 2. What did not go as expected
Sprint Retrospective
3. What could be improved

Sprint Backlog of current Sprint (Artifact)


What is Inspected?
Team's Working Agreements, Definition of Done (non Artifacts)

Sprint Backlog of NEXT Sprint


What is Adapted?
In addition, Team may revise their Working Agreements, Definition of Done, Action Items (if they are using)

When an improvement item is added to NEXT Sprint's Backlog, there would be a common understanding on what is
the improvement Team would work in coming Sprint

If Working Agreements and/or Definition of Done are revised, Scrum Team would have a better understanding on
how they would be working in future Sprints, what additional work to be done to produce the Done Increment in
Transparency
future Sprints [if they revise DoD]

If the Team uses Action Items, the tracker may create a common understanding to Team members on what
improvements are required and what is their respective status

Even though there could be no improvement, Retro provides an


Team feels there is nothing to improve. opportunity to inspect how the last Sprint went and Adapt.
They want to skip the Retro
So Team should do the Retro

Not allowed

This may cause problems to Scrum Team on openly


People outside Scrum Team (like Managers)
discussing their processes and relationships
want to attend Retro
These Managers can check with PO (about Product
Important things to note
Roadmap, progress towards Backlog items), SM (on Scrum
Process etc.) after the Retro

SM should coach the Team on purpose of Retro


and faciliate it to meet its expected outcomes

During the Retro, two DT Members are arguing SM should coach the Team using Scrum
and finding fault with each other. Other Team Values (Respect, Courage etc.) so that Trust
Members are quiet and are not happy about this fosters between Team Members

SM can also identify if there is any conflict,


check if the Team can resolve on themselves
otherwise support the team on its resolution

You might also like