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.

1. Kanban or Scrum?

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

4. Collect Work
Story
Story
Story
Story
Story
Story
Product Backlog:
prioritized
Story: something that
needs to be done, that
can be done in a Sprint
Highest priority Story
Lowest priority Story

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

22. The Nuclear Option

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

26. Burndown
Story
Points
remaining
Days remaining in Sprint
Theory
Reality
Stressful slow start
Panicky despair
Unwarranted euphoria

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

34. Collaboration Networks
(You are here)

35. Try Technology

36. Example: Personal Kanban
What’s currently on Melissa’s plate, and why your request is waiting…

37. Example: Team Kanban
More complex workflows, and smart highlights on what’s changed

38. Example: Agency
Public sector example of Kanban with a distributed team

39. Example: Marketing Scrum
Two Scrum boards, representing different Sprints, that access the same Backlog

40. Stories
The crucial details that won’t fit onto a Post It

41. Tasks
Track all the Tasks needed to complete a Story

42. Content
The files and Web stuff you consume and produce for the Story

43. Conversations
Chat about the Story, on the Story itself

44. People
Identify who’s working on a Story, right now

45. Tags
Help link together related cards, like all the Stories that came from same Epic

46. Situational Awareness
What happened while you were away

47. Pivoting Your View
See work from a time perspective, an alternative to workflow view

48. At Scale
Smart highlights to zoom in on what matters most to you

49. Across Projects
Summary views of everything that’s happening, across all your Kerika boards, right now.

50. What’s Assigned to Me?
Across every board: what’s expected of you, right now?

51. What Needs Attention?

52. What Got Done?
Your status report, automated

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

54. Questions?

55. Arun@Kerika.com