Agile Scrum Master Training Guide
•
2 likes•492 views
Scrum Master Training at ESPBS | 27th and 28th of Apr 2017.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile Scrum Master Training Guide
Similar to Agile Scrum Master Training Guide (20)
More from Eduardo Ribeiro
More from Eduardo Ribeiro (14)
Recently uploaded
Recently uploaded (20)
Agile Scrum Master Training Guide
- 6. 12 Principles behind the Agile Manifesto • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity the art of maximizing the amount of work not done is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- 13. PRINCIPLES Scrum
- 14. Empirical Process Control Transparency: • Transparency allows all facets of any Scrum process to be observed by anyone. Inspection: • Use of a common Scrum Board and other information radiators. Adaptation: • Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing.
- 16. Collaboration
- 18. Time-Boxing
- 22. Scrum Master
- 23. Ball Point Game Image Source: http://puppytoob.com/wp-content/uploads/2013/07/Dog_Tennis_Ball_1.jpg
- 25. The Rules • Everyone is part of one big team. • Each ball must have air-time. • Each ball must be touched at least once by every team member. • Balls cannot be passed to your direct neighbor to your immediate left or right. • Each ball must return to the same person who introduced it into the system. • There are a total of five iterations two minutes each.
- 28. Product Owner
- 29. CEREMONIES Scrum
- 31. Sprint Planning
- 32. Daily Stand Up
- 34. Scrum Framework
- 35. User Stories Context AS A … (user of the system) I WANT … (feature or problem to be solved) SO THAT I … (benefit of story being completed) The “so that” part is incredibly valuable as it focuses people on the real reason behind this story.
- 36. INVEST Acronym
- 37. Why?
- 38. User Story Game
- 40. Poker Planning
- 44. 10MIN
- 45. #1 – Absolute Estimation Beagle 11 Labrador 32 Great Dane 91 Chihuahua 2 Appalachian Mountain Dog - American Cocker Spaniel 14 Border Collie 20 Staffordshire Bull Terrier 17 What did we learn?
- 47. 10MIN
- 48. #2 – Relative Estimation Impala 13 Elephant 40 Giraffe 20 Elephant Shrew 2 Crocodile 8 Snake 3 What did we learn?
- 50. 10MIN
- 51. #3 – Planning Poker Spain 5 China 40 Luxembourg 1 Denmark 3 South Africa 13 Belize 2 What did we learn?
- 53. 10MIN
- 54. #4 – Affinity Estimation Convertible S Motorbike XS Starship Enterprise XL SUV S MINIVAN S BUS M What did we learn?
- 56. Definition of Done aka DoD • The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment "often a user story" is considered "done". • On a feature level, the acceptance criteria should be agreed up front BEFORE the User Story is submitted to acceptance.
- 57. Definition of Ready aka DoR • By analogy with the "Definition of Done", the team makes explicit and visible the criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration. • On a feature level, the acceptance criteria should be agreed up front BEFORE code is written.
- 58. Visibility of Progress • Team has a duty to radiate information outwards! • It also helps reduce interruptions! – Scrum and Kanban Physical Boards – Big visible charts (Ex: CFS’s, Burn Down, Etc) – On-line Tools (Ex: Rally Dev) – Daily reporting
- 59. Examples
- 61. Marshmallow Game Objective Build the Tallest Freestanding Structure: The winning team is the one that has the tallest structure measured from the table top surface to the top of the marshmallow. That means the structure cannot be suspended from a higher structure, like a chair, ceiling or chandelier.
- 62. The Rules • The entire marshmallow needs to be on the top of the structure. Cutting or eating part of the marshmallow disqualifies the team. • The team can use as many or as few of the 20 spaghetti sticks, as much or as little of the string or tape. • Teams are free to break the spaghetti, cut up the tape and string to create new structures. • The Challenge Lasts 18 minutes: Teams cannot hold on to the structure when the time runs out. Those touching or supporting the structure at the end of the exercise will be disqualified.
- 66. Scrum Smells aka Anti-Patterns • Scrum Master or any other team member assigning work. • Daily Scrum is for the Scrum Master or any other specify person. • Sprint work being carried over. • Test sprints. • Everything “In-progress”. • SM/ DM/ PO or anyone else providing estimates for the team.