Scrum

Principles

Empirical Process Control

Transparency

collaboration & communication between the Scrum Team members

common standard for the aspects of the process that must be visible to those responsible for the outcome

observers must have a common understanding of what is being seen

e.g.

common language referring to the process shared by all participants

definition of "Done" shared by those who work & those who accept work

Artifacts

Product Backlog

Project Vision

Release Planning Schedule

Meetings

Daily Standups

Sprint Review

Information Radiators

shared Scrumboard

Sprint Burndown Chart

necessary to do Inspection

Inspection

continuous customer feedback

inspection of the Deliverables by the Product Owner

Scrum users frequently inspect

artifacts

progress toward Sprint Goal

Information Radiators

detect undesireable variances

doesn't get in the way of work

best when done by inspectors at the point of work

material for analysis during Adaptation

Adaptation

empirical process control

monitor the relative efficacy of management & development practices

development is too complex to rely on canned procedures

production vs development

adjust process or material being processed

if inspector determines aspects deviating outside acceptable limits & resulting product is unacceptable

adjustment must be made ASAP to avoid further deviation

iterative delivery

(potentially) shippable product each iteration

adapt product definition

next version of a complete product

no need to adjust scope because this iteration of the product is complete

just enough process to generate the transparency, inspection and adaptation cycle

Each event is formal opportunity to inspect & adapt

Get the cook in the kitchen

Empirical Process Control Theory or empiricism

Evidence Based Management

medical practice

Evidence Based Medicine

manage risk to patient health

suboptimal care

Lack of systematic sharing

transparency

feedback less valued

not using existing research and data

reliance on experts' assumptions

preferring personal beliefs & conventional wisdom to research

all knowledge intensive domains & complex activities

social care

criminal justice

education

systematic use of evidence outperforms expert-only judgement

Self-Organization

Team buy-in

autonomous organization of work

within boundaries

towards given goals

shared ownership

no separate test team

Scrum Team has all competencies to produce a releasable, Done product

own entire product as negotiated with the Customer

value based thinking, not role based thinking

Approve, Estimate & Commit User Stories

not directed from outside the Team

Scrum Team chooses how to best accomplish their work

management and specialist efforts are not separated

there is no such subset of the project team that is responsible for project management while others are only responsible for specialist activities

team buy-in

team needs pm skills, but not a pm

Innovative environment conducive to growth

no centralized Project Management

Project Management responsibilities are distributed among the 3 roles

Time-boxing

benefits

Predictability

timeboxing ensures inspection & adaptation of process

customer knows when feedback will be required

quantifies processes

e.g. Velocity

Limits cost

Contain risks and complexity

All events timeboxed

PERT compatible

Critical path always visible

Burn-down, etc.

Sprint duration is fixed & cannot change once Sprint started

reduce "waste in the process"?

a nod to Lean?

events end when purpose of event achieved

events

Sprint Review Meetings

Sprint Meetings

Standups

Sprints

Prescribed events

Cadence

designed to enable critical transparency and inspection

skipping events reduces transparency

minimize need for other meetings

create regularity

Collaboration

cooperation vs collaboration

cooperation is sum of everyone's work

collaboration is everyone contributes to each feature of the final product

colocation

high bandwidth communication

questions answered quickly

problems fixed on the spot

formal & informal communication

trust

benefits

continuous improvement

e.g. Scrum Master improves on the team based on the Sprint Retrospect

fast risk identification

fewer change requests

Core Dimensions

Awareness

aware of each other's work

Standup meetings are a collaboration tool

e.g. a team might shift resources to help a member

Bus number

Requires healthy communication

Articulation

Partition work into units, divide between members, & reintegrate it into a finished product

Appropriation

Adapt technology to serve custom ends

Value-based Prioritization

Maximum business value early

Iterative Development

Change Management

Product Owner's responsibilities

Scrum Cycle

Variations

Agile

Stakeholder Meeting

Study Project Business Case

Create Project Vision Statement

Product Owner creates Prioritized Product Backlog

prioritized list of business and project requirements

in the form of User Stories

Sprint

1 - 6 weeks

Create potentially shippable Deliverables or product increments

Sprint Planning Meeting (Iteration Meeting)

High priority User Stories considered for inclusion in Sprint Backlog

Daily Standup Meetings

short

highly focused

Sprint Review Meeting

Demo the Deliverables to Product Owner & relevant stakeholders

Product Owner accepts the Deliverables based on Acceptance Criteria (Done)

Retrospect Sprint Meeting

discuss how to improve process & performance

Standard Scrum

Sprint

Sprint Planning

< 8hrs for 1 month Sprints

answer

What increment of work can be delivered in the timebox of the Sprint?

How will the work needed to deliver the increment be achieved?

Why is the Dev Team building the increment?

Sprint Goal

participation

Scrum Master makes sure

event

happens

timeboxed

teach Scrum Team to timebox

attendants understand purpose

Dev Team

Forecast functionality that will be developed in the Sprint

the hypothesis

Assess what it can accomplish

select PBIs

Entire Scrum Team

crafts Sprint Goal

inspects work from the PBIs

designs the work into Sprint Backlog

Product Owner

discuss Sprint Goal (business objective)

PBIs that will achieve Sprint Goal

clarify requirements

make trade-offs

Dev Team

How to turn selected PBIs into a "Done" increment by the end of Sprint?

Renegotiate the PBIs with Product Owner

e.g. if too much work

Choose # of PBIs

select individual PBIs as well

estimate their own productivity

Invite other people to provide advice

Create Sprint Backlog

PBIs + plan how to "do" them

Design System and Work to convert PB into a working product

Receives sufficient data from the Scrum Team during Sprint Planning to forecast amount of work it can get "Done"

Self-organizes to undertake the work

e.g. individuals volunteer to do work

collective responsibility & ownership of work

Should be able to explain to PO & SM how it will self-organize to accomplish SG

First days decomposed into units of 1 day or less

inputs

Product Backlog

Scrum Team

Characteristics

Self-organized

Cross-functional

no need for outside assistance

team model optimizes

flexibility

creativity

productivity

3-9 members

Scaled Scrum for larger groups

holonic?

frequency depends on

inter-team dependency

size of project

level of complexity

Convene Scrum of Scrums

unofficial Scrum (Indian)

6-10 members

Regardless of how many sub-Scrums there are, there is only one Product Owner

only count people who execute PBIs

Scrum Master

facilitator

doesn't need to understand the architecture

clear impediments

more of a role than a position

still is a management position

manages the Scrum process, not the Scrum Team

usually leads the adoption of Scrum in organization

Artifacts

ensure complete transparency

Scrum Team & others

apply practices to cope w/incomplete transparency

continuously work to increase transparency of the Artifacts

to detect incomplete transparency

inspect artifacts

sense patterns

listen closely to communications

detect discrepancy in expected & factual results

servant-leader for
Scrum Team & organization

help Product Owner

Find techniques for effective Product Backlog management

Product planning in an empirical environment

Arrange PBIs to maximize value

Understand & practice agility

Communicating information

Facilitating related events

help Dev Team

self-organization & cross-functionality

create high value products

add to value by applying Scrum

remove impediments

coach Dev Team till Scrum fully adopted/understood

help Scrum Team

understand the need for clear & concise PBIs

facilitate Scrum events as requested/needed

help/work with Scrum team & the organization

increase transparency of artifacts

understand and practice agility

involves

learning

convincing

change management

help those outside the Scrum Team

change interactions to maximize value created by the Scrum Team

understand which interactions are helpful

preferable for same person not also be on Dev Team

can be on Dev Team

when executing items from the Sprint Backlog

Development Team

cross-functional

3-9 people

application area experts

do not change members during Sprint

joint accountability

people don't own assigned tasks

tasks are owned by the whole team

jointly accountable & responsible for the delivery of every task

self-organized

manage themselves

find their way instead of receiving orders

aligned with the goal of the project

can exercise decision making power in managing themselves because aligned w/SG

no specific titles

Specific titles are good for production environment. In development there are too many unknowns to overlook increases in responsiveness and agility afforded by increased communication and idea exchange that results from all team members sharing the same goal and responsibility.Role based configuration works in the military and in production. Wherever the labour is heuristic, as opposed to algorithmic, and creativity is a job requirement, value based mindset produces the most efficient teams. Value based thinking unites the team members in striving to add value to the product/business, to achieve a common goal.

e.g. designer/quality inspector/team leader

all members have the same role

equally responsible/determined to deliver product

value-based vs role-based thinking

different roles

promote different goals

segment focus

prevent value based approaches

no sub-teams

exclusively create

definition of "Done"

the Increment

estimates in the Product Backlog

work

deliver PBIs

manage Sprint Backlog

work in SB can be summed up at any time

refine Product Backlog

consume < 10% of capacity of Dev Team

on behalf of PO

manage itself

tracking Sprint Backlog at least every Daily Scrum

increments

always work in product-based way

systems, projects, etc. are all viewed as Product

full-time employment recommended

Product Owner is the only person who can tell the Dev Team what items to deliver

by placing them in the PB

Referred to in the unofficial (Indian) guide as "Scrum Team"

possibly because traditionally management is something done to teams, so the management positions are assumed to be outside the team

Product Owner

Achieve maximum business value for the Project

Maintain business justification for the project

Value-driven Delivery

Deliver value/results early

stakeholder confidence

Flexibility

Articulate customer requirements

Voice of the Customer

Receive requirements from the Customer

Track total remaining work

at least every Sprint Review

compare with amount of work remaining after previous Sprint

transparent to all stakeholders

velocity

One person

may represent a committee

doesn't need to understand the technology, just the business

not from the client

must be from the performing organization

can be on Dev Team

when executing items from the Sprint Backlog

Chief Product Visionary

can a consultant do that?

Product Marketplace Expert

Product Release Decision Maker

entire organization must respect the order of PBIs set by Product Owner

manage the Product Backlog

discussion

Reception of a product is often a matter of marketing.

Maintaining business justification

inward

features

outward

image

a favourable business perspective

engaging stakeholders

form of a sale

persuasion

adopt a new perspective

requires effort

Non-core Roles

Stakeholders

customers, users, sponsors

the project produces "the collaborative benefits" for the stakeholders

Vendors

Chief Product Owner

Multiple Scrum Teams

Only in the Indian Scrum, in regular Scrum there is only one Product Owner

Chief Scrum Master

Multiple Scrum Teams

Artifacts

Product Backlog

Responsibility & discretion of PO

content

availability

ordering

can make changes any time

business terms

Dev Team will translate into system terms during Sprint Planning & Refinement

dynamic

evolves with the product & environment

never complete

Refinement

ongoing process

review & revise items

Scrum Team decides when and how

acquire a degree of transparency

consume < 10% of capacity of Dev Team

Dev Team & PO

Dev Team responsible for all estimates

people who do the work do the estimates

PO can help to select trade-offs

Story Sizing

value points

It is a good practice, keeping in mind that market reception is the best measure of value.

Indications of value on Product Backlog are useful but are only a prediction until validated against users and market.

Relative Business Value

Prepare for upcoming Sprint

each item intended for next Sprint must be refined to the degree that it can be reasonably "Done" next Sprint

Items must be deemed "Ready"

Product Owner

Express Product Backlog Items clearly

Stakeholders & Scrum Team must easily understand

Order the PBIs to best achieve goals & missions

e.g. ROI or value

Optimize the value of the work performed by the Development Team

make Product Backlog

visible

transparent

understood

show what the Scrum Team will work on next

may delegate these tasks to Dev Team, but remain accountable/responsible

items

types

features

funcitons

requirements

enhancements

fixes

attributes/states

description

order

estimate

value

other

e.g. group items by the Scrum Team

"Ready"

agreed depth/level of description

between Dev Team & PO

order

higher items more clear & detailed

allows for more precise estimates

can be used by multiple Scrum Teams

Sprint Backlog

aka Release Backlog?

system terms vs business terms

is a forecast by Dev Team

functionality in next increment

solely owned by Dev Team

work needed to deliver functionality as "Done"

contains

PBIs selected for Sprint during Sprint Planning

SBIs for the first days of a new Sprint are decomposed to units of one day or less

plan to deliver the product increment

plan to realize Sprint Goal

items

detailed enough for changes to be understood in Daily Scrum

estimates of remaining work are continuously updated

work

remaining work can always be summed

track at least every Daily Scrum

emerges/crystallizes during Sprint

Adjusted by Dev Team as their understanding of what's needed to achieve Sprint Goal grows

Dev Team adds work to SB as required to achieve SG

highly visible, real-time picture of Dev Team's work

Only Dev Team can change Sprint Backlog

Increment

sum of all the "Done" PBIs for this AND all previous Sprints

must be in usable condition regardless of whether PO releases it

created by Dev Team only

everyone who does work on the Sprint Backlog Items

function

Artifacts are Work or Value that provide transparency/inspection/adaptation

requirements for empirical process control

Artifact Transparency

decisions made by Scrum Team

e.g.

optimize value

control risk

based on perceived state of artifacts

decision making power delegated to all members

distributed project management

Scrum Master

ensure complete transparency

apply practices to cope w/incomplete transparency

ensures informed decisions

lack of transparency

flawed decisions

increased risk

diminished value

decreased communication

decreased collaboration

Monitoring & Managing Progress

aspect of transparency & inspection

compare unfinished work at the end of Sprint with last Sprint

Velocity

Dev Team

track likelihood of achieving SG

every Standup

manages its progress

updates projections

projections

Burn-down

Burn-up

cumulative flow

do not replace empiricism

Cone of Uncertainty

more of a selling prop than a useful graph

available to all stakeholders

Benefits/Attributes

Adaptability

empirical process control

iterative delivery

Transparency

shared Scrumboard

Sprint Burndown Chart

Continuous Feedback

Daily Standup

Demonstrate & Validate Sprint processes

Continuous Improvement

Groom Prioritized Product Backlog

Continuous Delivery of Value

Ship Deliverables

Sustainable Pace

good scheduling allows to avoid surprises

Early Delivery of High Value

Prioritized Product Backlog

Efficient Development Process

timeboxing

Motivation

Daily Standup

Sprint Retrospect

Faster Problem Resolution

Collaboration and colocation of cross-functional teams

Effective Deliverables

Prioritized Product Backlog

Regular reviews after creating deliverables

Customer Centric

Business Value

Collaborative approach to stakeholders

High Trust Environment

Daily Standup

Retrospect Sprint

Collective Ownership

Approve, Estimate & Commit User Stories

High Velocity

Collaborative Framework makes most use of highly skilled cross-functional teams

Innovative Environment

Retrospect Sprint

Retrospect Project

Scrum Framework

history

"All-inclusive product development strategy where the development team works as a unit to reach a common goal"

"a holistic or 'rugby' approach where a team tries to go the distance as a unit, passing the ball back & forth"

not a sequential relay race, but a team that passes a ball back and forth trying to get to the end of the field

Predates Agile Manifesto 1996 vs 2001

difference from traditional PM

Estimates are done for the completion of features, not internal tasks

Do not fix scope when adapting - create a new (iteration of a) product

Principles instead of defined steps

just enough process to generate the transparency, inspection and adaptation cycle

No centralized Project Management

Project Management responsibilities are distributed among the 3 roles

Transparency imperative

Properties

projects any size

Cynefin

Chaotic Domain?

Scrum is a container for other techniques, methodologies & practices

product perspective

projects vs products

everything is a product

parts

Scrum Teams

Roles

Events

Artifacts

Rules

Complementary Practice

Product Owner's responsibility for Profit & Loss

associated empowerment

not part of Scrum Framework

Values

Commitment

Focus

Openness

Respect

Courage

act in the moment

change direction as needed

Quality

meeting the Acceptance Criteria aka the definition of "Done"

Continuous Improvement

transparency, inspection, adaptation cycles

update Product Backlog with new requirements

reflect changes in the external business environment

rapid response

Business Agility

communication with stakeholders

reduce gap between customer expectations & project deliverables

stakeholders make better decisions

Reveal defects

full lifecycle every Sprint

test & know all stages

same Team does all testing

value based thinking

we are delivering a product, not a task

Team has perspective & ownership of entire product to the Customer

how long to release

acceptance tests every iteration

Acceptance Test Driven Development

principles

make errors visible

transparency-->inspection-->adaptation

Change

Requirements Churn

stakeholders' needs always change during project

Impossible to define all requirements upfront

Manage with

short Sprints

regular interactions with the Customer (stakeholders)

portfolio/program management respond to Change Requests generated by Scrum Projects

Update requirements to reflect change

Expecting change allows to better manage risk

Risks

Opportunities

Threats

Manage

standardized steps

identify, evaluate, respond

probability & impact value

multiply 2 factors

probability of occurrence

impact of occurrence

disciplined implementation

the organization must be committed

rules of Scrum

flexible enough to apply to most organizations