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
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
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
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
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
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
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.
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
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
46. Scaling Scrum
Synchronize sprints between teams
Do integration at sprint boundaries
Coordinate work
Lookahead planning
Complexity increases
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
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
Three levels of DoD: Task DoD (when all tasks are done, the story is done), Story DoD (when all the stories are done, the sprint is done) and Release DoD