The document discusses key principles of Scrum, including valuing individuals and interactions over processes, working software over documentation, and responding to change over following a plan. It describes Scrum goals of delivering working software frequently through iterations, favoring customer collaboration, and responding to changing requirements. Scrum uses self-organizing cross-functional teams, daily stand-ups, sprints, and retrospectives to deliver working increments iteratively.

1. Zen of Scrum

2. 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.

3. 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

4. Scrum Values
 Courage  Commitment
 Respect  Openness
 Focus

5. 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

6. 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

7. 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

8. http://www.flickr.com/photos/calypso/2767592937/
Planning and Estimation

9. 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

10. User Stories
Story XYZ 123
As a ...
I want to ...
So that I can ...
5 points

11. 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

12. 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

13. Cone of Uncertainty
4x
estimation accuracy
2x
1x
0.5x
0.25x
Project evolvement

14. 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

15. Estimating with Story Points

16. Estimating with Story Points
2
3
5
2
1

17. Story Points
Stories Epics
0 1 2 3 5 8 13 20 40 100

18. Story Points
0x8≠0

19. Story Points
XS S M L XL

20. Poker Planning

21. 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

22. http://www.flickr.com/photos/john_scone/493915787/
The Sprint

23. 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.

24. Sprint Planning
1 hrs 2 hrs
Story 1 123
4 hrs 4 hrs
5 points 1 hrs 8 hrs

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

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

27. 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?

28. 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

29. 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.

30. 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

31. Sprint Backlog
STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL
Implement a
Story 1 123 MN
working API
5 points BURNDOWN CHART
SA
Story 2 127
1 points UNPLANNED
Story 3 213 PL
8 points
NEXT
Story 4 129
5 points
5 points
3 points

32. Sprint Backlog
STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL
Implement a
Story 1 123 MN SA
working API
5 points BURNDOWN CHART
SA
Story 2 127
1 points UNPLANNED
Story 3 213 PL
8 points
NEXT
PL
Story 4 129
5 points
5 points
3 points

33. Sprint Backlog
STORY TO DO IN PROGRESS ”DONE” SPRINT GOAL
Implement a
Story 1 123 MN SA
working API
5 points BURNDOWN CHART
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

34. 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

35. Sprint Burndown Chart
Hours
Days

36. 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

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

38. http://www.flickr.com/photos/acediscovery/3030548744/
Release Planning

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

40. Release Planning
Fixed Date Fixed Scope
Can Have
X weeks
Might Have
Won’t Have

41. Release Burndown Chart
Story Points
Sprints

42. Release Burndown Bar Chart
Team Progress
Completed stories
Re-estimations
Story points
Sprints
Workload changes
Added features
Removed features

43. 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

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

45. Scrum of Scrums

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

47. http://www.flickr.com/photos/darkroses/2357927668/
Distributed Scrum

48. 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

49. Distributed Daily Stand-Up Meetings
Working Hours
A
Team
Working Hours
B
Time

50. http://www.flickr.com/photos/droetker0912/5542920908/
Additional Stuff

51. 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.
!

52. Scrum Misconceptions
”
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. !

53. Scrum Misconceptions
”
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.
!

54. Scrum Misconceptions
”
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.
!

55. 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

56. 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

57. Time’s up!