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"
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"
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
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)
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
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
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
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
