Module: Scrum Basics. Pete Deemer CPO, Yahoo! India R&D

Module: Scrum Basics Pete Deemer CPO, Yahoo! India R&D

Scrum Roles Brief Introduction Product Owner The Team ScrumMaster Determines what should be produced, to maximize ROI for the business Cross-functional and self-organizing team of 7 people +/- 2 Protects and serves the Team, and supports their practice of Scrum

The Basics of Scrum Scrum Master Daily Scrum Meeting 4-Week Sprint Product Owner The Team Review 1 2 3 4 5 6 7 8 9 10 11 12 13 Commitment No Changes (in Duration or Deliverable) Potentially Shippable Product Retrospective

Product Owner Charged with maximizing ROI and managing project risk Responsible for taking all inputs into what the team should produce, and turning it into a prioritized list. Inputs include: Customer Team Executives Competitors Other Stakeholders Determines release plan and communicates it to upper management and the customer

Team Cross-functional Possesses all the skills necessary to produce an increment of potentially shippable product Self-organizing Empowered to do whatever s necessary to produce the potentially shippable product, within the constraints of the organization s standards Commitment is shared 7 people, + or 2 Has worked with as high as 15, as few as 3 Can be shared with other teams (but better when not) Can change between Sprints (but better when they don t) Can be distributed (but better when colocated)

The Basics of Scrum Scrum Master Daily Scrum Meeting 4-Week Sprint Product Owner The Team Review 1 2 3 4 5 6 7 8 9 10 11 12 13 Product Backlog Commitment No Changes (in Duration or Deliverable) Potentially Shippable Product Retrospective

Product Backlog Product Owner lists items in descending order of priority (highest priority item is listed first, next-highest is second, etc.) Size estimates are rough relative estimates (ie, arbitrary points, not hours or days, etc.)

Product Backlog List of everything that could ever be of value to the business for the team to produce Ranked in order of priority Priority is a function of ROI and risk Product Owner can make any changes they want before the start of a Sprint Planning Meeting Items added, changed, removed, reordered The farther down the list, the bigger and less defined the items become ~2 Sprints worth are defined in detail

Sprint Planning Meeting Goal of Sprint Planning Meeting: For the team to make a good commitment around what it will deliver by the end of the Sprint What s a good commitment? Clearly understood by all Shared among the team Achievable without sacrificing quality Achievable without sacrificing sustainable pace Attended by Team, Product Owner, ScrumMaster, Stakeholders May require 1-2 hours for each week of Sprint duration

Sprint Planning Meeting 3 Steps: 1 Product Owner, Team, and other Stakeholders talk through Product Backlog Items and prioritization. 2 Team determines how much time it has available to commit during the Sprint 3 Team selects as much of the Product Backlog as it can commit to deliver by the end of the Sprint, and turns it into a plan Validates commitment by breaking down into tasks with time estimates Team decides who will do what, when; thinks through sequencing, dependencies, possible task trades, and so forth.

Hours Per Day time available for Sprint work 10-Hour Day hacking, reading blogs, playing foosball lunch and tea breaks reading and writing e-mail meetings

Calculating Available Hours in Sprint Sprint Length 4 weeks Workdays During Sprint 17 Team Member Available Days During Sprint* Available Hours Per Day for Sprint Total Available Hours During Sprint example: Pete Aishwarya Abhishek Shahrukh Amitabh John Shilpa example: 10 15 16 17 12 example: 4 Pete 16 Deemer5 CPO, Yahoo! 17 India 5R&D * Net of holidays & other planned days out of office 4 3 4 5 example: 4 x 10 = 40 15 x 4 = 60 hrs 16 x 3 = 48 hrs 17 x 4 = 68 hrs 12 x 5 = 60 hrs 16 x 5 = 80 hrs 17 x 5 = 85 hrs

Product Backlog

Task Breakdown

The Sprint The Sprint is never extended Sprint ends on pre-determined date whether or not team has completed what it committed to Sprint Length 4 weeks is standard in literature 2 weeks is also common 1 week is minimum, 4 weeks is maximum Factors in deciding your Sprint length Length of the release Amount of uncertainty How long priorities can stay unchanged Overhead of Sprint Planning and Review Urgency / intensity lag

Sprint Cycle: 2-Week Sprint Mon Tues Weds Thurs Fri 1 2 3 6 Sprint Planning Meeting 7 1 8 9 10 2 3 4 13 14 5 6 7 8 15 16 17 Sprint Review & Retrospective 20 21 22 23 24 27 28 29 30 31

Sprint Cycle: 4-Week Sprint Mon Tues Weds Thurs Fri 1 2 3 6 Sprint Planning Meeting 7 1 8 9 10 2 3 4 13 14 15 5 6 7 8 9 16 17 20 21 10 11 12 13 22 23 24 14 27 28 15 16 17 18 29 30 31 Sprint Review & Retrospective

Sprint Cycle: 2-Week Sprint Mon Tues Weds Thurs 1 1-Hr Pre- 5 6 Meeting 7 for 8 Next Sprint 2 Fri 3 Sprint Review & Retrospective 6 Sprint Planning Meeting 7 1 8 9 10 2 3 4 13 14 5 6 7 8 15 16 17 Sprint Review & Retrospective 20 Sprint Planning Meeting 21 1 22 23 24 2 3 4 27 28 5 6 7 8 29 30 31 Sprint Review & Retrospective

Work Intensity Work Intensity Waterfall Scrum Time

No Changes During Sprint No Changes to Deliverable Once team has committed, no changes Details will emerge during Sprint, but no new work or substantially changed work Product Owner can terminate the Sprint if necessary The experience of the Product Owner? No Changes to Sprint Duration Sprint ends on planned date whether team has completed its commitment or not

The Role of the ScrumMaster Serve the Team The ScrumMaster facilitates the removal of impediments to the team s productivity The ScrumMaster facilitates the team s group interactions, to help the team achieve its full potential Protect the Team The ScrumMaster protects the team from outside interference or disruption The ScrumMaster may represent the team to management The ScrumMaster may need to raise uncomfortable issues within the team Support the Team s use of Scrum The ScrumMaster organizes and facilitates Scrum-related practices The ScrumMaster serves as the Scrum conscience of the team, reminding the team of standard Scrum practices

Daily Scrum Meeting Every weekday, same time and place Whole team attends Everyone stands Lasts 15 minutes or less Everyone reports 3 things only to each other What was I able to accomplish since last meeting What will I try to accomplish by next meeting What is blocking me No discussion, conversation until meeting ends Product Owner can attend and report Following the Daily Scrum Meeting Team members update the Sprint Backlog with hours remaining for tasks that they ve worked on ScrumMaster adds up the hours remaining and plots it on the Burndown Chart

Sprint Backlog

Burndown Chart

Paper versus Electronic Electronic may look more convenient for the Sprint Backlog and Burndown Charts, but... Paper is fast and easy Paper is much more visible Paper doesn t go down

Task Board TO DO IN PROGRESS DONE Owner:` Sanjay Owner:` Sanjay Task: database Owner:` Sanjay Owner:` Sanjay Owner:` Sanjay Owner:` Sanjay

Potentially Shippable Product The goal of the Sprint is to produce Potentially Shippable Product This is the outcome of the Sprint that is of the greatest possible value to the Product Owner or customer. Anything produced that is less than potentially shippable represents unwanted risk for the Product Owner: Inventory of product that is always not-quite-done. However, producing Potentially Shippable Product every Sprint is hard For many teams, it will require a change in underlying software practices. For example: putting in place automated testing. These practices will produce further benefits of productivity and quality for almost all teams Can we use Scrum and not produce Potentially Shippable Product? Yes, but you ll be missing a big part of the potential benefit. Keep asking: Would it be of value to the customer and our business is we were able to produce Potentially Shippable Product every Sprint? What would we have to do differently if we wanted to be able to produce Potentially Shippable Product every Sprint? Would those changes also in and of themselves benefit the customer or our business?

Sprint Review The Sprint Review takes place at the end of each Sprint Purpose of the Sprint Review is Demo what the team has built Generate feedback, which the Product Owner can incorporate in the Product Backlog Attended by Team, Product Owner, ScrumMaster, functional managers, and any other stakeholders A demo of what s been built, not a presentation about what s been built No Powerpoints allowed! Usually lasts 1-2 hours Followed by Sprint Retrospective

Sprint Retrospective What is it? 1-2 hour meeting following each Sprint Demo Attended by Product Owner, Team, ScrumMaster Usually a neutral person will be invited in to facilitate What s working and what could work better Why does the Retrospective matter? Accelerates visibility Accelerates action to improve It s a key mechanism of continuous improvement If Scrum is an engine, Retrospective is the oil filter Catches the debris and keeps it from recirculating Keeps the engine running clean and smooth

Sprint Retrospective One Approach Part 1 Create 3 large lists (whiteboard or flipchart) What s working What s could work better Things to try in the next Sprint Go around the room, and give each person an opportunity to add 1 or more items to the 3 lists If people agree with something already on the lists, put a tick mark next to them Select a subset of the Things to try... list to try in the next Sprint (ScrumMaster responsible for tracking this)

Sprint Retrospective One Approach Part 2: At the end of the meeting, mark each item on the What s Working / What Could Work Better lists as either: C = caused by Scrum (would not be happening without Scrum) E = exposed by Scrum (would be there even if team were not using Scrum) U = unrelated to Scrum (like the weather) Then, add up the C, E, and U in each column