Dutch blog post: http://www.goldmund-wyldebeast-wunderliebe.com/tech-blog/scrum-in-de-praktijk

1. Working with Scrum
Douwe van der Meij
Goldmund, Wyldebeast & Wunderliebe
vandermeij@gw20e.com
@douwevandermeij

2. Outline
● History of scrum
● Scrum
● Tooling
● Conclusion

3. History

4. Holistic/Rugby approach
● 1986
● Hirotaka Takeuchi, Ikujiro Nonaka
● New production line tactic
○ Increase speed & flexibility
● Based on case studies:
○ Automotive, photocopier, restaurant food and
printer industries
● Like a rugby game
○ To gain distance as a group

5. Scrum
● 1991
● First referred to as Scrum by: Peter
DeGrace, Leslie Hulet Stahl
● Like scrummage
(abbr. scrum) in
rugby

6. Scrum-like approaches
● 1990's
● Ken Schwaber
○ Described "Advanced Development Methods"
● 1993
● Jeff Sutherland, John Scumniotales, Jeff
McKenna
○ Similar approach at Easel Corporation

7. First workshop
● 1995
● Sutherland, Schwaber
○ First presentation/workshop at OOPSLA '95, Austin
Texas
● They merged all earlier writings

8. Meanwhile
● 1999
● Mike Beedle
○ Scrum patterns
○ Chapter in book: "Pattern
Languages of Program
Design 4"

9. Combined forces
● 2001
● Schwaber, Beedle
○ Book: "Agile Software
Development with SCRUM"

10. Since then...
● A lot of literature appeared
○ Mike Cohn
● A lot of companies started using scrum
○ In a way

11. Common sayings:
● "We already use scrum"
● "We don't actually use all parts of scrum
because ..."
○ "... we are a (too) small company"
○ "... there is a fixed scope"
○ "... the project is fixed price"
○ "... the projects are too small"
○ "... each project is a project on its own"
○ "... we use another method"

12. Scrum

13. Roles
● Project manager
● Development team
● Product owner (PO)
● Scrum master

14. Product owner
● The product owner represents the customer
● The product owner represents the supplier
○ The product owner approves finished user stories
PO Development
team
Management
Scrum master

15. Product owner
● Two-fold role / pivot point
○ Responsible for the user stories
■ Towards the development team
○ Responsible for the deliverables
■ Towards the management

16. Scrum master
● Process owner
○ Guards the process
● Takes care of impediments
○ Every impediment you can think of, regarding the
project
● Mediator
○ For everyone

17. Sprints
● Work takes place in sprints
● Time boxed iterations, fixed!

18. Sprints
● Development team works on
○ Implementing planned user stories
○ Defining new user stories
● Product owner works on
○ Approving finished user stories
○ Defining new user stories
○ Prioritizing user stories

19. User story
● Description of a task that the application is
supposed to do for a certain reason and can
be measured.

20. User story
" As an <actor>,
I want to <action>
because <reason> "

21. User story
● <actor>
○ A user that can perform and measure the action
● <action>
○ Something that the application is supposed to do
● <reason>
○ Background information to give context to story

22. User story
● Everyone can should create user stories at
any time
● Be precise and concise
● Product owner keeps the overview
● Approval only by a product owner

23. User story
● When is it ready?
● Define visible indicators (measurability)
● Define a (global) "Definition of Done" (DoD)
○ Example:
■ Tests
■ Documentation (e.g., in code, user manual)

24. User story evolution

25. Overview (general)

26. User story lifecycle
Prioritized
backlog
Sprint
backlog
Backlog
Commitment
Product
increment Testing

27. User story lifecycle
Prioritized
backlog
Sprint
backlog
Backlog
Commitment
Product
increment Testing

28. How to do that?

29. Ceremonies
In order of appearance:
● (User story workshop)
● Planning poker
● PO-presentation
● Team planning / commitment
● Daily stand-up
● Review meeting
● Retrospective meeting

30. Ceremonies
Schematic:
Sprint
PO
Planning Team Retro-
presen- Review
poker planning spective
tatie
Daily Daily Daily
standup standup standup

31. Planning poker
● For all user stories
○ Discuss the goal
● Find spikes
● Discussion = information
● Questions = important to subject
● Add all information to user story
● Define "Definition of Done (DOD)"

32. Planning poker
● For all user stories
● Grade in terms of:
○ Complexity
○ Amount of time to implement
0 ½ 1 2 3 5
8 13 20 40 100 ?

33. Planning poker
● Use your gut feeling
● The more you poker the better you draw
● Provides insights in thoughts of the
developers about the implementation

34. Rules of planning poker
● The user story gets the (highest) score ...
a. ... that is unanimously chosen
b. ... when there is a difference of at most 1 card
● When difference > 1 card
a. Discuss differences (especially outliers)
b. Re-estimate until estimates converge

35. Business value poker
● For all ideas about the project
● Grade in terms of importance / business
value
100 200 300 500
800 1300 2000 3000

36. Business value poker
● Done by PO & management
● Defines priority
○ The most important and least complex user stories
get done first
○ The least important and most complex user stories
get done later
Business value score
Priority =
Story points

37. Re-modeling your kitchen
Product item backlog Estimate
a Install new hardwood floor
b Sand and re-paint cabinets
c Replace tile countertop with granite
d Re-paint entire kitchen
e Lay shelf paper
f Install recessed (down) lighting
g Install a built-in refrigerator
h Replace existing oven with a new one
i Run a water line to existing island and install a sink
j Replace existing simple window with a bay window
Copyright © 2011, Mountain Goat Software

38. PO-presentation
● Present general direction of the product
● Present voted prioritized backlog
● The complete development team is
attending
● Developers ask questions about the
implementation
● All developers must have a clear
understanding of each user story

39. Team planning / commitment
● Development team pulls in user stories and
commits to delivery
● User stories that certainly get finished
○ Actual commitment
● User stories that maybe get finished
○ Bonus
● Psychological effect

40. Team planning / commitment
https://learn.test.dau.mil/CourseWare/800949_1/pbl0202/pbl0202_0080p1.htm

41. Daily stand-up
● Talk about the user stories under
development
○ Yesterday
○ Today
○ Impediments
● Discuss mini-spikes

42. Review meeting
● Discuss spike results
● Discuss the user stories worked on
● Re-calibrate planning poker, if needed
● Calculate team velocity

43. Retrospective meeting
● What went well
● What went wrong
● What to improve
○ Inspect and adapt
● If we can't improve, we're doing something
wrong
○ Should end up in actions for the next sprint

44. Inspect and adapt

45. Overview (total)
© 2010 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde

46. Metrics

47. Team velocity
● The amount of story points the team is able
to process during a sprint
● Refined/more precise after each sprint

48. Burndown chart
● Hours left (and spent)
● Ahead of / behind schedule

49. Burnup chart
● Total nr. of story points
● Nr. of approved story points

50. Relation between charts

51. Tooling

52. Tools
● Jira
● Trac
● Lighthouse
● Spreadsheet

53. Lighthouse
● www.lighthouseapp.com
● Slightly other terminology
○ Sprints → Milestones
○ User stories → Tickets
● Signalling with tickets/milestones

54. Ticket responsible
● Unassigned
○ Not yet pulled by a team member
● Assigned
○ Someone is working on / responsible for this ticket
● Tip:
○ Max. 1 ticket assigned to a person except PO, or
have a good reason not to

55. Ticket milestone (sprint)
● Not linked
○ Ticket is in the product backlog
○ Doesn't need to be voted yet
○ Doesn't need to be prioritized
● Linked
○ Ticket is in the sprint backlog
○ Must be voted
○ Is prioritized

56. The product backlog
● All unlinked tickets (not linked to milestone)
● All tickets linked to older milestones
● Product owner should watch this closely
● Prepare (tickets) before poker planning
meeting

57. Conclusion

58. Conclusion
● Define user stories, find spikes
● Do planning poker
● Do PO-presentations
● Only work on planned user stories
○ No more, no less
● Find your team velocity
● Timeboxed sprints, no excuses!
○ 1 to 4 weeks

59. Thank you!
Douwe van der Meij
Goldmund, Wyldebeast & Wunderliebe
vandermeij@gw20e.com
@douwevandermeij

60. Kanban
● Signaling system
● Ideal for small projects
● Priority queue
● WIP limit
○ Nr. of user stories in progress

61. Kanban
Not planned Planned In progress Testing Done
Max. 3
WIP Limit
Priority
queue