working with scrum
TRANSCRIPT
Working with Scrum
Douwe van der Meij
Goldmund, Wyldebeast & Wunderliebe
[email protected]@douwevandermeij
● 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
Holistic/Rugby approach
● 1991● First referred to as Scrum by: Peter
DeGrace, Leslie Hulet Stahl
● Like scrummage (abbr. scrum) inrugby
Scrum
● 1990's● Ken Schwaber
○ Described "Advanced Development Methods"
● 1993● Jeff Sutherland, John Scumniotales, Jeff
McKenna○ Similar approach at Easel Corporation
Scrum-like approaches
● 1995● Sutherland, Schwaber
○ First presentation/workshop at OOPSLA '95, Austin Texas
● They merged all earlier writings
First workshop
● 1999● Mike Beedle
○ Scrum patterns○ Chapter in book: "Pattern
Languages of Program Design 4"
Meanwhile
● A lot of literature appeared○ Mike Cohn
● A lot of companies started using scrum○ In a way
Since then...
● "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"
Common sayings:
● The product owner represents the customer● The product owner represents the supplier
○ The product owner approves finished user stories
Product owner
PO
Scrum master
Developmentteam
Management
● Two-fold role / pivot point○ Responsible for the user stories
■ Towards the development team○ Responsible for the deliverables
■ Towards the management
Product owner
● Process owner○ Guards the process
● Takes care of impediments○ Every impediment you can think of, regarding the
project● Mediator
○ For everyone
Scrum master
● 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
Sprints
User story● Description of a task that the application is
supposed to do for a certain reason and can be measured.
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
● Everyone can should create user stories at any time
● Be precise and concise
● Product owner keeps the overview● Approval only by a product owner
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)
User story
User story lifecycle
Backlog
Prioritizedbacklog
Sprintbacklog
Commitment
TestingProduct
increment
Backlog
In order of appearance:● (User story workshop)● Planning poker● PO-presentation● Team planning / commitment● Daily stand-up● Review meeting● Retrospective meeting
Ceremonies
Schematic:
Ceremonies
SprintPlanning
pokerRetro-
spectiveReviewPO
presen- tatie
Team planning
Daily standup
Daily standup
Daily standup
● 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)"
Planning poker
● For all user stories● Grade in terms of:
○ Complexity○ Amount of time to implement
Planning poker
0 ½ 1 2 3 5
8 13 20 40 100 ?
● Use your gut feeling● The more you poker the better you draw
● Provides insights in thoughts of the developers about the implementation
Planning poker
● The user story gets the (highest) score ...a. ... that is unanimously chosenb. ... when there is a difference of at most 1 card
● When difference > 1 carda. Discuss differences (especially outliers)b. Re-estimate until estimates converge
Rules of planning poker
● For all ideas about the project● Grade in terms of importance / business
value
Business value poker
100 200 300 500
800 1300 2000 3000
● 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 poker
Business value scoreStory pointsPriority =
Re-modeling your kitchenProduct 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
● 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
PO-presentation
● 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
Team planning / commitment
Team planning / commitment
https://learn.test.dau.mil/CourseWare/800949_1/pbl0202/pbl0202_0080p1.htm
● Talk about the user stories under development○ Yesterday○ Today○ Impediments
● Discuss mini-spikes
Daily stand-up
● Discuss spike results● Discuss the user stories worked on
● Re-calibrate planning poker, if needed● Calculate team velocity
Review 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
Retrospective meeting
● The amount of story points the team is able to process during a sprint
● Refined/more precise after each sprint
Team velocity
● Jira● Trac● Lighthouse● Spreadsheet
Tools
● www.lighthouseapp.com● Slightly other terminology
○ Sprints → Milestones○ User stories → Tickets
● Signalling with tickets/milestones
Lighthouse
● 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
Ticket responsible
● 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
Ticket milestone (sprint)
● 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
The product backlog
● 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
Conclusion
● Signaling system● Ideal for small projects
● Priority queue● WIP limit
○ Nr. of user stories in progress
Kanban