Course 670 Agile Project Management with Scrum& active \learning = Course 670: Agile Project Management with Scrum 08/01/19Agile Project Management with Scrum Philippine Copyright © 2019 by ActiveLearning, Inc, Allrights reserved. Printedin the Philippines. No part ofthis book may be used or reproduced in any form or by any means, or stored ina database or retrieval system without prior written permission ofthe publisher except inthe case of bref quotations embodied in critica articles and reviews. Making copies of any part this book for any purpose other than your wn personal use isavolationof Philippine copyright laws. For information, please contact ActiveLearning, Ine, 2nd Floor Home Studio Building 63 Connecticut St. Greenhills, San Juan, Philippines. T: 726-8128. This bookis sold as is, without warranty of any kind, either expressed or implied. While every precaution has been taken inthe reparation ofthis book, the author and ActiveLearning, Inc. assume no responsitilit for errors or omissions. Neither ie any liability assumed for damages resulting from the use ofthe information or instructions herein. Itisfurther stated thatthe publisher and authors are not responsible for any damage o loss to your data or your equipment that results diectly ar indirectly from your use of this book. [ACTIVELEARNING, INC. 2nd Floor Home Studio Building 63 Connecticut st. Greenhills, San Juan Philippines 1:4692 726-8128 E-mail: info@activelearning ph Web wnactivelearning phCourse 670 Agile Project Management with Scrum Table of Contents Chapter 1 Whatis Agile? Chapter 2 © What is Scrum? Chapter 3 Roles and Responsibilities Chapter 4 — Elements of Scrum Chapter5 Meetings Chapter6 = ConclusionChapter 1 What is Agile? Cactive \Jeaming Agile Definition = “Agile Software Development is a group of software development processes based on iterative and incremental development where requirements and solutions evolve through collaboration between self-organising, cross-functional teams." Source: Wikipedia: Agile Software Development Q 670-1-2Agile Methodologies . Extreme Programming (XP) * Kanban * Lean * Crystal And of course... + SCRUM! ‘©Copyright ActiveLearing I Ale 670-1-3 = Silver Bullets (or Lack thereof...) . Therei is no Silver Bullet, one shot, cure-all for problems ina company or organization. * The best solution can often be a combination of different techniques, methodologies and frameworks. * If it’s working, continue doing it. If it’s not working, try something else. ©Copyright ActiveLeaning Inc Alright esrved.Nottobereproducedwithout peor witen consent. 670-1-4| Common Reasons for Project Failure * Poor requirements + Poor estimations leading to unrealistic schedules + Handling specification changes poorly + Poor testing + Rigid development process + Little to no customer involvement - Poor development techniques 2 a a ~< (active \leaming Aight 670-15 The Agile Solution * Problem: Poor requirements - on: Team checks requirements together and discuss each feature to learn more about it through collaboration. + Problem: Poor estimations leading to unrealistic schedules -Ag Team is trusted to make estimates and give own schedule of delivery. + Problem: Handling specification changes poorly 7 on: Change is welcomed - Peete oer aul + Problem: Poor testing ean” ae (aon 2 - Thorough testing is part of each re lease cycle ~ Gq active learning ©Copyright Acivetearing. ne Alright reserved 670-1-6The Agile Solution - — eaten . * Rigid development process : Lightweight development process * Little to no customer involvement | ~ Solution: Involve the customer as much as possible at every stage * Poor development techniques - »: Pair programming, code reviews, unit testing ”coprieh Acta nc Alen eve Notte efecto pretreat 670-1-7 Agile Manifesto * The Agile Manifesto values: ~ Individuals and interactions over processes and tools ~ Completed work over comprehensive documentation ~ Customer collaboration over contract negotiation ~ Responding to change over following a plan > Westill value the things on the right but we focus more on the things on the left. — Qt: {©Copyright ActveLearning ne Alrights reserved Nol tobe reproduced without ror writen consent. 670-1-8Agile Manifesto Principles | 1. Satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements - “ft + ¢# Deliver working software frequently Business people and developers work together Build projects around motivated individuals aa kN The most efficient and effective way to convey information to and within a development team is facertorface Pou, a Che | conversation \leaming ighs reserved reproduced wi 670-1-9 Agile Manifesto Principles (Continued) 7. Working software is the primary measure of progress 8. Sustainable development - -« °4y 9. Continuous attention to technical excellence 10. Simplicity is essential 11. The best architecture, requirements and designs emerge we pattie from self-organizing teams - “" °* rade Pe Oy boy ed 12. Reflect regularly on how to become more effective Q Bective | — leeming | ar0-4-40History of Agile Development Year Milestone 1957 Notion of Iterative Development - Weinberg at IBM 1970 “Managing the Development of Large Software Systems ” ~ Royce, describes an iterative waterfall 1976 “Software Metrics ”- Glib, describes iterative and incremental development system as “evolutionary”. Recognizes that “a complex system will be most successful if it is implemented in small steps” “active - 50 a at oamec atmatmmennconnmmrernaemraN ge Ae FANS HSN saan learning {©Copyright Activelearing In Allights reserved Netto berepreduced without rir written consent 670-1-11, = ot History of Agile Development (Continued) Year Milestone y 1980s | NASA and other companies successfully uses iterative development to deliver projects 1986 “Scrum” first described in “The New New Product Development Game” - Takeuchi and Nonaka 1990s Sutherland and Schwaber start to apply Scrum method 2001 17 people meet to write the Agile Manifesto Leaning, ne Alrights reserved Nt tobe reproduced without prior written consent. 670-1-12 = Gees reChapter 2 What is Scrum? (rere leaning Definition of Scrum = “Scrum is designed for any team that needs to get work done faster, with higher quality and in a way that makes the end users and the customers happy with the result” - Jeff Sutherland “Scrum is a framework for developing complex products and systems. It is grounded in empirical process control theory. Scrum employs an iterative, incremental approach to optimize predictability and control risk.’ - Ken Schwaber bctive aes veLeaning, In Alright reserved. Not to be reproduced without prior writen consent 670-2-2Key Points in Scrum Predictive Start with plan End with ail | and all ecient requirements complete Scrum - Empirical Start with goals End with and some priority goals met requirements “Source: Bas Vodde ie: active es | NiCSITINg ©Copyright ActiveLearing nc Aleights reserved Not tobe reproduced without pir written consent. 670-2-3 Empirical Process Control + Frequent inspection and adaptation of process for optimization * Requires transparency and honesty * Continuous improvement ‘active learning © Copyright ActveLearning Inc Alright reserved Not tobe reproduced without prior written consent 670-2-4 =Spore + wea your Fetlny bday AT wre yd tthe 4 PRODUCT END PRODUCT BACKLOG. active — learning ‘copy ActveLaring Ins Avg reserved Not tobe reproduced without ir ten consent 670-2-5 a ae Sprint 1 day Sprint review 1 day Sprint planning meeting and retrospective (4h/4h) Dai cia scrum. (4h/ 3h) =>. = 85-4 Teh the a | YW Development Work 1-4 weeks at a sustainable pace *Source: Pyxis Technologies ‘©Copyright ActiveLearing. ne Al ight reserved, Not tobe reproduced without prior writen consentsour %_Setet © banks Sprint a 8 co ‘active ots 670-3-14 s ‘©Copyright Activeearing. ne. Alright reserved ced without prior writen consent.ScrumMaster: In Depth » Making the change is hard. * From command and control to facilitation. * 1ScrumMaster per team and 1 team per ScrumMaster ‘Scop Atv reared Not tobe repedved out pr wen consent ee ScrumMaster: What Does He Do All Day? * Find out what there is to do. * How is my Product Owner doing? ~ Is the Product Backlog up to date? Prioritised? Clear? ~ Is he updated with the velocity of the team? * How is my team doing? ~ Are they working well together? ~ Are there any conflicts they need help resolving? ~ Are they communicating properly? So ‘active learning \ o ls 670-3-16SMe pe a Kam — Ten or heh ScrumMaster: ane mre eechat oe He Do} All Day? . Don’ t know what to do? Ask the ‘team! ~ Inoticed , what shall we do? ~ Shall we try to find out why ? - lobserved , is that important? Ce ‘active ——— leering ‘© opyrihtAtivelerig nc Nigh reserved Noto be eyed int pr ten consent 670-3-17 Product Owner = . Prioritizes s features according to business value - Decides on release dates + Can change features every sprint | + Responsible for ROI of the product | © Responsible for reviewing the product at regular intervals \° Gives vision of product + Is not allowed to interfere during a sprint + Must give prompt answers to queries from the team Gtens 670-3-18[ | Exercise: What Would a Good ScrumMaster Do? * Scenario #1: ~ The Team is frequently failing to deliver on their commitments, working over time and not enjoying the Scrum process at all. * Scenario #2: ~ During a Sprint, the Product Owner constantly asks the team when they can deliver a feature to her. by Te He eng of TR ferint * Scenario #3: ~ Product Owner calls you and says she won't be able to answer any questions this week as she’s very, busy. Le Adalyy hb Under Dube abs’ g ferry . eer ‘itive Sie Goats corre tnt be gis ora he bere uabn ptr eir omer 670-3-19 i i wR Gt bh beads Grate Exercise: ook wu ee _What Would a Good ScrumMaster Do? (Continued) . Scenario #4; ~ One team member often leaves the team to go and work on a previous project m with his old team. Conte gles Cy & Sab e ry s ve faba * Scenario #5: ~ Product Owner often doesn't reply to the team’s questions until 24 hours after they've been asked. + Scenario #6: ~The Team is very quiet and don’t talk to each other during the working day. ay Uyptid ode ely Lfesanal send ATE beake ; |___ecconyiatActiveLeaming ln Al ight reserved. Noto be reproduced without pir written consentExercise: | What Would a Good Team Do? . Scenario #1: ~ One team member spends the working day browsing the internet and watching Youtube videos lot hoe Th la maybe Wy te Seeking Rte (apaiale (roster, yk ley Gn webily re oon te tak + Scenario #2: ~ The ScrumMaster assigns tasks to Team members and asks the Team for a status report every evening Ny Geb em ed py + Scenario #3: ~ During a Sprint, the specification of a task is unclear Gy Wem nateber | fo Gets 670-3-21 Exercise: What would a Good Product Owner Do? . Scenario #1: ~ During a Sprint, many specification changes often occur Eng yous shteloldes bet Hane yore galt de We * Scenario #2: ~ At the end of a Sprint, the committed deliverables by the Team are often incomplete or are missing key features Woe + hece ot fee ine ph Qwik God -A jek fe a .Don'ts of a ScrumMaster - Don’ t manage your team * Don't interrupt your team unnecessarily * Don’t allow upper management to interfere + Don't settle for Scrum-But * Don't ignore your team * Don't ignore your team’s problems * Don't spread yourself too thinly ‘active leering opr aceieanng ne Agha Nt ob padsend wou pr eter 670-3-23 Don'ts of a Product Owner . Don’ ‘t make changes during a sprint * Dor’t interrupt your team during a sprint * Don't forget to prepare the Product Backlog in advance + Don't forget to ask the team’s opinion if you're not sure of a feature * Don’t push your team to develop at an unsustainable pace * Don't accept incomplete work at the end of a Sprint * Don't forget that the success of the project depends on you _ Css 670-3-24 ialHow to select a Product Owner . "Product Owner i is ultimately responsible for the project + Have understanding of project management * Good interpersonal skills + Be able to handle pulling vs pushing the team + Understand the customer + Understand the product ‘tive — \teaming 670-3-25 = How to Select a Scrum Master a earn e « Responsible for successful ee of Scrum * Humble “Look what I helped accomplish” vs “Look what | accomplished” + Ability to create a collaborative culture + Committed + Influential with the team and outside of the team Source: Mike Cohn, Mountain Goat Software: Qs Ativelzaming, ne Alright reserved, Not tobe reproduced without rior written consent. 670-3-26Test Your Knowledge Te en, sears PETE What isthe ideal size of ateaminScrum? ~ 3 » q What are the main roles in Scrum? Who is responsible for implementing Scrum in an organization? 4. In your opinion, what is the most useful meeting in Scrum? What does the Project Manager doin Scrum? ma ONE wa sctve ee Costs copia tvanng i pra ha sbenposa then io ammreeae wosChapter 4 Elements of Scrum Elements of Scrum User Stories Product Backlog — twiywasshieae omar Ay Story Points » Sprint Backlog » Taskboard Definition of Done Burndown Chart Burnup Chart Release Plan » Abnormal Sprint Termination : Ghats {© Copyright ActiveLearng Inc. Alright reserved Noto be reproduced without rior written consent 670-4-2Elements of Scrum: User Stories SHE » User stories describe each feature in the project - Make up the product backlog » Are short and easy to understand for all parties (technical/non-technical) Ceetive \ learning ©Copyright ActiveLearning, Inc. All rights reserved, Not to be reproduced without prior written consent. 670-4-3 = Ideal format of User Stories “As a [role], | want to [function] so that [rationale/business value].” ~ Example: * Asaconference attendee, | want to be able to register online, so that I can register quickly and cut down on paperwork | @ | Rretve learning ©Copyright ActiveLeaming, ne Alright reserved Nott be reproduced without rior written consent 670-4-4User Stories Acceptance Criteria - Each user story should have acceptance criteria » Used in Sprint Review when demoing the feature ©Copyright ActiveLearing, ne Alright reserved Nottobe reproduced without pie written consent 670-45 G Sctive \ learning User Stories Acceptance Criteria For the user story ~ ‘As aconference attendee, | want to be able to register online, so | can register quickly and cut down on paperwork.” The acceptance criteria might be: e Auser cannot submit a form without completing all the mandatory fields ¢ Information from the form is stored in the registrations database e Protection against spam is working e Payment can be made via credit card e Anacknowledgment email is sent to the user after submitting the form. {©Copyright Acivelaring nc Alights reserved Noto be reproduced without prior writen consent 670-4-6 ‘cy \esmingElements of Scrum: User Stories #0001 USER LOGIN Fibonacci S As a [registered user], | want to [log in], so | can [access subscriber content]. User Stories Acceptance Criteria Confirmation: 1. Success - valid user logged in and referred to home page. a) ‘Remember me’ ticked - store cookie / automatic login next time. b) ‘Remember me’ not ticked - force login next time 2. Failure - display message: a) ‘Email address in wrong format’ | b) ‘Unrecognised user name, please try again’ c) ‘Incorrect password, please try again’ d) ‘Service unavailable, please try again’ e) Account has expired - refer to account renewal sales page Source; wonalapoutagiecon Gebeteg a a ee User's email address. | Username: oan | F Password: | | serecoouen | epee rar} atte | crsemtiet | BS [toein |] yoscoans icon er ae | oat | eke eerie dey ramage hare Woot rma ercenrmatoe antes on Source: vnvwallaboutagile.com (2 active ‘learning ©Copyright ActiveLearning, Inc. All rights reserved. Not to be reproduced without prior written consent. 670-4-7 bad Elements of Scrum:Elements of Scrum: User Stories Guidelines for creation from Bill Wake: Alluser stories should be: Independent Negotiable Valuable Estimable Smali Testable baritian 62d = Dawber b Cretve \\learning ©Copyright ActiveLeaming. inc. All rights reserved. Not to be reproduced without prior written consent. 670-4-9 al Elements of Scrum » User Stories * Product Backlog » Story Points » Sprint Backlog * Taskboard * Definition of Done Burndown Chart » Burnup Chart ~ Release Plan » Abnormal Sprint Termination (Oe (Gj Bective learning {Copyright Activelearing. nc. Allright reserves Noto be reproduced without rior writen const 670-4-10_I » List of all functionality required in the product » Enough task detail is added for at least the next sprint * Can be technical tasks ~ “Refactor login class” * Can be user-centric ~ ‘Allow undo on setup screen” * Ordered by priority » Asitems become higher priority, more detail is added Crete \leaming _©.Copyright ActiveLearning. Inc. All rights reserved, Not to be reproduced without prior written consent. 670-4-11 = Elements of Scrum: Product Backlog ) Fine-grained, detailed items ready > for consumption in the next iteration 2 i.e., small user stories \ Medium-grained items | ie, larger user stories Coarse-grained items | ive., epics (G active learning 670-4-12 Elements of Scrum: Product Backlog Ss = |Elements of Scrum: Product Backlog * ScrumMaster works with the Product Owner to groom the backlog in preparation for next sprint Re-order, prioritise and clarify items » Agroomed product backlog must be ready for the sprint planning meeting » During Sprint A, prepare backlog for Sprint B | » Product Owner needs to know how large a feature is so that Scar Eke UEC . clive learning © Copyriht Activating ne lights rererved. Not tobe reproduced without rior writen consent 670-4-13 = Elements of Scrum: Product Backlog » Why Prioritize? ~ Avoid “everything is urgent” ~ Force Product Owner to think about importance in terms of business value ~ Team needs to know what to work on first | ‘active \esmaing © conyiht ctiveearing ne Argh reserve. Noto be reproduced witout rir writen consent 670-4-14Elements of Scrum: Product Backlog » Product Backlog Checklist: ~ Stories are estimated ~ Stories are prioritized ~ Stories have sufficient detail (6 active learning {© Copyright ActiveLearing ne. Alright reserved, Not tobe reproduced without ror writen consent 670-4-15 2 Exercise: Generate Product Backlog Items * Goal: Familiarity with user stories and acceptance criteria Look at requirements for PBATix Select functional and non-functional requirements Write one user story (and its acceptance criteria) for each item ona card ve wo Cactive leering 3 Allrights reserved. Noto beeprodued without ror writen consent 670-4-16Exercise: Assign Value to Product Backlog Items I | Goal: Familiarity with the Product Backlog concept ~ Assign a value to each of the items ~ Value is in terms of business value to the client G Sctive learning {©Copyright ActiveLearing nc Alright reserved Notto be reproduced without rior written consent 670-4-17 = Elements of Scrum » User Stories » Product Backlog | Story Points Sprint Backlog » Taskboard » Definition of Done » Burndown Chart > Burnup Chart » Release Plan » Abnormal Sprint Termination ~ GSctive \lesming ©Copyright Activelearing ne Alright eteved Not tobe reproduced without pie writen consent. 670-4-18|__ ecopwrict Actveearning. ne Al Story Points » Astory point is an arbitrary number applied to a user story that indicates approximately how much effort is required to complete the story relative to other stories. Way of estimating without committing to a specific duration so e.g. team size does not affect the size of the story. - Are used to calculate the team’s “velocity” - which can give a rough indicator of how quickly a project can be developed. (active \Jeamning ts reserved. Noto bereraduced without rior written consent. 670-4-19 Story Points » Need to keep the team together for it to have any meaning. * This can be difficult depending on your organisation. ©Copyright ActiveLeaming Inc Allrghsreservad.Nottobereproducedwithoutpriorwrittanconsent. 6 70-4-20Velocity After the first sprint you will see how many story points were completed. » It will be erratic for the first few sprints. » After 3 take average and consider this their current velocity. » Challenge them to increase it. ~ ‘active learning ©Copyright Activeearring nc. Alrighs reserved Noto be reproduced without prior writen consent 670-4-24, Exercise 10: Estimate Effort * Goal: Familiarity with planning poker and story points 1. Everyone takes 8 index cards and writes the numbers 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, Infinity, ? Choose a clear “4 - 5 day” story and assign it the value “3, 3. Choose a clear “2 - 3 week” story and assign it the value “38” 4. Play poker and, one by one, vote on the relative size of the effort to “do” the product backlog items for the first release. 5. If large discrepancies occur, discuss, play again. 6. If estimates are close, use the higher number. “Source: Bas Vodde (@rewe \\leeming N ©Copyright Activeearing ne Alright reserved Not tobe reproduced without prior writen consent. 670-8-22Elements of Scrum: Planning Poker » Fibonacci - no need to spend time on whether a task is a 21 or a23 » Everyone learns about the task at the same time » Clarification on the functionality required + Fun! {©Copyright Activeearing, ne Alright reserved Nott be reproduced without pro writen consent. Elements of Scrum User Stories Product Backlog Story Points Sprint Backlog Taskboard Definition of Done Burndown Chart Burnup Chart * Release Plan * Abnormal Sprint Termination {©Copyright Activeeaming. ln Alright reserved, Nott be reproduced without prior wrtencongent. 670-4-23 670-4-24 (Cactive \leamingTask Breakdown » User stories form the basis for what will features be developed in the Sprint. * But astory is usually too big a piece of work to work on and involves multiple smaller tasks that go together to make the whole. During the Sprint Planning meeting, the user stories are broken down further into actual tasks so multiple people can then work on one single story. * These tasks are then placed on the Taskboard (Sprint Backlog). {©Copyright Activelearing nc Al rights reserved Notto be reproduced without pir wrtton consent. 670-4-25 Elements of Scrum: Sprint Backlog Subset of the Product Backlog « List of actual tasks that have to be completed to complete the sprint goal * Team members choose which tasks to work on » Estimated work remaining is updated daily ( active \lecming | _ ©copyright Activeearning ne. All rights eserved Netto be reproduced without rio written onset 670-4-26Elements of Scrum » User Stories » Product Backlog + Story Points » Sprint Backlog * Taskboard * Definition of Done * Burndown Chart » Burnup Chart * Release Plan * Abnormal Sprint Termination (active \lecming ‘Scopright cbeieang nc Al gh rene Nats bereromien nowt per wetencomne 670-4-27 | Elements of Scrum: Taskboard ——_ oS | ToD ne 7 — | — - —_—— sort —__ ae on — 2 ome = cael a ae SS a | eee TO Es Y = A \leaming 670-428, ‘©Copyright ActveLearing, In Alright reserved. Noto be reproduced without prior written concent.Elements of Scrum: Taskboard Coens ©Copyright ActiveLearning, Inc. All rights reserve ved. Not to be reproduced without prior written consent. 670-4-29 = Elements of Scrum: Taskboard Visual indicator of work in progress for the current sprint - Information radiator for PO and others See at a glance the status of all work for this sprint See work remaining for this sprint See if the team is on target to finish on time Is where the daily scrum happens * Updated as and when tasks are finished by the person working on the task Tasks at the top are higher priority, tasks lower down are lower priority (4 Setive \leeming {©Copyright Activlearing nc All ih reserved Noto be reproduced without pir writen consent. 670-4-30 =Elements of Scrum: Taskboard Ho be Wut) & Span Seite 4, TO 00 IN PROGRESS DONE Task: Create user login function Estimate: 6h Elements of Scrum: Taskboard {Copyright AtiveLearning Inc Aleghts reserved. Notto be reproduced without pir written consent. CG active learning 670-4-31 7 TO 00 IN PROGRESS DONE JOHN PAUL RINGO 670-4-32| Elements of Scrum: Taskboard TO 00 IN FOR QA DONE | PROGRESS | USER STORY | USER STORY 2 USER STORY 9 ‘active \leaining {©Copyright ActiveLearrng ne Al rights reserved Not tobe reroduced without prior writen consent. 670-4-33 Exercise: Breakdown User Stories to Tasks * Goal: Familiarity with task breakdown - Starting with our user stories, break them down into “pieces of work” i.e. tasks. CG ketive \leaming ©Copyright Activeleacning ne Alright eserved Not tobe reproduced without prior written consent. 670-4-34Elements of Scrum » User Stories » Product Backlog » Story Points » Sprint Backlog » Taskboard * Definition of Done » Burndown Chart * Burnup Chart » Release Plan * Abnormal Sprint Termination ‘©Copyright ActiveLesing In Allrights reserved. Nott be reproduced without, Exercise: When is “Done” Done? {© Cooyrit ActiveLeering, In Al ht reserved. Not tobe reproduced without pir writen consent. 670-4-36 ‘etive \lesi ningElements of Scrum: | Definition of Done oe = } | |» Each team's definition of done is different Team should agree together what their definition is and stick toit » Anything not done ina sprint is not demoed to the Product Owner. Gets ©Copyright ActiveLearning, Inc. All rights reserved. Not to be reproduced without prior written consent. 670-4-37 = ° | Elements of Scrum: Definition of Done * Sample definition from Scott Downey at PivotalLabs: ~ Feature Complete ~ Has been reviewed | ~No known defects ~ Ready to send to client Copyright Acivebearving ne All igh reserved Noto be reproduced without rir writen consent. 670-4-38| Elements of Scrum: | Definition of Done | i » The definition can grow over time as the team grows together. Inspect/Adapt - definition of done is something that can be | brought up in the Sprint Retrospective. | ©Copyright Actveleaming. ne Allights reserved. Nott bereroduced without pir written consent. 670-4-39 Elements of Scrum: Definition of Done » What about undone work? ~ Inform the Product Owner. | ~ Not necessarily done in the next Sprint. | ~ It goes back on the Product Backlog for reprioritization and the Product Owner will choose when the team works on it. | ‘©Copyright Activeearing, ne Alright reserve Noto be reproduced without prior writen consent. 670-4-40Elements of Scrum » User Stories Product Backlog » Story Points * Sprint Backlog » Taskboard * Definition of Done > Burndown Chart * Burnup Chart » Release Plan » Abnormal Sprint Termination Gactive \leaming ©Copyright Activelearring ne. Alright reserved Not tobe reproduced without pia written consent. 670-444 = Elements of Scrum: Burndown Chart HE * Indicator of work remaining for this sprint » Updated daily based on hours remaining per task » Allows all roles (and upper management) to see at a glance how things are going | Geter .©CopyrantActiveearing Ine Alright reserved Notto be reproduced without prior writen consent. 670-4-42Elements of Scrum: | Burndown Chart | 120 w» 100 2 | 2 80 ca Actual | | £& 60 Ideal | | & | = 40 o | « 20 0 | tO t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 | Time Vieatits ‘capigu sccm ne ht igre eed lettvnreduatnatertnerinmeman ero-aas Elements of Scrum: Burndown Chart “Sprint 0 - Burndown Chart = oS — Sprint 0 | ee i \ i \ Burndown Chart Burnup Chart Release Plan * Abnormal Sprint Termination | Caetive } \lesining |___Scconmiene ActveLearing Inc Alrighs reserve Not tobe reproduced without ror writen consent. 670-4-45 Elements of Scrum: Burnup Chart = » Burndown chart in reverse * Plotted per iteration, not per day * Shows total work remaining on the project to manage scope changes * Allows all roles (and upper management) to see at a glance how things are going {© Copyeeht Activelearing Inc Al rights reserved Not tobe reproduced without pir written consent. 670-4-46Elements of Scrum: Burnup Chart 140 120 120 120 120 120 eae areca eee S 6 100 “400 “100 +100 7 - -Total Complete STORY POINTS S v ® aig Ss es A & & MI s Ss § $ $ s g teaming ©copyright ActiveLearing. ne Alright reserved Nott be reproduced without prior wen consent 670-4-47, Exercise: Burndown Chart * Given the following information, draw the Burndown chart: ~ Team Size: 6 ~ Sprint length: 2 weeks ~ Estimated hours of work for sprint: 345 hours ~ Total hours available for sprint: 360 * 6 people x 6 productive hours per day x 10 working days ~ Day 1 remaining: 340 hours ~ Day 2 remaining: 310 hours ~ Day 3 remaining: 290 hours ©Copyright AciveLenrrng In. Al rights reserved. Noto be reproduced without rior writen consent. 670-4-48Exercise: i | [tise | 150 + ie | | | 100 -—______— ————- | 7 | | | 50 festa Seer aa | o one e ne ana eye eo eo 4 2 8 4 & 6 7 & © to 1 Visas © conv een Ais rome Natt erect yo oan oat mee ~ Exercise: _ Burndown Chart » Given the following information, draw the Burndown chart: ~ Team Size: 6 ~ Sprint length: 2 weeks ~ Estimated hours of work for sprint: 345 hours ~ Total hours available for sprint: 360 * 6 people x 6 productive hours per day x 10 working days ~ Day 1 remaining: 300 hours ~ Day 2 remaining: 260 hours ~ Day 3 remaining: 220 hours Q ective vloeming {©Copyright Activelearrng Ic Alright reserved Not obereproduced without prie written consent. ____670-4-50© Copyright Activelearing ne Alright reserved, Not tobe reproduced without rior writen convent 670-452 Exercise: Burndown Chart 2 Solution active \leaming {© Copyright ActveLeaning. In Alright reserved Noto berearodced without pir written consent. 670-4-54, = Exercise: Burnup Chart * Given the following information, draw the Burnup chart: ~ Project length: 10 iterations ~ Estimated story points for whole project: 200 points ~ Iteration 1 points completed: 8 points ~ Iteration 2 points completed: 16 points - Iteration 3 points completed: 12 points ~ Iteration 4 points completed: 14 points - Iteration 5 points completed: 16 points ~ After iteration 3 a new feature is added, estimated by team to be 35 story points ~ After iteration 5 a feature worth 10 points is removed by the Product Owner (G active \leamingExercise: Burnup Chart Solution 50 + l © Copyright Activeearing ne. Aleights refered. Not tobe reproduced without prior write conden 670-453 + Storypoints -+~ Progress. Tj aslive \learing Elements of Scrum » User Stories » Product Backlog » Story Points * Sprint Backlog * Taskboard * Definition of Done » Burndown Chart * Burnup Chart » Release Plan » Abnormal Sprint Termination {© CopyrohtActivelearing. nc. Alright reserved Noto be reproduced without rior written consent 670-454Elements of Scrum: Release Plan Cc S = Prioritise and Estimate the Backlog 2. Get the team’s velocity i. Solid? One plan 2. Variable? Best and worst case plans. 3. (Total estimates / velocity) + 1 release sprint = number of sprints required I | ~ | \learning | ‘© copvieh Athearn he Alghs eseved Nth posta wlbout por writen casa 670-4-55 es Elements of Scrum: Release Plan Priority Estimate Story 1. Let's say your product backlog with estimates looks like this: 1 2 Feature At 2 5 FeatureAz 3 3 Feature Ag 4 5 FeatureBs 5 8 Feature C | 6 1g Feature Da 7 3 Feature Bz a 13 —-FeatureE 9 5 Feature Bg to 2 FeatureBg a 8 Feature D2 12 13 Feature Fi 1g 3 Feature Bs | 14 5 Feature Aq is, a Feature F2 | 16 5 FeatureF3 i? 20 FeatureG 18 8 Feature H 19. 13 Featurel “Source: http://scrumcoachingv.___ 2°. 40. Featured vith-scrum/ ¢ rs learning {©Copyright AtveLearing. In Allrighs reserved. Netto be reproduced without pir written consent 670-4-56 salElements of Scrum: Release Plan output would look like this: Assuming you team has a velocity of 13, your release plan | Sprint. Start End Stories Estimates Total Estimate for | Sprinta april goApril Feature As 2 10 | Feature Az A | Feature Ag 3 | Sprintz May aqMay ‘Feature Br 5 13 | Feature 3 Sprintg apMay28May Feature Ds 3 6 | Feature Ba 3 gaMay aidan Feature 3 13 iqiune agdune Feature 5 3 Feature D2 8 Sprint é 28June 9 July Feature Fa 6 3 Sprint? aaJuly 2gduly —‘FeatureBy > a Feature BS 3 Feature Ag 5 FeaturaFa : Sprints 26dJuly 6 Aug Feature F3 5 5 Sprinto Ang 2oAug ‘Feature 20 20 Sprintio 29g Sep Feature 3 8 Sprints: Sep .7Sep Feature 3 Sprintszaq 20Sep 200 Ps Sprintig a Now 13 | > | ‘Source: http:/scrumeoaching word ase-planning ‘active } slesrning |__ ©Copyright Activetearning Inc All rights reserved, Not tobe reproduced without prior written consent bal Exercise: Release Plan » Given the following information, create a Release Plan: ~Team Velocity: 10 w ~ Product Backlog: | | OME GH re | Priority Estimate Story Serta Borin | | 1 Feature A1 y | 2 Feature B1 | 3 Feature A2 \ a 4 Feature B2 5 20 Feature C1 — on 6 g Feature D1 y 8 7 Feature Fi 8 W Feature E y ee 9 - 13 Feature B3 (Gene \leetning {© Copyright Activeearning ng Al rights reserved. Not tobe reproduced without pio wrlten consent 670-4-58Exercise: Release Plan (Solution) | Total estimate | Sprint_| Estimate |Story for Sprint 1 6 Feature A1 10 4 Feature Bi 2 7 Feature A2 10 3 Feature B2 i} 3-4 20 Feature C1 20 5 2 Feature Di 8 6 Feature Fi 6-7 7 Feature E 20 13 Feature B3 8 = Release Sprint _-| ; eteits ©Copyright ActiveLearning, Inc. All rights reserved. Not to be reproduced without prior written consent. 670-4-59 nal Elements of Scrum: Release Plan * Careful! ~ Plans change aware that this is only a plan. ©Copyright Activelearing, ne Alright reserved, Nott be reproduced without prior writen consent. ~ Make sure the Product Owner is kept updated and made 670-4-60 ( \learning SctiveElements of Scrum User Stories » Product Backlog Story Points Sprint Backlog Taskboard » Definition of Done Burndown Chart * Burnup Chart Release Plan Abnormal Sprint Termination \leaining {©Copyright Activelearrng nc Allights reserved Not tbe reproduced without prior writen consent 670-4-64 Elements of Scrum: Abnormal Sprint Termination Ne * Sprint termination is very serious and should only occur in extreme circumstances, such as: Fundamental and urgent changes in the functionality - Failure of the Scrum Process due to poorly performing Team, PO, ScrumMaster or a combination of all 3. » Following the termination, the ScrumMaster should look at the reason the Sprint was cancelled and do what he can to avoid it in future. » Next step: a new Sprint planning meeting ‘ctive leaming ‘©Copyright Activelearning ne. Alright reserved Not tobe reoroduced without pir written consent. 670-4-62Test Your Knowledge What tool can be used to track the Team’s progress during a Sprint? What tool can be used to track the Team’s progress over the course of a whole project? What is a Taskboard used for? What is a User Story used for? | (Cactive | veering ©Copyright ActiveLearning, Inc. All rights reserved. Not to be reproduced without prior written consent. 670-4-63 =Chapter 5 Meetings Meetings * Sprint Planning » Daily Scrum Sprint Review » Sprint Retrospective {©Copyright ActiveLearning ne Alright reserved Not tobe reproduced without prior writen onsen (G active \leaming 670-5-2 =Chapter 6 | Conclusion | esis | _ Conclusion » Alternatives to Scrum » Implementation » Dealing with Fixed-price Projects * Metrics | Gbehg Copyright Activeteatng nc Alright reserved Not tobe reproduced without prie written consent 670-6-2Alternatives: Kanban * Scrum is rigid, no changes during Sprint Weekly? Daily? Or even...hourly? No problem! changes come in WIP limits Useful for maintenance / small projects {©Copyright ActiveLearing ne. Alright reserved. Not to be eprodiced without prior writen consent. Kanban What if your project has frequently changing requirements? Kanban has no Sprints but uses Taskboards to manage tasks Tasks can be updated and reprioritised as necessary whenever clive learning 670-6-3 = TODO IN PROGRESS FOR QA DONE Task | [Task | Task Task Lf Task Teak Task Task gb Task {©Copyright ActiveLeaming, ne Allright reserved Not tobe reproduced without prior writen consent Caaates 670-6-4Kanban Taskboard TODO IN PROGRESS FORQA DONE (3) (3) FCA Je ae Cop cveLeing ne Aight rr Noto beep wi pr writen case 670-65 = Alternatives: XP * Very similar to Scrum » Sprint (Iteration) length is usually one to two weeks » XP requires engineering practices such as Test Driven | Development, Pair Programming, Continuous Integration...where Scrum leaves this up to the team | | | | . ( ‘active learning ‘Copyright Aciveteaeing ne Alright ererved Not tobe reproduced without prior written consent. 670-6-6Implementation » Explain benefits » If they don't agree, he can try it out anyway |__©copviaeActveLearnng ne. Al its reserved Not tobe reproduced without prior writen consent Implementation: Tips organisation so try it slowly. + Easy things to start with: ~ Taskboard ~ Retrospective Meetings ~ Empowering the team + Inspect + Adapt * ScrumMaster: Proponent of Scrum in organisation » He will have to get upper management onboard 670-6-7 * It's alot to take in and involves big changes for the 670-6-8 (G. active \leaming Gsetive \leamingImplementation: Are We Doing Scrum? | Nokia Test by Bas Vodde Part 1 - Are we doing Iterative Development? ~ Iterations must be time-boxed to less than 4 weeks ~ Software features must be tested and working at the end of each iteration - The Iteration must start before specification is complete G active \leamning ©Copyright ActiveLearning, Inc. All rights reserved. Not to be reproduced without prior written consent. 670-6-9 7 Implementation: Are We Doing Scrum? Part 2 - Are we doing Scrum? ~ You know who the product owner is | ~ There is a product backlog prioritized by business value | ~ The product backlog has estimates created by the team | - The team generates burndown charts and knows their velocity ~ There are no project managers (or anyone else) disrupting the work of the team ( bctive leering {© Copyright ActiveLearning ng Alights reserved. Netto be reproduced without prior writen content 670-6-10Implementation: Bad Scrum Smells Daily Scrum meeting goes longer than 15 minutes Burndown chart is not visible at Daily Scrum Team consistently misses their deadlines Team unsure who the Product Owner is Scrum Master micro managing tasks Tasks stay in progress for 3 days Team unsure who is working on task A | Team doesn’t learn from Retrospective Upper Management interfering Product Owner never attends the Daily Scrum Daily Scrum is for the Scrum Master Testers not integrated with team 670-6-11 {©Copyright ActiveLearing, Ine Allright reserved. Nott be reproduced without io wr Implementation: ScrumBut * We're doing Scrum but... ~ We still have a Project Manager role ~ Our team has to send daily status updates to management ~We don't do testing within the Sprint ~ We don't have a Daily Scrum ~ Our team is not co-located ~We don't do retrospective meetings ~ Our Sprints are 8 weeks ~ Our ScrumMaster assigns tasks (PSctive — learning opr Actveearing ne Al ighsreserved Noto be reproduced thou pr wien cnent “610-6-12 isMetrics How to improve as a team? ~ Use metrics as inputs to start the thinking process ~ Metrics are developed by the team to help them improve Productivity: In-Sprint Cycle Time ~ Measure turnover by tracking when task was started vs when completed. ~ Shorter the better. Quality: Technical Debt “Those internal things that you choose not to do now, but which will impede future development if left undone”. - Lower number of points the better ( Sctive \leaming © ConyrightActiveLearing ne. Allights reserved Not tobe reproduced without pir written consent 670-6-13, ial Metrics (2) * Predictability: Velocity ~ Number of story points per sprint completed by the team. Value: Customer Satisfaction Survey ~ Quantitative/Qualitative quarterly feedback on quality, predictability, productivity, support etc Value: Employee Satisfaction Survey ~ Quantitative/Qualitative quarterly feedback on roles, quality of work/life balance, teamwork, product definition, overall happiness. *Source: http:liscrumo! ( active \ leering {© Copyright AciveLzarnng ne. Alright reserved Noto erepoducevathout rr writen consent 70-614 =Fixed Price Projects * To cost effectively in Scrum: | ~ Define your team (remember the team should stay together for the duration of the project) | ~ Define your team’s cost per Sprint ~ Customer pays per Sprint ~ Give the client the option to end the contract after any sprint | ~ Pressure on the development team to keep the client instead of client committing e.g. 50% down at beginning of project Nieamning 670-615, = C@retve | ‘©Copyright ActiveLearing In Allright reserve. Nott be reproduced without Evaluating Teams * Stats: - 90% of appraisal systems are unsuccessful | ~ 48% believe it is merely a second-guessing session | ~ 5% of HR professionals says they were “very satisfied” * Mentor/Coach System adi os * Company Performance * Coach and guide employees * Feedback and communication * Salary and benefits management » Promotions * Termination and layoffs {©Copyright Activelearig, In Alright reserved Notte reproduced without prior written consent. 670-6-16| Questions? GG Sctive \ \leamning |__eccoowrient Actietering ne Alig reserved Not tobe reproduced without prior writen consent, 670-617, 2 Exercise 15: gril@omrkF grugor Putting It All Together * The goal is to create a paper brochure for a Dog Spa » The brochure must be ready after one sprint of 3 days » You will actually do the work to create the brochure and demo to the Product Owner (Your Instructor) at the end Notes: - The PO is unlikely to accept anything that doesn’t look nice or contains typos! ~ For practical reasons, we will not be using Burndown charts in this simulation. (4 active \lesming {Copyright ActiveLearing In Alright reserved Not tobe reproduced without ror writen consent 670-6-18Exercise 15: | Putting It All Together » Schedule: ~ Project length is one sprint only | ~ Pre-sprint - Sprint planning for 10 minutes ~ Day 1 - Daily Scrum for 2 minutes followed by 8 minutes of work ~ Day 2 - Daily Scrum for 2 minutes followed by 8 minutes of work ~ Day 3 - Daily Scrum for 2 minutes followed by 8 minutes of work ~ Post-sprint - Sprint Review for 5 minutes followed by retrospective for 5 minutes {Copyright ctveLearning Inc Allelghts reserved Netto berepreduced without prior written consent 670-6-19 {© Copyright ActveLearning nc Alleghts reserved Not tobe reproduced without prior written consent. 670-6-20 Exercise 15: | Putting It All Together Product Backlog Task Priority Provide company’s contact information Create cover art, brand and/or logo Define major care sections Define the “Ultra Doggy Spa” service Provide satisifed customer testimonials Define the price structure for services Outline boarding options Suggest daypack contents to accompany clients Outline full week lunch menu Create a guarantee policy Provide complete bios on all staff members (backgrounds, training, interests) 11 Define discounted partner pet services 12 CrmVaunakwone eatFurther Reading “Scrum and XP from the trenches” by Henrik Kniberg “Iterative and Incremental Development: A Brief History” by Craig Larman and Victor Basili “Agile Software Development with Scrum” by Ken Schwaber “Succeeding with Agile: Software Development Using Scrum” by Mike Cohn » “Agile Estimating and Planning” by Mike Cohn Crctve ‘learning {Coprgh ActiveLcring. In Alright reserved Not tobe reproduce without rir wen consent 670-624, ia __Meetings: Sprint Planning SHE * Outcome of meeting: —Next Sprint goal ~Sprint Backlog * Length: ~ 8 hours for a monthly sprint. ~- For shorter sprints, it is usually shorter. (active \leaming Copyright Actvelearing In Allrghts reserves Nott be reproduced without prior written onsen. 670-5-3 bd Meetings: Sprint Planning (Continued) > Part 4: ~ Discuss and ask questions on the backlog items ~ Select tentative sprint backlog items > Part 2: ~ Hours based Sprint planning ~ Get team’s commitment to deliver ~ Update PO “betive : —— : learning [© Copvight eteearting nc Aig sere. Nato berepodind thet rr wien consent 054 =Meetings: Sprint Planning Part 1 Rules » Timebox: 4 hours » Team: Make suggestions for the items { Copyright ActiveLearing Ine Allright reserved, Not tobe reproduce without ror writen consent 6705-5 = Attendees: Scrum Master, Team, Product Owner Preparation: ~Scrum Master must ensure the Product Owner has prepared the backlog before the meeting Goals: —Goal 1: Select backlog items it believes it can commit to —Goal 2: Analyse the Product Backlog PO Output: Final decision on what items to work on Team Output: Decision on how many items to work on (Gy active \leaming Meetings: | Sprint Planning Part 2 Rules » Attendees: * Outputs: {© CopyrihtActiveLearnng ne. Alrights reserved. Not tbe reproduced without prior writen consent. __670-5-6 ~—Scrum Master, Team —(PO is not required but must be available to answer questions) Goal: Find out how to convert the backlog items to working functionality Tasks: No bigger than 12 hours Timebox: 4 hours —Sprint Backlog —Final commitment —Sprint Goal (active \lesmingMeetings: Daily Scrum SHE » 15 minute, stand-up meeting in the morning » Happens at the beginning of the shift + Burndown chart should be prepared in advance * In front of the taskboard * Everyone answers 3 questions: ~—What did you do yesterday? —What are you going to do today? —Are there any impediments in your way? (& active \leaining {©Copyright ActiveLearing In Allright reserved. Netto be reproduced without prior written consent. 670-5-7 = Meetings: Daily Scrum (Continued) » Attendees: Team * Goal: Sychronise work * Timebox: 15 minutes * Impose a penalty for coming late {©.opyrightActiveearing, nc Alrights reserved. Nott be reproduced without prio writen consent 670-5-8| Meetings: Sprint Review SH » Attendees: ScrumMaster, Product Owner and Team : Preparation: Less than 2 hours Goal: Present the development of the last sprint Timebox: 4 hours for a monthly Sprint. For shorter Sprints it is | usually shorter | Cannot present functionality that is not “done” | CC retive } \ learning ony Attain Alig res Netto beeetucn ope oe Ce i Meetings: Sprint Retrospective » Attendees: ScrumMaster, Product Owner and Team Timebox: 4 hours * Goal: Reflect on the previous sprint Questions to ask: ~ What went well during the last sprint? ~ What didn't go well during the last sprint? ~ Improvements to make? » ScrumMaster leads the meeting Output: Action points for the next Sprint {©Copyright Activelearng Inc lights eerved Nato be reproduced without pie written consent 670-5-10Exercise: The Dysfunctional Daily Scrum ¢ — : ee leering ©Copyright ActiveLearning. Inc.All rights reserved. Not to be reproduced without prior written consent. 670-5-11 = Elements of Scrum: Taskboard reproduced without por weten consent 670-5-12 ~Exercise 14: Lost in Communication (Part 1) ©Copyright Activelearing Ic Alrights reserved Not tobe reproduced without pir wrttn consent. 670-5-13, 1. Split into groups of 3 and assign roles (1 Product Owner, 1 Analyst, 1 Developer). Developer leaves the room Product Owner describes the project to the Analyst Analyst creates a written specification Product Owner leaves the room and the Developer develops the project based on the written specification . At the end, the project will be presented to the Product Owner (Sprint Review) clive learning Exercise 14: Lost in Communication (Part 2) One © Copyright AciveLeaning Inc Alright reserved Notto be reroduced without ir writen consent 670-5-14 Same roles as Part 1. Everyone in the same room. Product Owner describes the project to the Analyst and the Developer. Developer develops but can ask any questions to the Product Owner. At the end, the project will be presented to the Product Owner (Sprint Review) ( Sctive learningExercise 15: Thumb Wars 1. Find a partner to play thumb wars with. 2. You win (an imaginary :p ) 100PHP per “pin”. 3. Your goal is to “Maximise gains”. | 4. Retrospective meeting. 5. Repeat. ~~ ( Sctive \learning {©Copyright ActveLeoring, In Allrights reserved Nott be reproduced without 670-5-15 = Test Your Knowledge » List the main meetings involved in Scrum * Inyour opinion, which meeting is the most important? GG Setive - a a 7 ne scene — \learning [econ cvetering ie Alig reseed Nato eprdurd wet ten consent 6705-16