Working with Scrum

            Douwe van der Meij

   Goldmund, Wyldebeast & Wunderliebe
vandermeij@gw20e.com
@douwevandermeij
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
● 1990's
● 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 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"
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?
Ceremonies
In order of appearance:
● (User story workshop)
● Planning poker
● PO-presentation
● Team planning / commitment
● Daily stand-up
● Review meeting
● Retrospective meeting
Ceremonies
Schematic:

                                           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




                https://learn.test.dau.mil/CourseWare/800949_1/pbl0202/pbl0202_0080p1.htm
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 can't improve, we're 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
● www.lighthouseapp.com
● 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
  ○ 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
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 & Wunderliebe
vandermeij@gw20e.com
@douwevandermeij
Kanban
● Signaling system
● Ideal for small projects

● Priority queue
● WIP limit
   ○ Nr. of user stories in progress
Kanban

Not planned   Planned    In progress Testing   Done




                         Max. 3
                         WIP Limit

              Priority
              queue

Scrum in practice

  • 1.
    Working with Scrum Douwe van der Meij Goldmund, Wyldebeast & Wunderliebe vandermeij@gw20e.com @douwevandermeij
  • 2.
    Outline ● History of scrum ● Scrum ● Tooling ● Conclusion
  • 3.
  • 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 ● Firstreferred 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 ● MikeBeedle ○ 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... ● Alot of literature appeared ○ Mike Cohn ● A lot of companies started using scrum ○ In a way
  • 11.
    Common sayings: ● "Wealready 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.
  • 13.
    Roles ● Project manager ●Development team ● Product owner (PO) ● Scrum master
  • 14.
    Product owner ● Theproduct 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-foldrole / pivot point ○ Responsible for the user stories ■ Towards the development team ○ Responsible for the deliverables ■ Towards the management
  • 16.
    Scrum master ● Processowner ○ Guards the process ● Takes care of impediments ○ Every impediment you can think of, regarding the project ● Mediator ○ For everyone
  • 17.
    Sprints ● Work takesplace in sprints ● Time boxed iterations, fixed!
  • 18.
    Sprints ● Development teamworks 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 ● Descriptionof 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 ● Everyonecan 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 ● Whenis it ready? ● Define visible indicators (measurability) ● Define a (global) "Definition of Done" (DoD) ○ Example: ■ Tests ■ Documentation (e.g., in code, user manual)
  • 24.
  • 25.
  • 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 dothat?
  • 29.
    Ceremonies In order ofappearance: ● (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 ● Forall 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 ● Forall 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 ● Useyour gut feeling ● The more you poker the better you draw ● Provides insights in thoughts of the developers about the implementation
  • 34.
    Rules of planningpoker ● 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 generaldirection 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 ● Talkabout the user stories under development ○ Yesterday ○ Today ○ Impediments ● Discuss mini-spikes
  • 42.
    Review meeting ● Discussspike results ● Discuss the user stories worked on ● Re-calibrate planning poker, if needed ● Calculate team velocity
  • 43.
    Retrospective meeting ● Whatwent 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.
  • 45.
    Overview (total) © 2010 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde
  • 46.
  • 47.
    Team velocity ● Theamount of story points the team is able to process during a sprint ● Refined/more precise after each sprint
  • 48.
    Burndown chart ● Hoursleft (and spent) ● Ahead of / behind schedule
  • 49.
    Burnup chart ● Totalnr. of story points ● Nr. of approved story points
  • 50.
  • 51.
  • 52.
    Tools ● Jira ● Trac ● Lighthouse ● Spreadsheet
  • 53.
    Lighthouse ● www.lighthouseapp.com ● Slightlyother 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.
  • 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