Zen of Scrum

Agile Manifesto

 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

That is, while there is value in the items on the right, we value the items
on the left more.

Scrum Goals

 Deliver working (“potentially Work
shippable”) software frequently by
developing functioning software in
each iteration Transparency
 Favor customer collaboration by
encouraging customer involvement Inspect
throughout the project
 Respond to changing
requirements, even late in Adapt
development, by not planning
ahead in too much detail
 Avoid procrastination, or ”student’s “Scrum employs an
syndrome”, by working in small iterative, incremental approach to
increments optimize predictability and control
risk.”
- Scrum Guide

Scrum Values

 Courage  Commitment
 Respect  Openness
 Focus

Scrum Distilled

scrum team iterations events

Daily Scrum Daily
Scrum 24 hours Stand-Up
Master

Sprint
Sprint Planning
2-4 weeks
Team Sprint backlog

Sprint
Review

Product Release Sprint
Owner 2-6 months Retrospective

Product backlog Increment

Scrum Team

Product Scrum Team
Owner Master (Developers)

 Responsible for Product  Ensure Scrum is  Deliver potentially
Backlog (PBL) understood and enacted releasable increment of
 Ensure developers  Scrum coach “Done” product at the
understand PBL items  Removing impediments end of each Sprint
 Maximize ROI  Facilitate meetings  Self-organizing
 Cross-functional

“Scrum Teams deliver products
“…designed to optimize iteratively and
flexibility, creativity, and productivity.” incrementally, maximizing
- Scrum Guide opportunities for feedback.”
- Scrum Guide

Definition of Done

It is crucial to have the same definition of done in the Scrum
team, between teams, across the organization, and when
talking to other stakeholders and customers.
 Everybody must understand what “done” means
 Helps during estimation
 Ensures transparency
 Helps to avoid technical debt “As Scrum Teams mature, it is
expected that their Definition
of “Done” will expand to
include more stringent criteria
for higher quality.”
- Scrum Guide

http://www.flickr.com/photos/calypso/2767592937/

Planning and Estimation

Product Backlog

 Ordered list of everything that might be needed in the
product
 Single source of requirements
 Dynamic

“The Product Backlog is often ordered by
value, risk, priority, and necessity. Top-
ordered Product Backlog items drive
immediate development activities. The higher
the order, the more a Product Backlog item
has been considered, and the more consensus
exists regarding it and its value.”
- Scrum Guide

User Stories

Story XYZ 123

As a ...

I want to ...

So that I can ...

5 points

User Stories

INVEST in the user stories
 Independent – avoid dependencies on other stories
 Negotiable – stories are not a contract
 Valuable – show the value to customers/stakeholders
 Estimable – sufficient detail needs to be present
 Sized right – small enough to complete in one sprint
 Testable – Acceptance criteria should be apparent in story

Estimation Key Points

 It’s easier to estimate relatively than absolutely
 It’s difficult impossible to accurately estimate calendar time
 Firmly establish estimates by team commitment
 Separate the task of estimating size and duration
 Only re-estimate relative changes

Cone of Uncertainty

4x
estimation accuracy

2x

1x

0.5x

0.25x

Project evolvement

Story Points vs Ideal Days

 Ideal days are easily confused with calendar time, especially
when communicating outside the team
 My ideal day is not your ideal day
 Ideal days always have a relationship to calendar days. If the
project takes twice the ideal days in calendar time to
finish, it does not mean the team is 50% efficient
 If everything takes longer (or shorter, even though longer is
much more common :-P) you do not have to re-estimate;
this is more intuitive using story points

Estimating with Story Points

2
3
5

2
1

Story Points

Stories Epics

0 1 2 3 5 8 13 20 40 100

Story Points

XS S M L XL

Story Splitting

 Sometimes stories are too big for one sprint
 Story Splitting Patterns
 Boundaries: Operational, data, interfaces
 Remove cross-cutting concerns: Logging, Exception handling, ...
 Functional and non-functional aspects
 Business value

 Anti-Patterns
 When in doubt,
do a spike solution

http://www.flickr.com/photos/john_scone/493915787/

The Sprint

Sprint Planning

Agenda Participants
 Select user stories  Product Owner
 Identify and estimate  Scrum Master
technical tasks  Developers
 Come up with sprint goal

Two parts: (a) Selecting stories and (b) identifying tasks. The
PO and stakeholders only need to participate in the first
half, but must still be available during the second half.

Sprint Planning

1 hrs 2 hrs

Story 1 123

4 hrs 4 hrs

5 points 1 hrs 8 hrs

Product Backlog Grooming

Agenda Participants
 Update the product  Product Owner
backlog  Scrum Master
 Refine and split top stories  Developers
 Estimate stories

Sprint Rules

 No changes affecting the Sprint goal
 No changes to team
 Scope may be discussed, re-negotiated and clarified
as knowledge is gained

Sprint Emergency Procedure

Three questions to ask before canceling a sprint:

1. Can anything be changed in
the way work is done?
2. Can anyone outside the team
help?
3. Can something be dropped
from the sprint backlog?

Sprint Length

Size matters. Shorter is better!
 Feedback more often
 Stable velocity quicker
 React to changes faster
 Learn processes faster
 ”If it wasn’t for the last minute, nothing would ever get
done.” - a lot more last minutes

Daily Stand-Up Meeting

Agenda Participants
 What has been accomplished  Scrum Master
since the last meeting?  Developers
 What will be done before the  Passive: Other interested
next meeting? parties - only listen!
 What obstacles are in the
way?

Same time and place every day. Only answer the three
questions, keep any discussions outside the meeting.
Instead, meet immediately after the Daily Scrum for re-
planning and further discussions.

Sprint Backlog
STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL
Implement a
Story 1 123
working API
5 points BURNDOWN CHART

Story 2 127

1 points UNPLANNED
Story 3 213

8 points
NEXT
Story 4 129

5 points
5 points
3 points

Sprint Backlog
Implement a
Story 1 123 MN
working API
SA

Story 2 127

1 points UNPLANNED
Story 3 213 PL

8 points
NEXT
Story 4 129

5 points
5 points
3 points

Sprint Backlog
Implement a
Story 1 123 MN SA
working API
SA

Story 2 127

1 points UNPLANNED
Story 3 213 PL

8 points
NEXT
PL
Story 4 129

5 points
5 points
3 points

Sprint Backlog
Implement a
Story 1 123 MN SA
working API
SA MN

Story 2 127 PL

1 points UNPLANNED
Story 3 213 PL SA

8 points
NEXT
MN PL
Story 4 129

5 points
5 points
3 points

Sprint Backlog
STORY TO DO TESTS COMPLETE IN PROGRESS ”DONE” HOURS
(2)
Story 1 123 SA
32
5 points
 MN

SA

Story 2 127

1 points
8

Story 3 213 PL

8 points
 48
PL

Sprint Burndown Chart
Hours

Days

Sprint Review

Agenda Participants
 What has been  Product Owner
done, what has not been  Scrum Master
done
 Developers
 What went well, any
problems  Stakeholders
 Product backlog
 What to do next

Sprint Retrospective

Agenda Participants
 Inspect last sprint  Scrum Master
 People and relationships  Developers
 Process and tools
 Identify potential
improvements
 Plan for implementing
improvements

http://www.flickr.com/photos/acediscovery/3030548744/

Release Planning

Release Planning

Agenda Participants
 Goal for the release  Product Owner
 Identify features  Stakeholders
 Rough estimates  Scrum Master
 Create a release plan  Developers

Release Planning

Fixed Date Fixed Scope

Can Have

X weeks
Might Have

Won’t Have

Release Burndown Chart
Story Points

Sprints

Release Burndown Bar Chart

Team Progress
Completed stories
Re-estimations
Story points

Sprints

Workload changes
Added features
Removed features

Parking Lot Diagram

Theme, subsystem, product

Theme, epic, fe Theme, epic, fe Theme, epic, fe
ature set ature set ature set
(8) (8) (8)
50% 50% 0%

Sprint 8 Sprint 3 Sprint 10

Theme, subsystem, product Theme, subsystem, product

Theme, epic, fe Theme, epic, fe Theme, epic, fe Theme, epic, fe
ature set ature set ature set ature set
(8) (4) (8) (4)
50% 25% 0% 0%

Sprint 8 Sprint 3 Sprint 12 Sprint 12

http://www.flickr.com/photos/28481088@N00/2957770391/

Scaling Scrum

Scaling Scrum

 Synchronize sprints between teams
 Do integration at sprint boundaries
 Coordinate work
 Lookahead planning
 Complexity increases

http://www.flickr.com/photos/darkroses/2357927668/

Distributed Scrum

Distributed Scrum

To be successful...

 Shared vision and goal  Tools for distributed
 Personal relationships collaboration
 Virtual Scrum boards
 Kick-off meeting
 Video conferencing
 Workshops
 Screen sharing
 Same standards and
values
 Estimation
 Definition of Done

Distributed Daily Stand-Up Meetings

Working Hours

A
Team

Working Hours

B

Time

http://www.flickr.com/photos/droetker0912/5542920908/

Additional Stuff

Scrum Misconceptions

”
Scrum says documentation
isn’t important.
Documentation is important, but
working software is valued more.
!
”
People need to be ”cross- Teams need to be cross-
functional”. That sounds
both inefficient and
unrealistic.
functional, not people. Nonetheless, it
is always a good idea not to rely on
one person. Spread the knowledge.
!


”
We can’t estimate in size, I
need to know when we can
Using story points you can still
deliver. estimate when the project will be
completed. The important difference
is that duration is derived from size.
!
”
It’s not possible to mix Maybe you will not reach Scrum’s
Scrum and our traditional
project model (read:
waterfall)
full potential, but you can benefit
from agile methods nontheless. !


”
We’re working on a fixed
price contract, so we can’t use
Let the project manager act as
Scrum. product owner, and use Scrum inside
your organization. !
”
Scrum does not work with Good point. Co-located teams are
distributed teams. always best, but it is possible to use
Scrum in a distributed organization
as well.
!


”
When you split stories you
create dependencies, but you
Stories should independently bring
should INVEST in the user
stories? (Stories should be
independent)
value to the product. They can still
have logical dependencies on other
stories. Remember: the product
backlog is ordered.
!

Supporting Practices

 XP practices
 Sustainable pace  Pair programming
 Collective code ownership  Coding standards
 Test Driven Development (TDD)  Refactoring
 Continuous Integration (CI)  Spikes
 Meeting Techniques
 Preparation
 Time boxing
 Pragmatic Programming

Further Reading

 Devoted Developer – www.devoteddeveloper.com
 The Scrum Guide - www.scrum.org
 ”Agile Estimating and Planning”, Mike Cohn, 2005
Addison-Wesley - www.mountaingoatsoftware.com/books/1-agile-estimating-and-planning
 User Story Primer - trailridgeconsulting.com/files/user-story-primer.pdf
 Scrum Alliance - www.scrumalliance.org/
 How to Split a User Story - rslawrence.wpengine.com/wp-
content/uploads/2012/01/Story-Splitting-Flowchart.pdf

Zen of Scrum

More Related Content

What's hot (20)

Similar to Zen of Scrum (20)

Recently uploaded (20)

Zen of Scrum

Editor's Notes