scrum in practice
DESCRIPTION
Dutch blog post: http://www.goldmund-wyldebeast-wunderliebe.com/tech-blog/scrum-in-de-praktijkTRANSCRIPT
Working with Scrum
Douwe van der Meij
Goldmund, Wyldebeast & Wunderliebe
[email protected]@douwevandermeij
Outline
● History of scrum● Scrum● Tooling● Conclusion
History
● 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
● 2001● Schwaber, Beedle
○ Book: "Agile Software Development with SCRUM"
Combined forces
● 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:
Scrum
● Project manager● Development team
● Product owner (PO)● Scrum master
Roles
● 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
● Work takes place in sprints● Time boxed iterations, fixed!
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
Sprints
User story● Description of a task that the application is
supposed to do for a certain reason and can be measured.
" As an <actor>,I want to <action>
because <reason> "
User story
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 evolution
Overview (general)
User story lifecycle
Backlog
Prioritizedbacklog
Sprintbacklog
Commitment
TestingProduct
increment
User story lifecycle
Backlog
Prioritizedbacklog
Sprintbacklog
Commitment
TestingProduct
increment
Backlog
How to do that?
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
Inspect and adapt
Overview (total)
© 2010 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde
Metrics
● The amount of story points the team is able to process during a sprint
● Refined/more precise after each sprint
Team velocity
● Hours left (and spent)● Ahead of / behind schedule
Burndown chart
● Total nr. of story points● Nr. of approved story points
Burnup chart
Relation between charts
Tooling
● 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
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
Conclusion
● Signaling system● Ideal for small projects
● Priority queue● WIP limit
○ Nr. of user stories in progress
Kanban
Kanban
Not planned Planned In progress Testing Done
Priority queue
Max. 3 WIP Limit