Scrum in practice
Upcoming SlideShare
Loading in...5

Scrum in practice



Dutch blog post:

Dutch blog post:



Total Views
Views on SlideShare
Embed Views



6 Embeds 1,621 1282 328 6
http://localhost 2 2 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Scrum in practice Scrum in practice Presentation Transcript

  • Working with Scrum Douwe van der Meij Goldmund, Wyldebeast &
  • Outline● History of scrum● Scrum● Tooling● Conclusion
  • History
  • 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
  • Scrum● 1991● First referred to as Scrum by: Peter DeGrace, Leslie Hulet Stahl● Like scrummage (abbr. scrum) in rugby
  • Scrum-like approaches● 1990s● Ken Schwaber ○ Described "Advanced Development Methods"● 1993● Jeff Sutherland, John Scumniotales, Jeff McKenna ○ Similar approach at Easel Corporation
  • First workshop● 1995● Sutherland, Schwaber ○ First presentation/workshop at OOPSLA 95, Austin Texas● They merged all earlier writings
  • Meanwhile● 1999● Mike Beedle ○ Scrum patterns ○ Chapter in book: "Pattern Languages of Program Design 4"
  • Combined forces● 2001● Schwaber, Beedle ○ Book: "Agile Software Development with SCRUM"
  • Since then...● A lot of literature appeared ○ Mike Cohn● A lot of companies started using scrum ○ In a way
  • Common sayings:● "We already use scrum"● "We dont 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"
  • Scrum
  • Roles● Project manager● Development team● Product owner (PO)● Scrum master
  • 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
  • Product owner● Two-fold role / pivot point ○ Responsible for the user stories ■ Towards the development team ○ Responsible for the deliverables ■ Towards the management
  • Scrum master● Process owner ○ Guards the process● Takes care of impediments ○ Every impediment you can think of, regarding the project● Mediator ○ For everyone
  • Sprints● 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
  • User story● Description of a task that the application is supposed to do for a certain reason and can be measured.
  • User story " As an <actor>, I want to <action> because <reason> "
  • 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
  • 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
  • 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 evolution
  • Overview (general)
  • User story lifecycle Prioritized backlog Sprint backlog Backlog Commitment Product increment Testing
  • User story lifecycle Prioritized backlog Sprint backlog Backlog Commitment Product increment Testing
  • How to do that?
  • CeremoniesIn order of appearance:● (User story workshop)● Planning poker● PO-presentation● Team planning / commitment● Daily stand-up● Review meeting● Retrospective meeting
  • CeremoniesSchematic: Sprint PO Planning Team Retro- presen- Review poker planning spective tatie Daily Daily Daily standup standup standup
  • 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)"
  • 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 ?
  • Planning poker● Use your gut feeling● The more you poker the better you draw● Provides insights in thoughts of the developers about the implementation
  • 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
  • Business value poker● For all ideas about the project● Grade in terms of importance / business value 100 200 300 500 800 1300 2000 3000
  • 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
  • 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
  • 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
  • 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
  • Team planning / commitment
  • Daily stand-up● Talk about the user stories under development ○ Yesterday ○ Today ○ Impediments● Discuss mini-spikes
  • Review meeting● Discuss spike results● Discuss the user stories worked on● Re-calibrate planning poker, if needed● Calculate team velocity
  • Retrospective meeting● What went well● What went wrong● What to improve ○ Inspect and adapt● If we cant improve, were doing something wrong ○ Should end up in actions for the next sprint
  • Inspect and adapt
  • Overview (total) © 2010 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde
  • Metrics
  • Team velocity● The amount of story points the team is able to process during a sprint● Refined/more precise after each sprint
  • Burndown chart● Hours left (and spent)● Ahead of / behind schedule
  • Burnup chart● Total nr. of story points● Nr. of approved story points
  • Relation between charts
  • Tooling
  • Tools● Jira● Trac● Lighthouse● Spreadsheet
  • Lighthouse●● Slightly other terminology ○ Sprints → Milestones ○ User stories → Tickets● Signalling with tickets/milestones
  • 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
  • Ticket milestone (sprint)● Not linked ○ Ticket is in the product backlog ○ Doesnt need to be voted yet ○ Doesnt need to be prioritized● Linked ○ Ticket is in the sprint backlog ○ Must be voted ○ Is prioritized
  • 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
  • Conclusion
  • 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
  • Thank you! Douwe van der Meij Goldmund, Wyldebeast &
  • Kanban● Signaling system● Ideal for small projects● Priority queue● WIP limit ○ Nr. of user stories in progress
  • KanbanNot planned Planned In progress Testing Done Max. 3 WIP Limit Priority queue