Management Fundamentals: Scrum 101 Reality Check! Management Fundamentals: Scrum 101 Manager’s Guide Project Management Consulting Yossi Barezer Aug 2016

Introduction This presentation describes the basic elements of the Scrum Framework My goal is to provide an organized view that will help a novice understand and implement the Scrum foundation quickly For enhanced details, you should read the Guide, receive official training and consult a coach How would I describe Scrum? The Scrum methodology provides a way to continuously, consistently, and constantly improve product value using reality checks Note, I use the Scrum Guide as my reference as well.

AGENDA Certifications Definition of Scrum Scrum Theory The Scrum Team The Scrum Framework The 3 Pillars/Principles The Scrum Team The Scrum Team and Event Scrum Artifacts Product Backlog Sprint Planning and Backlog The Scrum Process - Increment Scrum Event/Ceremony Events Goals and Deliverables The Sprint Framework Time Box Sprint Planning Daily Scrum Scrum Board Burn-Down Chart Sprint Review Sprint Retrospective Definition of “Done” Scrum Summary

Scrum.org Certification PSM I, II - Professional Scrum Master Level I&II (CSM Equivalent) PSPO I, II - Professional Scrum Product Owner Level I&II (CSPO Equivalent) PSD I - Professional Scrum Developer Level I (CSD Equivalent) SPS - Scaled Professional Scrum (Scrum of Scrum) PSP - Professional Scrum Practitioner PSF - Professional Scrum Foundations PSE - Professional Scrum Expert PST - Professional Scrum Trainer

Definition of Scrum “Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. “ “Scrum is a process framework that has been used to manage complex product development.” “The rules of Scrum bind together the events, roles, and artifacts” Scrum-Guides Scrum-Glossary PSD-Glossary

Scrum Theory “Scrum is founded on empirical process control theory, or empiricism” The 3 Pillars/Principles Three pillars uphold every implementation of empirical process control: Transparency Inspection Adaptation The Scrum Team /Roles The Scrum Team consists of a: Product Owner The Development Team Scrum Master Scrum Teams are self-organizing and cross-functional Scrum Artifacts Scrum artifacts represent the work or value to provide transparency and opportunities for inspection and adaptation Product Backlog Sprint Backlog Increment Scrum Events Scrum prescribes five formal events for inspection and adaptation, as described in the Scrum Events section of this document: The Sprint Sprint Planning Daily Scrum Sprint Review Sprint Retrospective Note: Scrum Master A Scrum Master is a servant-leader for the Development Team. He is facilitating and removing impediments Serves a team in achieving the best productivity possible

The Principles/Pillars The Scrum Framework Roles/Team Product Owner Scrum Master Developer Artifact Product Backlog Sprint Backlog Sprint Increment * Burn-Down/Up Chart Events/Ceremonies The Sprint Sprint Planning Meeting Daily Meeting The Sprint Review Sprint Retrospective **Product Refining DONE The Principles/Pillars Transparency Inspection Adaptation *Burn-Down/Up Chart – is considered as an internal artifact for the Development team **Product Refining – is considered as an external event to the ceremonies

The 3 Pillars/Principles Transparency Inspection Adaptation

The 3 Pillars/Principles Transparency “Significant aspects of the process must be visible to those responsible for the outcome” Inspection “Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances” Adaptation “If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted”

The 3 Pillars/Principles Transparency Inspected Adapted Artifact The Sprint Product Backlog Yes Sprint Planning Sprint Backlog Daily Meeting Sprint Review Sprint Increment Sprint Retrospective The Team & Process No Product Refining Product Backlog & Sprint Backlog 1 Sprint Backlog Sub-task *Artifacts are part of the outcome of the meeting **The Sprint Retrospective should have a meeting minutes only if the team will agree and only on the process improvement

The Scrum Team The Scrum Team Product Owner Scrum Master Developer

The Scrum Team The Product Owner The Development Team The Scrum Master “The Product Owner is responsible for maximizing the value of the product and the work of the Development Team” “The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes” The Development Team “The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint” “Only members of the Development Team create the Increment” The Scrum Master “The Scrum Master is responsible for ensuring Scrum is understood and enacted” “Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules”

The Scrum Team and Events Owner Product Owner Scrum Master Developer Other Sprint Planning Part I Y N Sprint Planning Part II Dev Optional Daily Meeting Sprint Review Sprint Retrospective Product Refining 1 Sprint Backlog Sub-task

Scrum Artifacts Product Backlog Sprint Backlog Increment Product Backlog – marketing wish list The sprint Backlog – developer plans how to execute Increment – the actual deliverable

Scrum Artifacts Product Backlog Sprint Backlog Increment “The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product” “The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering” Sprint Backlog “The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal” “The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment” Increment “The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” User’s Acceptance Test can be added to the Product Backlog. Product Backlog items that selected to move to the Sprint Backlog named “Ready” Sprint Backlog also called Sub-Tasks. Sub-Task belong to a Story. Tasks are independed. i.e. ‘Done’ Checklist.

Product Backlog The product attributes are: scrumreferencecard.com Product Backlog items also called ‘Issues’. Issue types can be Story, Bug, Task… The product attributes are: - Description: will answer the question “What should I do?” (detailed enough to understand) Order: The Product Backlog is ordered by the Product Owner Estimate workload effort: Small, Medium, Large, Extra Large Value: to marketplace

Sprint Planning and Backlog Sprint Backlog items also called ‘Sub-Tasks’. scrumreferencecard.com The Development Team selects items to develop. This will be the Product Increment. Each selected Item will have the following details: Description: will answer the question “How will we make this change?” Duration 1-2 days Assign Owner

The Scrum Process - Increment “At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it” By Lakeworks - Own work, GFDL, https://commons.wikimedia.org/w/index.php?curid=3526338

Scrum Events Sprint Planning Daily Scrum Sprint Review Sprint Retrospective The Sprint Scrum Events

Scrum Events The Sprint Sprint Planning Daily Scrum Sprint Review The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created Sprint Planning The work to be performed in the Sprint plans at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team Daily Scrum The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one” Sprint Review A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint Sprint Retrospective The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

Events Goals and Deliverables The Sprint A time-box duration which a “Done”, usable, and Increment is created potentially releasable product A working Increment Sprint Planning Part I: What can be done this sprint? Part II: How will the chosen work get done? Product Backlog, Sprint Goal, list of selected Product Backlog Define “Done”, Check List, Sprint Backlog (Sprint Plan: Tasks & Owner) Daily Meeting Inspect and adapt the progress toward the Sprint Goal What did I do yesterday? What will I do today? Do I see any impediment? Updated Scrum Board, Updated Sprint Backlog Burn-Down/Up

Events Goals and Deliverables Sprint Review Inspect the Increment and Adapt the Product Backlog P.O. explain what is “done” and what is not “Done” Dev. Team explain overall achievements Demonstrate the Increment Refine Product Backlog Sprint Retrospective Inspect itself and provide a plan to adjust in the next Sprint A plan with improvements for the next Sprint Product Refining Refine the Product Backlog Refined Product Backlog, Updated Product Backlog Burn-Down/Up 1 Sprint Backlog Sub-Task Provide daily task to execute Working task, Updated Sprint Backlog Burn-Down/Up

The Sprint Framework “The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. This applies to every Sprint”

Time Box Time-boxed events are events that have a maximum duration. 1 Month 2 Weeks The Sprint*1 30 days/4 weeks 2 weeks Sprint Planning 8 hours 4 hours Daily Meeting 15minutes Sprint Review 2 hours Sprint Retrospective 3 hours 1.5 hours Product Refining (<10% Dev. Team time) <2 days <1 days 1 Sprint Backlog Sub-task*2 1-2 days Time-boxed events are events that have a maximum duration. 1: Sprint should be short enough to keep the business risk acceptable to the Product Owner and  to be able to synchronize the development work with other business events 2: The duration of the first tasks should be less than a 1 day

Sprint Planning The goal is to answer the following: Part I: What can be done this sprint? Part II: How will the chosen work get done?

Part I: What can be done this sprint? Input: Product Backlog, latest product Increment, project capacity of the Dev. Team, past performance of the Dev. Team (Team Velocity) Dev. Team to assess and select from the Product Backlog what to execute Craft a Sprint Goal An objective set for the sprint that can be met through the implementation of the Product Backlog It provides guidance to the Dev. Team on why it is building the Increment Size the effort for each item Generate agreed list of the Product Backlog

Part II: How will the chosen work get done? Define what “does “Done” means in practical terms” along with a Check List (verifiable condition - tests) agreed by the P.O. and the Dev. Team Generate the Sprint Backlog: Detailed Sprint Backlog A plan to deliver the selected Product Backlog Detailed description Assigned owner The plan System Design Work needed to convert the product backlog into a working product Increment Task duration should be 1-2 days, for the first few days it should be less than a 1 day Output The Dev. Team is able to explain how the plan will accomplish the Sprint Goal

Part II: How will the chosen work get done? At the first Sprint, the Product Owner collaborates with the Scrum Master and also select the Developer Architect to help him to assemble the team This is the initial Scrum’s Team The Developer Architect is changeable; Thus, he can be replaced any time with another Dev. Engineer First Sprint may used for Go/No Go Prototype product Multiple Development Teams must have one Product Backlog and a definition of "done" that makes their combined work potentially releasable

Daily Scrum The meeting is used to inspect and adapt the progress toward the Sprint Goal Traditionally, 3 questions are asked: What did I do yesterday? What will I do today? Do I see any impediment? Updating the Scrum Board Update, revise, prioritize the progress and assignment – finished and new Updating the Sprint Backlog Burn-Down/Up If needed, a brainstorm/clarification meeting will occur after the Daily Scrum meeting

Daily Scrum Round status check with each individual Update Scrum Boards and Sprint Backlog Burn-Down/Up By Klean Denmark - Daily Sprint Meeting, CC BY-SA 2.0, https://commons.wikimedia.org/w/index.php?curid=19838566

Scrum Board Used to Track Status programmers.stackexchange.com

Burn-Down Chart Describes the remaining workload Note, Story Point are NOT the Sprint Planning Backlog Sub-Task but the Product Backlog Task Describes the remaining workload - The Work units are the Story Points - The Time units are 1 Day https://www.axosoft.com/scrum

Sprint Review Sprint review Inspect the Increment and Adapt the Product Backlog if needed This is an informal meeting, not a status meeting Product Owner explains what have been “Done” and what has not been “Done” The Dev. Team explain what went well, problem and how they are solved Demo the work that has “Done” and answers questions about the Increment; Updating the Product Backlog Burn-Down/Up The Product Owner discusses on the current Product Backlog and expected completion date (if needed) A short discussion on what to do next. This will be input for the next Sprint Planning (Product Refining) Recheck if the marketplace has new value and need to refine the Product Backlog Review the timeline, budget, potential capability, marketplace for the next release of the product The output of the meeting may be a revised Product Backlog

Sprint Retrospective Sprint review Inspect itself and provide a plan to adjust the next Sprint This is a formal meeting, but NO meeting minutes unless agreed by all The purpose of the meeting is: Inspect how the last sprint went in regards to people, relationships, process, and tools; Identify and order the major items that went well and potential improvements; and Create a plan for implementing improvements to the way the Scrum Team does its work The output of the meeting should be a plan with improvements for the next Sprint

Definition of “Done” Done is definable by the Development Organization/Team and should be acceptable by the Product Owner “The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team's current definition of "Done"”

A picture is worth a thousand words… In case you want details…

www.scrumprimer.org

Links to Previous Managements Fundamentals Lectures Topic Description 1 Introduction Describes the difference between Soft Skills and Hard Skills 2 The Iceberg Model Explain why soft skills are the primary contributor to project success 3 Communication Manage one of the main causes for project failure; Get familiar with The C’s of Communication's model 4, part 1 Building A Team Part 1 Learn the 4 stages of team building 4, part 2 Building A Team Part 2 10 steps to develop an effective team 5 Motivation Your best Ally, 3 motivation models