zen of scrum
DESCRIPTION
Introduction to Scrum: a product development framework based on agile principles.TRANSCRIPT
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 shippable”) software frequently by developing functioning software in each iteration
Favor customer collaboration by encouraging customer involvement throughout the project
Respond to changing requirements, even late in development, by not planning ahead in too much detail
Avoid procrastination, or ”student’s syndrome”, by working in small increments
“Scrum employs an iterative, incremental approach to optimize predictability and control risk.”
- Scrum Guide
Transparency
Work
Inspect
Adapt
Scrum Values
Courage Respect Focus
Commitment Openness
Scrum Distilled
Product backlog Increment
Team
ProductOwner
SprintPlanning
DailyStand-Up
SprintRetrospective
Release2-6 months
Sprint2-4 weeks
Daily Scrum24 hoursScrum
Master
Sprint backlog
scrum team iterations events
SprintReview
Scrum Team
“Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback.”
- Scrum Guide
ProductOwner
ScrumMaster
Team(Developers)
Responsible for Product Backlog (PBL)
Ensure developers understand PBL items
Maximize ROI
Ensure Scrum is understood and enacted
Scrum coach Removing impediments Facilitate meetings
Deliver potentially releasable increment of “Done” product at the end of each Sprint
Self-organizing Cross-functional
“…designed to optimize flexibility, creativity, and productivity.”
- 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
Planning and Estimation
http://www.flickr.com/photos/calypso/2767592937/
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
123
5 points
As a ...
I want to ...
So that I can ...
Story XYZ
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
Project evolvement
estim
ation
acc
urac
y
1x
4x
2x
0.5x
0.25x
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
Estimating with Story Points
2
2
1
53
Story Points
0 1 2 3 5 8 13 20 40 100Stories Epics
Story Points
0 x 8 ≠ 0
Story Points
XS S M L XL
Poker Planning
012835 8102040100
Story Splitting
Story 1
123
5 points
Story 1
123
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
The Sprint
http://www.flickr.com/photos/john_scone/493915787/
Sprint Planning
Agenda Select user stories Identify and estimate
technical tasks Come up with sprint goal
Participants Product Owner Scrum Master Developers
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.
1 hrs
Story 1 123
5 points
4 hrs
1 hrs
2 hrs
4 hrs
8 hrs
Sprint Planning
Product Backlog Grooming
Agenda Update the product
backlog Refine and split top stories Estimate stories
Participants Product Owner Scrum Master Developers
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
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?
Three questions to ask before canceling a sprint:
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 What has been accomplished
since the last meeting? What will be done before the
next meeting? What obstacles are in the
way?
Participants Scrum Master Developers Passive: Other interested
parties - only listen!
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
TO DO IN PROGRESS ”DONE”
UNPLANNED
NEXT
STORY
Story 1 123
5 points
Story 2 127
1 points
Story 3 213
8 points
5 points
5 points
Story 4 129
3 points
BURNDOWN CHART
Definition of Done
SPRINT GOALImplement a working API
Sprint Backlog
TO DO IN PROGRESS ”DONE”
MN
STORY
Story 1 123
5 points
Story 2 127
1 points
Story 3 213
8 points
SA
PL
BURNDOWN CHART
UNPLANNED
NEXT
5 points
5 points
Story 4 129
3 points
SPRINT GOALImplement a working API
Sprint Backlog
TO DO IN PROGRESS ”DONE”
MN
STORY
Story 1 123
5 points
Story 2 127
1 points
Story 3 213
8 points
SA
PL
PL
SA BURNDOWN CHART
UNPLANNED
NEXT
5 points
5 points
Story 4 129
3 points
SPRINT GOALImplement a working API
Sprint Backlog
TO DO IN PROGRESS ”DONE”
MN
STORY
Story 1 123
5 points
Story 2 127
1 points
Story 3 213
8 points
SA
PL
MN
SA BURNDOWN CHARTMN
PL
PL
SA
UNPLANNED
NEXT
5 points
5 points
Story 4 129
3 points
SPRINT GOALImplement a working API
Sprint Backlog
TO DO IN PROGRESS(2)
”DONE”
MN
STORY
Story 1 123
5 points
Story 2 127
1 points
Story 3 213
8 points
SA
PL
PL
SA
TESTS COMPLETE
HOURS
32
8
48
Sprint Burndown ChartH
ours
Days
Sprint Review
Agenda What has been done,
what has not been done What went well, any
problems Product backlog What to do next
Participants Product Owner Scrum Master Developers Stakeholders
Sprint Retrospective
Agenda Inspect last sprint
People and relationships Process and tools
Identify potential improvements
Plan for implementing improvements
Participants Scrum Master Developers
Release Planninghttp://www.flickr.com/photos/acediscovery/3030548744/
Agenda Goal for the release Identify features Rough estimates Create a release plan
Participants Product Owner Stakeholders Scrum Master Developers
Release Planning
Release Planning
Can Have
Might Have
Won’t Have
X weeks
Fixed Date Fixed Scope
Release Burndown ChartSt
ory
Poin
ts
Sprints
Release Burndown Bar ChartSt
ory
poin
ts
Sprints
Team ProgressCompleted storiesRe-estimations
Workload changesAdded featuresRemoved features
Theme, subsystem, product
Parking Lot Diagram
Sprint 8
Theme, epic, feature set
(8)
50%
Theme, subsystem, product
Sprint 3
Theme, epic, feature set
(8)
50%
Sprint 10
Theme, epic, feature set
(8)
0%
Sprint 8
Theme, epic, feature set
(8)
50%
Theme, subsystem, product
Sprint 3
Theme, epic, feature set
(4)
25%
Sprint 12
Theme, epic, feature set
(8)
0%
Sprint 12
Theme, epic, feature set
(4)
0%
Scaling Scrumhttp://www.flickr.com/photos/28481088@N00/2957770391/
Scrum of Scrums
Scaling Scrum
Synchronize sprints between teams Do integration at sprint boundaries
Coordinate work Lookahead planning
Complexity increases
Distributed Scrumhttp://www.flickr.com/photos/darkroses/2357927668/
Distributed Scrum
Shared vision and goal Personal relationships
Kick-off meeting Workshops
Same standards and values Estimation Definition of Done
Tools for distributed collaboration Virtual Scrum boards Video conferencing Screen sharing
To be successful...
Distributed Daily Stand-Up Meetings
Time
Team
A
BWorking Hours
Working Hours
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-functional”. That sounds both inefficient and unrealistic.
” Teams need to be cross-functional, not people.
Nonetheless, it is always a good idea not to rely on one person.
Spread the knowledge.
!
Scrum Misconceptions
We can’t estimate in size, I need to know when we can deliver.” Using story points you can still
estimate when the project will be completed. The important
difference is that duration is derived from size.
!It’s not possible to mix Scrum and our traditional project model (read: waterfall)” Maybe you will not reach Scrum’s
full potential, but you can benefit from agile methods nontheless.!
Scrum Misconceptions
We’re working on a fixed price contract, so we can’t use Scrum.” Let the project manager act as
product owner, and use Scrum inside your organization.!
Scrum does not work with distributed teams.” Good point. Co-located teams are
always best, but it is possible to use Scrum in a distributed
organization as well.!
Scrum Misconceptions
When you split stories you create dependencies, but you should INVEST in the user stories? (Stories should be independent)
” Stories should independently bring 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 Collective code ownership Test Driven Development (TDD) Continuous Integration (CI)
Meeting Techniques Preparation Time boxing
Pragmatic Programming
Pair programming Coding standards Refactoring Spikes
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
Time’s up!