Originally presented at the 207 Lean Transformation Conference, this presentation provides a practical introduction to Scrum, particularly for public sector employees, and guides you to deciding whether Kanban or Scrum will work best for your teams and projects.
2. Scrum in a nutshell
Form a team
Collect work
Prioritize work
Pick up some of the work
Do this work in a Sprint
Show what you did
Reflect on how well you did
3. Form a Team
• Product Owner
– The voice of the customer
– If you need several Product Owners, you need
several Scrum Teams
• Scrum Master
– Removes impediments
– (Not really a Project Manager)
– (Not necessarily a full-time job)
– (Not necessarily a permanent role)
• Scrum Team
– People who can Pull; don’t need work Pushed to
them
5. “As a small business owner, I
want a single place to file all
my quarterly reports,
so I don’t have to deal with
multiple agencies.”
6. Write a Good Story
“As a …,
I want to …
so that I can …”
Who?
What?
Why?
(But not how)
7. Define “Done”
• Agree, up-front, what Done means for each Story
– Define acceptance criteria for the Story
– Include as part of the Story
– Agree on this before starting work
• Use this definition during Show & Tell at Sprint’s
End
– Team formally demonstrates that acceptance
criteria have been met
– Product Owner accepts Story as Done.
– If more/different work is required after story
has been accepted, that’s a new story
8. Epics & Stories
Can it be
done in
a Sprint?
You have a
story
Break it down into
more stories
Yes
No
9. Epics, Stories, Tasks
Story 1-1
Story 1-2
Story 1-3
Story 2-1
Story 2-2
Story 2-3
Epic 1
Epic 2
Task 1-1-1
Task 1-1-2
Task 1-1-3
10. Example
Epic: create a mobile-friendly version of the
OFM agency website
• Story 1: “As a citizen, I want to be able to
look up salaries from my phone”
• Story 2: “As an employee, I want to be able
to access HR docs from my phone”
Task 2-1: Reformat the Sick Leave page
11. Plan Work
• Estimate relative complexity using story
points
Story Points ≠ Hours or Days
• Complexity has a non-linear impact
2x as hard? More than 2x as long
• Fibonacci Series helps
1, 2, 3, 5, 8, 13, 21
12. Try to Fail Fast
Story
Story
Story
Story
Story
Story
Product Backlog:
Prioritized by
difficulty
Try to do the hardest,
riskiest work first.
If project is going to fail
because the work is too
hard to do, it’s better to
learn early than late.
Hardest work first
Easy work is lower priority
13. Organize a Sprint
• Prep: Groom the Backlog
– Product Owner does this
• Start: Sprint Planning
– Pick a doable set of prioritized stories
• Work: Daily Standups
– Track progress with burndown
• Deliver: Sprint Ends
– Only completed stories are Done
• Reflect: Sprint Retrospective
– How did we do?
14. Play Planning Poker
A way for a team to collectively estimate complexity
• Each team member has cards numbered 1, 2, 3, 5…
• After a Story is reviewed, everyone simultaneously holds up a card
with their personal estimate of the Story’s complexity (Story Points)
– This is needed to get a wisdom of crowds estimate, where
each estimate is independent
• If estimates are widely divergent, team members are asked to justify
their outliers:
– Why did you think it is just 1 point?
– And why did you think it is 8 points?
• After discussion, people bid again: the estimates should start
converging, as people’s understanding of the work converges.
– Repeat until estimates converge to a single number; use that
number.
15. Commit just enough
• Velocity is used to help the Scrum Team pick a
suitable number of Stories for the next Sprint
– Velocity is average number of Story Points
delivered by the Team in previous Sprints
• Commit as close to velocity as possible, without
going over
Example: Velocity is 20 points; commit to 19
points rather than 21.
– If Team finishes before Sprint ends, pick up
more Stories as stretch goals.
16. How long is a Sprint?
Depends…
• 1 week is short
• 1 month is long
• 2 weeks is usually good
You need to be able to do at least 1+ stories in one
Sprint
You need consistency across Sprints
• Duration doesn’t change based upon complexity of
work in a particular Sprint
• Break the stories down to fit into a Sprint, not the
other way around…
17. Ideal Sprints
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6
Story 7
Story 8
Product Backlog
Story 1
Story 2
Story 3
Sprint 1
Story 4
Story 5
Story 6
Sprint 2
Story 1
Story 2
Story 3
Done
Story 7
Story 8
Sprint 3
Story 4
Story 5
Story 6
Story 7
Story 8
18. Real-life Sprints
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6
Product Backlog
Story 1
Story 2
Story 3
Sprint 1
Story 4
Story 5
Story 5
Sprint 2
Story 1
Story 2
Story 3
Done
Story 6
Sprint 3
Story 4
Story 5
Story 6
Story 3Story 3
Story 5
19. Abandoning Stories
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6
Product Backlog
Story 1
Story 2
Story 3
Sprint 1
Story 6
Story 6
Sprint 2
Story 1
Story 2
Story 4
Done
Sprint 3
Story 5
Story 6
Story 6
Story 4
Story 5
Time-sensitive story didn’t
make it; gets abandoned
20. Epics Across Sprints
Sprint 1 Sprint 2
Story 1 Story 2 Story 3
Sprint 3
Story 4 Story 5 Story 6 Story 7 Story 8
Epic 1 Epic 2
21. Run the Sprint
• Protect the team
– No new commitments
• Measure output
– Use Burndown Chart for early warning
• Show & Tell
– Product Owner must accept what’s Done
• End Sprint
– Use Retrospective to reflect
– Calculate Velocity of the team
23. Daily Standups: Old School
In 2 minutes each, each person tells the team:
• What did I get done, since yesterday?
• What do I plan to do today?
• What is blocking me?
Scrum Master:
• Remove impediments
• Update Burndown
• Not a Project Manager
• Not a full-time job
24. Daily Standups: Kerika Style
Standups are not needed simply for the team to
catch up on what everyone else is doing: Kerika will
provide updates in real-time.
Standup are not needed to identify impediments;
these can be flagged in real-time.
Instead, use the Daily Standup to address the most
difficult problems, and answer the most strategic
questions
• Where individual action isn’t enough, and
collective problem solving is needed
Makes the Daily Standup worth attending!
25. Product Owner Stays Involved
Product Owners shouldn’t just appear at the Sprint
Planning and Sprint Retrospectives; they should
participate in the Daily Standups.
As team works through stories, questions will
arise; decisions will need to be taken.
• Product Owner can help remove external
impediments
• Product Owner shouldn’t expand scope of work,
but can help narrow scope when needed
27. Velocity
• Capacity of team, measured as historical average
of Story Points delivered in past 3 Sprints
• Useful for planning future Sprints
– Guide to capacity of current team
– Not known at the beginning
– Measures perceived complexity of work; not
competence or productivity of Team
• Will flatline eventually
– Stable team, consistent Sprints
28. Scrum Retrospectives
• What worked, what didn’t
– Were stories clear?
– Was Product Owner supportive?
– Was Scrum Master helpful?
• Did velocity change?
– Why?
29. Getting Scrum Right
• Deal with distributed teams
– Fluid collaboration networks
– Instant situational awareness
• Deal with differences in skills
– Specialists often to work on multiple projects at same time.
• Deal with scale
– Many, many cards. Many, many boards.
• Deal with chores and defects
– Treat them like stories
• Have a sprint theme
– Avoid picking a random set of stories for a Sprint
• Avoid velocity inflation
30. Where Scrum Works Best
• Work is new
– Strategy, tactics are uncertain
• Environment is fluid
– Requirements / market / policy uncertainty
– New partnerships are being tried
• Process improvement is rhythmic
– Re-prioritize work episodically
• Examples:
– Any & all software development
31. Scrum in Government
• Need regulatory flexibility in purchasing
– Buying Agile services
– Trying SaaS technology
• Need budget flexibility in planning
– Cannot realistic budget for everything that a
Scrum project needs
• Need organizational flexibility in career paths
– Without traditional Project Managers,
promotion paths need to evolve
– Rewards team contribution, more than
individual achievement?
32. Getting Kanban Right
• Deal with distributed teams
– Fluid collaboration networks
– Awareness with emails
• Integrate Tasks + Content + Conversations
– Critical elements of system
• Manage capacity with Work-in-Process Limits
– Personal Kanban: WIP for today
– Team Kanban: WIP for function in workflow
• Optimize for smooth flows
– Avoid rework, waste
33. Where Kanban Works Best
• Work flows in continuously
– Similar size and shape
– Can be done by anyone
– Is re-prioritized very frequently
• Work is well understood
– You are not inventing (much)
• Examples:
– Case Management, Help Desk
53. Summary
• You need technology to scale
– Paper doesn’t scale
• Be pragmatic, not dogmatic
– The perfect team doesn’t exist
• Remember to reflect, improve
– Every Sprint
• Get buy-in, get support
– Management, policy, technology
As with any religion, you need to understand the
philosophy before you follow the rituals