Download as KEY, PPTX
Uploaded byAndré Heijstek
Agile intro module 1
This document provides an introduction to agile principles and Scrum methodology. It defines key Scrum roles like Product Owner and Scrum Master. It also explains common Scrum ceremonies such as sprint planning, daily stand-ups, sprint reviews and retrospectives. Artifacts like the product backlog, sprint backlog and burn down charts are also described. The document aims to give trainees an overview of agile and Scrum concepts to help them apply these principles.
More Related Content
Agile intro module 1
- 1. Agile Introduction Module 1 - General introduction 1
- 2. Agile according toDilbert 2
- 3. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 3
- 4. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 4
- 5. User Story As a trainee I want to understand Agile principles To be able to apply Agile in various situations 5
- 6. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 6
- 7. 12 principles Our highest priority is to satisfy the customer Working software is the primary 1 measure of progress. 7 through early and continuous delivery of valuable software. Agile processes promote sustainable Welcome changing requirements, even late in development. The sponsors, developers, 2 and users should be able to maintain a 8 development. Agile processes harness change for the customer's competitive advantage. constant pace indefinitely. Continuous attention to technical Deliver working software frequently, from a 3 excellence and good design enhances 9 couple of weeks to a couple of months, with a agility. preference to the shorter timescale. Simplicity--the art of maximizing the Business people and developers must work 4 amount of work not done--is essential. 10 together daily throughout the project. The best architectures, requirements, Build projects around motivated individuals. 5 and designs emerge from self-organizing teams. 11 Give them the environment and support they need, and trust them to get the job done. At regular intervals, the team reflects The most efficient and effective method of on how to become more effective, then 6 tunes and adjusts its behavior 12 conveying information to and within a development team is face-to-face conversation. accordingly. 7
- 8. Agile - protestmovement • Against: • waterfall development • micro management • disdain for craftsmanship of developers 8
- 9. Principles no Rules • YAGNI - you ain’t gonna need it • BDUF - big design up front • BPUF - big planning up front • Simplicity - the art of maximizing the amount of work NOT done • Fail fast 9
- 10. Other planning principles Scope FIXED ESTIMATE Traditional Time Cost 10
- 11. Other planning principles Scope Time Cost FIXED Agile ESTIMATE Traditional Time Cost Scope 10
- 12. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 11
- 13. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 12
- 14. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 13
- 15. User Story As a trainee I want to know what Scrum is and XP Because I might start applying it 14
- 16. Scrum • PROJECT MANAGEMENT approach • So, same goals as Prince2 • But, a completely different approach! 15
- 17. The big picture Image available at www.mountaingoatsoftware.com/scrum
- 18. Scrum framework Roles • Product owner • ScrumMaster Ceremonies • Team • Release planning • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts • Definition of Done 17
- 19. Scrum framework Roles • Product owner • ScrumMaster Ceremonies • Team • Release planning • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts • Definition of Done 18
- 20. Product owner • Definethe features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Accept or reject work results Mountain Goat Software, LLC
- 21. The ScrumMaster • Representsmanagement to the project • Responsible for enacting Scrum values and practices • Removes impediments • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences Mountain Goat Software, LLC
- 22. The team • Typically5-9 people • Cross-functional: • Programmers, testers, user experience designers, etc. • Members should be full-time • May be exceptions (e.g., database administrator) • Teams are self-organizing • Ideally, no titles but rarely a possibility • Membership should change only between sprints Mountain Goat Software, LLC
- 23. Scrum framework Roles • Product owner • ScrumMaster Ceremonies • Team • Release planning • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts • Definition of Done 22
- 24. Release Planning Product Vision 1 2 3 4 5 6 7 8 User User User User Story Story Story Story Epic User User User User Epic Story Story Story Story Epic Epic User User User User User Story Story Story Story Story User User User User User User Story Story Story Story Story Story 23
- 25. Release Planning Product Vision 1 2 3 4 5 6 7 8 User User User User Story Story Story User stories are the Story Epic Agile way of documenting User User User User Story Story Story requirements. Epic Story As a <user role> Epic Epic User User User User User Story Story Story I want <something> Story Story So I can achieve <value> User User User User User User Story Story Story Story Story Story 23
- 26. Sprint planning meeting Team capacity Product backlog Business conditions Current product Technology 24
- 27. Sprint planning meeting Team capacity Sprint prioritization Product • Analyze and evaluate product backlog backlog • Select sprint goal Business conditions Current product Technology 24
- 28. Sprint planning meeting Team capacity Sprint prioritization Product • Analyze and evaluate product Sprint backlog backlog goal • Select sprint goal Business conditions Current product Technology 24
- 29. Sprint planning meeting Team capacity Sprint prioritization Product • Analyze and evaluate product Sprint backlog backlog goal • Select sprint goal Business conditions Sprint planning • Decide how to achieve sprint Current goal (design) product • Create sprint backlog (tasks) from product backlog items (user stories / features) Technology • Estimate sprint backlog in hours 24
- 30. Sprint planning meeting Team capacity Sprint prioritization Product • Analyze and evaluate product Sprint backlog backlog goal • Select sprint goal Business conditions Sprint planning • Decide how to achieve sprint goal (design) Current Sprint product • Create sprint backlog (tasks) from product backlog items (user backlog stories / features) Technology • Estimate sprint backlog in hours 24
- 31. Sprint planning • Team selects items from the product backlog they can commit to completing • Sprint backlog is created • Tasks are identified and each is estimated (1-16 hours) • Collaboratively, not done alone by the ScrumMaster • High-level design is considered As a vacation Code the middle tier (8 hours) planner, I want to Code the user interface (4) Write test fixtures (4) see photos of the Code the foo class (6) hotels. Update performance tests (4) 25
- 32. The daily scrum • Parameters • Daily • 15-minutes • Stand-up • Not for problem solving • Whole world is invited • Only team members, ScrumMaster, product owner, can talk • Helps avoid other unnecessary meetings 26
- 33. Everyone answers 3questions 1 What did you do yesterday? 2 What will you do today? 3 Is anything in your way? • These are not status for the ScrumMaster • They are commitments in front of peers 27
- 34. The sprint review • Team presents what it accomplished during the sprint • Typically or underlying architecture of new features takes the form of a demo • Informal • 2-hour prep time rule • No slides • Whole team participates • Invite the world 28
- 35. Sprint retrospective • Periodically take a look at what is and is not working • Typically 15–30 minutes • Done after every sprint • Whole team participates • ScrumMaster • Product owner • Team • Possibly customers and others 29
- 36. Start / Stop/ Continue • Whole team gathers and discusses what they’d like to: Start doing Stop doing This is just one of many ways to Continue doing do a sprint retrospective. 30
- 37. Scrum framework Roles • Product owner • ScrumMaster • Team Ceremonies • Sprint planning • Sprint review • Sprint retrospective • Daily scrum meeting Artifacts • Product backlog • Sprint backlog • Burndown charts • Definition of Done 31
- 38. Product backlog •The requirements •A list of all desired work on the project •Ideally expressed the users each item has value to such that or customers of the product • Prioritized by the product owner This is the • Reprioritized at the start of each sprint product backlog 32
- 39. A sample productbacklog Backlog item Estimate Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a 3 reservation. As a hotel employee, I can run RevPAR reports 8 (revenue-per-available-room) Improve exception handling 8 ... 30 Or use T-Shirt ... sizes (S/M/L) 50 33
- 40. The sprint goal • A short statement of what the work will be focused on during the sprint Life Sciences Support features necessary for Database Application population genetics studies. Make the application run on SQL Server in addition to Oracle. Financial services Support more technical indicators than company ABC with real-time, streaming data. 34
- 41. Managing the sprintbacklog • Individuals sign up for work of their own choosing • Work is never assigned • Estimated work remaining is updated daily • Any team member can add, delete or change the sprint backlog • Work for the sprint emerges • If work is unclear, define a sprint backlog item with a larger amount of time and break it down later • Update work remaining as more becomes known 35
- 42. A sprint backlog User Story Mon Tue Wed Thu Fri As a user ... borrow item ... return item ... search for books ... find other books / author ... find book reviews 36
- 43. A sprint backlog User Story Mon Tue Wed Thu Fri As a user ... borrow item 8 ... return item 16 ... search for books 8 ... find other books / author 12 ... find book reviews 8 36
- 44. A sprint backlog User Story Mon Tue Wed Thu Fri As a user ... borrow item 8 4 ... return item 16 12 ... search for books 8 16 ... find other books / author 12 ... find book reviews 8 8 36
- 45. A sprint backlog User Story Mon Tue Wed Thu Fri As a user ... borrow item 8 4 8 ... return item 16 12 10 ... search for books 8 16 16 ... find other books / author 12 ... find book reviews 8 8 8 ... read magazines 8 36
- 46. A sprint backlog User Story Mon Tue Wed Thu Fri As a user ... borrow item 8 4 8 ... return item 16 12 10 4 ... search for books 8 16 16 11 ... find other books / author 12 ... find book reviews 8 8 8 8 ... read magazines 8 4 36
- 47. A sprint backlog User Story Mon Tue Wed Thu Fri As a user ... borrow item 8 4 8 ... return item 16 12 10 4 ... search for books 8 16 16 11 8 ... find other books / author 12 ... find book reviews 8 8 8 8 8 ... read magazines 8 4 36
- 48. A sprint burndownchart 1,000 800 600 Hours 400 200 0 4/29/02 5/6/02 5/13/02 5/20/02 5/24/02 37
- 49. Tasks Mon Tues Wed Thur Fri Code the user interface 8 Code the middle tier 16 Test the middle tier 8 Write online help 12 50 40 Hours remaining 30 20 10 0 Mon Tue Wed Thu Fri 38
- 50. Tasks Mon Tues Wed Thur Fri Code the user interface 8 Code the middle tier 16 Test the middle tier 8 Write online help 12 50 40 Hours remaining 30 20 10 0 Mon Tue Wed Thu Fri 38
- 51. Tasks Mon Tues Wed Thur Fri Code the user interface 8 Code the middle tier 16 Test the middle tier 8 Write online help 12 50 40 Hours remaining 30 20 10 0 Mon Tue Wed Thu Fri 38
- 52. Tasks Mon Tues Wed Thur Fri Code the user interface 8 4 Code the middle tier 16 12 Test the middle tier 8 16 Write online help 12 50 40 Hours remaining 30 20 10 0 Mon Tue Wed Thu Fri 38
- 53. Tasks Mon Tues Wed Thur Fri Code the user interface 8 4 Code the middle tier 16 12 Test the middle tier 8 16 Write online help 12 50 40 Hours remaining 30 20 10 0 Mon Tue Wed Thu Fri 38
- 54. Tasks Mon Tues Wed Thur Fri Code the user interface 8 4 Code the middle tier 16 12 Test the middle tier 8 16 Write online help 12 50 40 Hours remaining 30 20 10 0 Mon Tue Wed Thu Fri 38
- 55. Tasks Mon Tues Wed Thur Fri Code the user interface 8 4 8 Code the middle tier 16 12 10 7 Test the middle tier 8 16 16 11 8 Write online help 12 50 40 Hours remaining 30 20 10 0 Mon Tue Wed Thu Fri 38
- 56. Definition of Done • Wanneer is een taak (een stuk code) af? 39
- 57. Definition of Done From a presentation by Ken Schwaber: 1. I can readily understand the software and where and how things happen; 2. When I change or add to part of the software, there are no unintended or poorly designed dependencies; 3. I can read the code without lookin for tricks or poorly defined and • labeled variables or is een taak (een stuk code) af? Wanneer data; 4. I don’t need the person(s) who wrote the code to explain it to me; 5. There are a full set of (automated) tests to check that the function works as expected; 6. When I change something and add to the test, I can check that the entire change and product continuous to work; 7. How thing work and hang together is transparent, and 8. Standard, well-known design principles have been adhered to. 39
- 58. Responsibilities Team PO Scrum Master
- 59. XP - eXtremeProgramming • DEVELOPMENT approach 41
- 60.
- 61. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 43
- 62. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 44
- 63. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 45
- 64. User Story As a trainee I want to brainstorm about opportunities and risks of Agile Because there’s a trainer around Because that helps to sink in the ‘slideware’ Because I will also run into these issues when implementing in my company 46
- 65. Retrospective • Workshop • 3 groups, 2x10 minuten • “What has made me really thrilled, what will I start using tomorrow” • “This is never going to work, because ...” 47
- 66. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 48
- 67. Sprint Backlog TO-DO IN WORK DONE What is Agile? Scrum and XP Usage & risks 49
- 68. Credits • Several slides have been taken from the Redistributable Scrum Introduction - Scrum Alliance 50
Editor's Notes
- #2 \n
- #3 \n
- #4 \n
- #5 \n
- #6 \n
- #7 Manifesto brengt spirit in Scrum. Infusion.\n\nProcessen en tools zijn prima, maar we zijn, door teveel focus hierop, wel eens vergeten dat software ontwikkeld wordt door vakmensen, en dat zij echt met elkaar in gesprek moeten gaan.\n\nDocumentatie is belangrijk, maar werkende software nog meer. Bij traditionele milestones werd alleen maar papier opgeleverd.\nOnderzoek naar re-use van software heeft aangetoond dat documentatie over designs maar een heel beperkt nut heeft. Alleen praten met de oorspronkelijke ontwikkelaars over het idee achter het design, en discussie met hen over waar een uitbreiding het beste geplaatst kon worden leidt tot een efficient ontwerp.\nVoorbeeld Wittgenstein - beschrijf een stoel, beschrijf het geluid van een klarinet.\n\nIn contracten met KPI&#x2019;s kan alles dichtgetimmerd worden, waardoor het contract belangrijker wordt dan het tevredenstellen van de klant. Angstcultuur, afrekencultuur zijn het gevolg.\n\nWees realistisch, in vrijwel elk project zal er verandering komen. En dat is goed. Voortschrijdend inzicht van de klant (ik wil eigenlijk iets anders) of van de ontwikkelaars (we weten een slimmere manier) is alleen maar goed. Krampachtig vasthouden aan het oude plan is dan stompzinnig.\n
- #8 \n
- #9 \n
- #10 \n
- #11 \n
- #12 \n
- #13 \n
- #14 \n
- #15 \n
- #16 \n
- #17 \n
- #18 \n
- #19 \n
- #20 \n
- #21 \n
- #22 Manifesto: working software, customer collaboration, responding to change\n12 Principles:\n- early and continuous delivery\n- changing requirements\n- deliver frequently\n- business and developers work together daily\n- face-to-face communication\n- working software is primary measure of progress\n- self-organising teams\n- regular self-reflection\n
- #23 \n
- #24 \n
- #25 Manifesto: customer collaboration\n12 Principles:\n- business and development work together\n
- #26 Impediments\n- risks\n- issues\n- meteen oppakken, niet op een lijstje zetten\n- concreet\nNIET - er is een kans dat we te weinig resources hebben\nWEL - als Judy het grafisch ontwerp niet af krijgt, kunnen we dit item niet leveren\n
- #27 Manifesto: individuals and interactions\n12 Principles:\n- motivated individuals\n- face-to-face communication\n- self-organising teams\n
- #28 PO and SM roles MAY NOT overlap\nPO and SM may be team members\n
- #29 \n
- #30 Note that there should also be a Release Vision.\n
- #31 Manifesto: customer collaboration\n12 Principles:\n- deliver frequently\n- business and development work together\n- face-to-face\n- simplicity\n
- #32 Manifesto: customer collaboration\n12 Principles:\n- deliver frequently\n- business and development work together\n- face-to-face\n- simplicity\n
- #33 Manifesto: customer collaboration\n12 Principles:\n- deliver frequently\n- business and development work together\n- face-to-face\n- simplicity\n
- #34 Manifesto: customer collaboration\n12 Principles:\n- deliver frequently\n- business and development work together\n- face-to-face\n- simplicity\n
- #35 \n
- #36 Pigs and Chickens verhaal vertellen\n\nManifesto: interactions\n12 Principles:\n- motivated individuals\n- face-to-face\n- self-organising\n
- #37 \n
- #38 Manifesto: working software\n12 Principles:\n- early and continuous delivery\n- deliver frequently\n- business and development work together\n- motivated individuals\n- face-to-face\n- working software\n\n
- #39 Manifesto:\n12 Principles:\n- regular intervals, reflect\n\n
- #40 \n
- #41 \n
- #42 Manifesto: collaboration vs. contract\n12 Principles:\n- changing requirements\n- business and development\n\n
- #43 \n
- #44 \n
- #45 Manifesto:\n12 Principles:\n- self-organisation\n
- #46 Let op: het is beter tracking te doen per User Story dan op individuele taken\n
- #47 Let op: het is beter tracking te doen per User Story dan op individuele taken\n
- #48 Let op: het is beter tracking te doen per User Story dan op individuele taken\n
- #49 Let op: het is beter tracking te doen per User Story dan op individuele taken\n
- #50 Let op: het is beter tracking te doen per User Story dan op individuele taken\n
- #51 Opmerking: er is een Sprint burndown en een Release burndown.\n
- #52 \n
- #53 \n
- #54 \n
- #55 \n
- #56 \n
- #57 \n
- #58 \n
- #59 \n
- #60 \n
- #61 \n
- #62 \n
- #63 \n
- #64 \n
- #65 \n
- #66 \n
- #67 \n
- #68 \n
- #69 \n
- #70 \n
- #71 \n
- #72 \n
- #73 \n
- #74 \n
- #75 \n
- #76 \n
- #77 \n
- #78 \n
- #79 \n
- #80 \n
- #81 \n
- #82 \n
- #83 \n
- #84 \n
- #85 \n
- #86 \n
- #87 \n
- #88 \n
- #89 \n
- #90 \n