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"
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)
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
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 cant improve, were doing something wrong ○ Should end up in actions for the next sprint
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 ○ 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● 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 & Wunderliebevandermeij@gw20e.com@douwevandermeij
Kanban● Signaling system● Ideal for small projects● Priority queue● WIP limit ○ Nr. of user stories in progress