Introduction to Scrum for Project Managers cPrime, Inc. cPrime Training Center 877.7.Learn.0...

download Introduction to Scrum for Project Managers cPrime, Inc. cPrime Training Center 877.7.Learn.0 877.753.1760 650.931.1651 learn@cPrime.com Copyright 2010.

If you can't read please download the document

Transcript of Introduction to Scrum for Project Managers cPrime, Inc. cPrime Training Center 877.7.Learn.0...

  • Slide 1

Introduction to Scrum for Project Managers cPrime, Inc. cPrime Training Center 877.7.Learn.0 877.753.1760 650.931.1651 [email protected] Copyright 2010 cPrime, Inc. Slide 2 Course Description Title: Introduction to Scrum for Project Managers Audience: Project Managers and Team Leaders Course Units: 1 PDU (PMI) Course Award: Certificate of Completion Course Time: 1 hour and 15 minutes Updated: January 27, 2010 Prerequisites: None Resources: http://www.cPrime.com/about /scrum_faq.htmlhttp://www.cPrime.com/about /scrum_faq.html http://www.cPrime.com/Training/courses.html http://www.cprime.com/knowledge/articles.html http://www.cprime.com/knowledge/resources.html Instructors: Instructor Questions & Answers http://www.cprime.com/forums/http://www.cprime.com/forums/ cPrime Training Center, [email protected], 877.7.Learn.0, 877.753.1760, [email protected] Copyright 2010 cPrime, Inc. 2 Slide 3 Course Goals The purpose of the course is to provide a perspective on Scrum that makes sense to experienced Project Managers (PMs) and Team Leaders. Copyright 2010 cPrime, Inc. 3 Traditional project managers and team leaders are familiar with concepts such as schedule estimation, Gantt charts and change control systems. They may find Scrum difficult to understand at first. A Scrum process may seem alien, chaotic or underplanned when compared to the formal structure of more familiar projects. This course will familiarize you with the Scrum process, concepts and tools based on your existing project management and software development experience. After this course, you should be able to fit seamlessly into an Agile Scrum software development environment and begin to take on responsibilities and leadership roles. Additional training is needed to be a ScrumMaster or Product Owner. Slide 4 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 4 Slide 5 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 5 Slide 6 Overview Scrum makes sense to trained Project Managers and Team Leaders. Copyright 2010 cPrime, Inc. 6 Scrum did not arise in a formal PM context. Scrum grew from existing PM methodologies. Scrum can seem alien, or wrong. It makes unfamiliar optimizations and tradeoffs. It uses unfamiliar terms. Your work experience supports you learning Scrum. The philosophy of Scrum is simple. Learning how to do Scrum takes days. We can explain the basic concepts quickly. Slide 7 Overview Copyright 2010 cPrime, Inc. 7 Scrum arises from basic principles. Define success. Define failure. Optimize the process for success. Slide 8 Overview Scrum Summary Scrum is a project management framework for software development with: A short, fixed schedule per cycle with adjustable scope A repeating Cadence of events, milestones and meetings A practice of implementing and testing new requirements, or Stories, to ensure some work is release-ready after each cycle, or Sprint Copyright 2010 cPrime, Inc. 8 Scrum uses standard project management concepts with different terminology and some new Best Practices. Scrum provides customer satisfaction by optimizing turnaround time and responsiveness to requests. Slide 9 Overview Agile Software Development Individuals and interactions are more essential, productive and important than processes and tools. Copyright 2010 cPrime, Inc. 9 Working software is the product for the software developers not comprehensive documentation. Customer collaboration matters more and guarantees customer satisfaction more than higher- level contract negotiation. Responding to change is critical to delivering what the customer wants not just following a plan. Slide 10 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 10 Slide 11 Scrum Process Scrum is a Lightweight Process Framework for Agile Software Development. Copyright 2010 cPrime, Inc. 11 Scrum is the most widely-used of the Agile process frameworks. A "process framework" is a particular set of practices that must be followed in order for a process to be consistent with the framework. "Lightweight" means that the overhead of the process is kept as small as possible to maximize the amount of productive time available for getting useful work done. Slide 12 Scrum Process Benefits An Agile Scrum process benefits the organization by helping it to: Increase the quality of the deliverables Cope better with change and expect the changes Provide better estimates while spending less time creating them Be more in control of the project schedule and state Copyright 2010 cPrime, Inc. 12 As a result, Scrum projects achieve higher customer satisfaction rates. Slide 13 Scrum Process Success and Failure Success Provide the right features to the customer at the right time for an acceptable cost Success in Scrum builds company success! Copyright 2010 cPrime, Inc. 13 Failure Provide the right features at the wrong time Provide the wrong features at any time Many software failures mean company failure! Slide 14 Scrum Process The Right Time The customer determines the right time. Copyright 2010 cPrime, Inc. 14 Some applications web apps are subjected to a continuing stream of feature requests. Requests come in over time with varied urgency. Features are desired when requested. Scrum is ideal for rapidly changing, accumulating requirements. Slide 15 Scrum Process The Right Time Some applications flight control software may have a fixed set of features. Requirements are fairly static. Features may not be usable until the platform is ready. Agile can speed up feature development and delivery. Copyright 2010 cPrime, Inc. 15 Project Managers must meet customer and project needs. Slide 16 Scrum Process What is Success? How is project success related to the schedule of feature delivery? Success depends on feature delivery NOW. Copyright 2010 cPrime, Inc. 16 The Ideal Provide every useful new feature the day it is requested. Key elements of ideal solution Instant turnaround (zero time to feature delivery) Maximum responsiveness (Yes to every request) Other definitions of success are possible! They could lead to optimal processes different from Scrum. Slide 17 Scrum Process Achieve Success How can we approximate the ideal of success in the real world? We develop a few features quickly! Copyright 2010 cPrime, Inc. 17 Instant turnaround? > Quick turnaround! Work in short development cycles called Sprints. Within the Sprint, reduce risk and maximize delivered value by finishing each feature before starting the next. Maximum responsiveness? > Few features per Sprint! Prioritize feature requests in rank order and burn down the list from the top. Revise the ranked feature list before each development Sprint based on a current evaluation of customer needs. Slide 18 Scrum Process Approach the Ideal Scrum is a project management framework designed to address rapidly-changing customer needs. Copyright 2010 cPrime, Inc. 18 Scrum is optimized for projects where: Needs change quickly the scope is very fluid. Plenty of implementation can be done quickly. Long lead times are usually not a major issue. Project is cyclic it always starts over in a few weeks, so new needs can be addressed then. It is not linear with only one chance to do it right. Success is measured by customer satisfaction with responsiveness and turnaround time. Slide 19 Scrum Process Who Benefits Benefits to Customer Customers find that the software development company is more responsive to development requests. High-value features are developed and delivered faster with short cycles than with the longer cycles favored by classic Waterfall processes. Copyright 2010 cPrime, Inc. 19 Benefits to Project Managers Project Managers and others who fill the ScrumMaster role find that planning and tracking are easier and more concrete compared to Waterfall processes. The focus on task-level tracking, the use of Burndown Charts to display daily progress, and the Daily Scrum meetings give the Project Manager tremendous awareness about the state of the project at all times. This awareness is key to monitoring the project and to catching and addressing issues quickly. Slide 20 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 20 Slide 21 Scrum vs. Waterfall How does Scrum differ from the classic Waterfall project management? New trade-offs between schedule and scope New timeboxes New roles New language New artifacts Copyright 2010 cPrime, Inc. 21 Scrum Characteristics Meetings Sprint Planning Meeting, Daily Scrum, Retrospective Meeting Roles ScrumMaster, Product Owner, Team Artifacts Sprint Backlog, Product Backlog, Burndown Chart Slide 22 Scrum vs. Waterfall Timeboxes A Timebox is a span of time of fixed duration dedicated to a particular purpose with strictly enforced boundaries. Scrum defines several "official" timeboxes, such as the Sprint and critical meetings, but the concept of a timebox is an important theme that permeates Scrum projects. Copyright 2010 cPrime, Inc. 22 Scrum is a schedule-oriented, rather than scope-oriented, approach to managing projects. This means that the schedule overrides other considerations. Thus all meetings and activities are timeboxed, or kept within the planned duration. The timebox attitude promotes focus and quick decision-making. It encourages people to make decisions that are "good enough" now instead of "perfect" later. It is a key element in the constant effort to remain pragmatic and flexible in the face of the constant temptation to strive for perfection. The Scrum timeboxes include the Sprint and critical meetings. The meetings are the Sprint Planning meeting, the Daily Scrum meeting, the Sprint Review meeting and the Retrospective meeting. Each timebox has a specified start and duration. Work is not allowed to extend beyond it. Slide 23 Scrum vs. Waterfall Meetings & Activities The diagram shows how the different meetings and activities relate to each other. Copyright 2010 cPrime, Inc. 23 Within a product roadmap, a customer release cycle includes many 2-4 week Sprints. Each Sprint develops a few features at a time. The Sprint begins with the product Vision, including the features, or Stories, that the Sprint will develop. Slide 24 Scrum vs. Waterfall Meetings & Activities Release planning and Sprint planning occur next, with the Sprint Planning Meeting to kick off the Sprint. Copyright 2010 cPrime, Inc. 24 Then development begins! Daily Scrums track day-to-day issue resolution and Task Breakdown adjustments. At the end of the Sprint, the Sprint Review Meeting validates the feature for release and deployment while planning continues for the next Sprint. The Retrospective Meeting covers lessons learned. Slide 25 Scrum vs. Waterfall Scope Scrum optimizes the balance of schedule and scope, unlike Waterfall project management. Copyright 2010 cPrime, Inc. 25 Waterfall Freezes scope Customer requirements contract Estimates schedule Delivery time is intended Scrum Freezes schedule Short Sprint by short Sprint Estimates scope Top feature, then next feature Slide 26 Scrum vs. Waterfall Adjust Scope Scrum adjusts the scope, not the schedule. Know what to freeze (the schedule) and what to adjust (the scope). Copyright 2010 cPrime, Inc. 26 Waterfall schedules disappoint customers. Adjust the schedule to meet scope Then adjust the scope to meet later release dates Scrum delivers! Never changes the schedule, or Sprint Adjusts the scope if needed to meet release dates Slide 27 Scrum vs. Waterfall 1 Feature at a Time Scrum produces one feature at a time during a Sprint. Copyright 2010 cPrime, Inc. 27 Waterfall follows each step in a linear path. Plans all features for simultaneous implementation Designs all features Implements all features Tests all features Fixes all features bugs Scrum completes one robust feature quickly, and repeats. Plans a few features, or Stories, in rank order for the cycle, or Sprint Designs a Story Implements a Story Tests a Story Fixes all bugs for the Story Starts the next Story in rank order Slide 28 Scrum vs. Waterfall Feature Complete Each Story in a Scrum Sprint feels complete. Copyright 2010 cPrime, Inc. 28 Each Sprint is like a series of tiny waterfalls from end to end. Many Sprints and Stories achieve the customer release on time. Work estimates are much easier. Work proceeds and completes more logically. Feature granularity a few Stories per Sprint Feature development one by one for reduced risk Sprint by Sprint Waterfall develops all features in parallel to complete at the end of the schedule, which risks the delivery of no working features. Scrum develops one feature at a time in rank order, completing some features within the long-term customer requirements contract, or software roadmap. Scrum offers many Best Practices for quick turnaround and maximum responsiveness. Slide 29 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 29 Slide 30 Scrum vs. Normal Project Management Customary practices are normal PM Copyright 2010 cPrime, Inc. 30 Scrum makes a less-familiar tradeoff in the iron triangle of scope, schedule and resources. Most non-software and long-term software projects have a specified scope. Project Managers estimate and adjust the schedule to guarantee the scope. Scrum projects have a specified schedule. The Team estimates and adjusts the scope to guarantee the schedule. Scrum Best Practices are unfamiliar to project managers. Slide 31 Scrum vs. PM PMs Iron Triangle Start Project Scope Resources Schedule Budget Copyright 2010 cPrime, Inc. 31 Slide 32 Scrum vs. PM PMs Iron Triangle Scope Increases Resources Schedule Budget Scope Copyright 2010 cPrime, Inc. 32 Slide 33 Scrum vs. PM PMs Iron Triangle Schedule Increases Resources Schedule Budget Scope Copyright 2010 cPrime, Inc. 33 Slide 34 Scrum vs. PM PMs Iron Triangle Schedule Increases Resources Schedule Budget cPrime Scope Copyright 2010 cPrime, Inc. 34 Slide 35 Scrum vs. PM Why Not Freeze Scope? The first Scrum Best Practice is to freeze the Sprint schedule! Adjust the scope of the features in the Sprint. Copyright 2010 cPrime, Inc. 35 We cannot estimate better, even with more data. Software development involves constant invention, not repetition of standard steps. Accurate effort estimation is impossible. We cannot guarantee both schedule and scope. Attempts to constrain both produce high uncertainty and high risk to customer satisfaction with our responsiveness and good turnaround time. Risk is minimized if only one variable is constrained Scope Scrum chooses a predictable schedule over a predictable scope. We are much more likely to deliver on a commitment to schedule than on a commitment to scope. We communicate the schedule commitment to customers and then meet their expectations. Slide 36 Scrum vs. PM Scrums Iron Triangle Start Scrum Project Resources Schedule Budget Scope Copyright 2010 cPrime, Inc. 36 Slide 37 Scrum vs. PM Scrums Iron Triangle Scope Increases Resources Schedule Budget cPrime Scope Copyright 2010 cPrime, Inc. 37 Slide 38 Scrum vs. PM Scrums Iron Triangle Adjust Scope to Keep Schedule Resources Schedule Budget Scope Copyright 2010 cPrime, Inc. 38 Slide 39 Scrum vs. PM Product Management Scrum is different from traditional ProDUCT Management. Copyright 2010 cPrime, Inc. 39 In traditional software development, a Product Manager receives requirements from customers and updates the Product Requirements Document (PRD). He also uses a marketing MRD. In Scrum projects, the Product Manager updates the Product Backlog, which contains requirements intended for future implementation. The specifications, or Product Backlog Items (PBIs), are brief and easy to read. The Product Manager remains responsible all customer-facing deliverables, including software, user documentation and marketing collateral. The people who create these deliverables may or may not be part of the Team, but their work must be planned. Product Managers work very closely with development Teams, collaborating on a daily basis to address all product-related issues. Scrum requires this tight coupling and does not tolerate an "us vs. them" attitude between Product Management and Engineering. Since the Product Manager finalizes all priorities for the Team's development work, he can tap time from the Team to handle urgent issues like customer Requests For Information (RFIs) as long as he works with the ScrumMaster to reduce scope for the current Sprint. Slide 40 Quiz 1 Scrum Process Its time for a fast quiz to check your learning! Copyright 2010 cPrime, Inc. 40 If you would like to review any slide, use the Play, Pause and Stop buttons and the Outline tab to navigate the course. When you are ready, begin the quiz. If you answer a question incorrectly, you will be given 3 chances to answer. You will be able to review any slide during the quiz. Slide 41 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 41 Slide 42 Scrum Concepts Story Sprints Self-Organization Shipped! Copyright 2010 cPrime, Inc. 42 Slide 43 Scrum Concepts Story The product requirements of Scrum are chunked into a small set called a Story, or feature, with a short narrative description, somewhat like a use case or test case. The Product Backlog includes all requirements not yet scheduled for implementation. Copyright 2010 cPrime, Inc. 43 There are three types of Stories: User Story, or user-facing functional requirement Technical Story, or supporting non-functional requirement Defect, or bug report Stories use a common format for easy reading. Solid Stories give enough detail to estimate the Task Breakdown and the Velocity of the Sprint. Slide 44 Scrum Concepts User Story A User Story describes what the user does with the software and how the software responds. A User Story is a functional requirement that resembles a use case and test case. Copyright 2010 cPrime, Inc. 44 The Scrum Product Owner is responsible for and writes the User Stories. The User Story includes: Name Descriptive text References to external documents and screen shots Testing information for implementation Sample User Story Slide 45 Scrum Concepts Technical Story A Technical Story is a non-functional requirement that describes the functionality supporting the user-facing features in User Stories. Copyright 2010 cPrime, Inc. 45 Technical Stories are usually written by Team members and are added to the Product Backlog. The Product Owner must be familiar with these Stories and understand the dependencies between these and User Stories in order to rank all Stories for implementation. Sample Technical Story Slide 46 Scrum Concepts Defect A Defect, or bug report, is a description of the failure of the product to behave as designed and expected. It usually includes a description of the missing or incorrect functionality, an analysis of the problem and a proposal to fix the bug. Copyright 2010 cPrime, Inc. 46 Defects are stored in a bug-tracking system, which can also store the Product Backlog to eliminate duplicate entry of items. The Product Owner tracks each Defect in the Product Backlog for sequencing and scheduling in a Sprint. Sample Defect Slide 47 Scrum Concepts Sprint Project Managers say Schedule. ScrumMasters say Sprint! Copyright 2010 cPrime, Inc. 47 Small teams of 3-9 people work in short Sprints of 2-4 weeks to implement Stories in rank order. Sprint Goal To produce release-quality increments in functionality. Experiment with the length of Sprint that works best for your company and then make all Sprints uniform to simplify planning. The scope, or Sprint Backlog of Stories, is frozen when the Sprint startsno change requests allowed! Slide 48 Scrum Concepts Sprint Team Members Collaborate and self-organize Track their progress and update tasks when finished Copyright 2010 cPrime, Inc. 48 The chart provides an example of how workdays can be grouped into Sprints, and Sprints grouped into Releases. The example assumes that each Sprint contains 10 workdays and each Release contains 2 Sprints. Slide 49 Scrum Concepts Self-Organize Teams self-organize to best apply member skill sets coding, test development, testing. Copyright 2010 cPrime, Inc. 49 The ScrumMaster and Product Owner do not assign tasks. There is no formal PM to assign tasks. Team members collaborate to complete Stories quickly instead of working on separate Stories in parallel. Slide 50 Scrum Concepts Self-Organize The Agile philosophy holds that the best way to meet customer needs is through the collaboration of a committed group of people who focus on achieving results quickly with as little process overhead as possible. Copyright 2010 cPrime, Inc. 50 We must trust people and their ability to collaborate more than we trust any particular process. People can succeed without a formal process, but no process can succeed without people. An Agile process best taps the abilities of team members by emphasizing collaboration rather than relying on the structure of a process to guarantee success. Slide 51 Scrum Concepts Shipped! At the end of a Sprint, completed Stories are Shipped. Incomplete Stories are not. Copyright 2010 cPrime, Inc. 51 No exceptions! The schedule is not extended to complete work. Slide 52 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 52 Slide 53 Scrum Roles The three roles defined in Scrum are the ScrumMaster, the Product Owner and the Team with Team members. The people who fulfill these roles work together closely, on a daily basis to ensure the smooth flow of information and the quick resolution of issues. ScrumMaster Product Owner Team Copyright 2010 cPrime, Inc. 53 Slide 54 Scrum Roles ScrumMaster The ScrumMaster is an important leadership role with essential responsibilities. The ScrumMaster is the keeper of the process. He is responsible for making the process run smoothly, for removing obstacles that impact productivity, and for organizing and facilitating the critical meetings. Manage the process by enforcing, tracking and expediting problem resolution Run the Daily Scrum and Sprint Planning Meetings Often a Project Manager Copyright 2010 cPrime, Inc. 54 The ScrumMaster is responsible for enforcing the process, tracking progress and expediting problem resolution. He keeps the team focused and productive, protects them from interference and ensures the swift removal of roadblocks. Slide 55 Scrum Roles ScrumMaster The ScrumMasters responsibilities are to: Remove the barriers between the development Team and the Product Owner so that the Product Owner directly drives development Teach the Product Owner how to maximize return on investment (ROI) and meet objectives through Scrum Improve the lives of the development Team by facilitating creativity and empowerment. Improve the productivity of the development Team in any way possible. Improve the engineering practices and tools so that each increment of functionality is potentially shippable. Keep information about the Team's progress up to date and visible to all parties Copyright 2010 cPrime, Inc. 55 Slide 56 Scrum Roles Product Owner The Product Owner is the keeper of the requirements. He provides the "single source of truth" for the Team regarding requirements and their planned order of implementation. Copyright 2010 cPrime, Inc. 56 Responsible for Stories and release dates Working with customers to define user-facing features Collaborating with engineers, QA, Services and Support personnel to work out the order of implementation of all requests Often a Product Manager Slide 57 Scrum Roles Product Owner The Product Owner works closely with the Team to define the User Stories, Technical Stories and Defects, to document the Stories as needed, to determine the order of their implementation and to decide when to release product upgrades to customers. He maintains the Product Backlog, the repository for this information, keeping it up-to-date and at the level of detail and quality the Team requires. Copyright 2010 cPrime, Inc. 57 The Product Owner sets the customer release schedule and makes the final call as to whether implementations have the features and quality required for release. The Product Owner is the interface between the Team and the business, the customers and their product-related needs. Slide 58 Scrum Roles Team The Team gets the work done. Self-organizes cross-functional members to implement and test features Usually software and test engineers, database architects, UI developers Copyright 2010 cPrime, Inc. 58 The Team is a self-organizing, cross-functional group of people who do the hands-on work of developing and testing the product. Since the Team is responsible for producing the product, it must also have the authority to make decisions about how to perform the work. The Team is therefore self-organizing: Team members decide how to break work into tasks and how to allocate tasks to individuals throughout the Sprint. The Team size is 3-9 people. More people make communication difficult, while fewer people lead to low productivity and fragility. Team members collaborate and dynamically allocate tasks. Slide 59 Scrum Cadence A Scrum schedule, or Sprint, is really a Cadence, a repeating sequence of meetings, activities, milestones and events. Copyright 2010 cPrime, Inc. 59 The content of the Cadence varies by role or organization for the Team, Product Management, Customer Support and Professional Services. Gantt Charts are possible but not of much value. Slide 60 Scrum Cadence Development Team A Development Team Cadence repeats every 2-4 weeks. Copyright 2010 cPrime, Inc. 60 Slide 61 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 61 Slide 62 Scrum Phases PM Renamed A common Best Practice in any project management methodology is consistent language. Scrum has its own terms and mappings to customary practices in project management. Copyright 2010 cPrime, Inc. 62 Project Managers say Plan, Execute, Monitor & Control, and Close. There are many tools, including Gantt charts, to accomplish this in long-term software projects. Scrum maps phases to normal project management and offers effective tools to achieve each phase in the 2-4 week Sprint. Just like the activities mapped well plan, design, implement, test and fix bugs the phases are familiar Planning, Execution with Monitoring and Control, and Closing. ScrumMasters say Define the Backlog & Plan the Sprint; Develop & Test with Stickies, Scrums & Burndown; and Demo, Release & Retrospective. Each phase has important tools for the project manager and team. Most Project Management process groups also map to categories of Scrum activities. Slide 63 Phase 1 Define Backlog & Plan Sprint Project Managers say Plan. Scrum Masters say Define the Backlog and Plan the Sprint. Copyright 2010 cPrime, Inc. 63 Planning maps to defining the Product Backlog and planning the next Sprint. 1.Begin with the previous Sprints Retrospective Meeting, a familiar Best Practice in project management. 2.Review and revise the Product Backlog and rank the Stories going into the next Sprint. The Product Owner and Team write any new Stories for the Sprint. Determine the Definition of Done for the top Stories. 3.At the Sprint Planning meeting, estimate the time to complete the Stories in rank order and assign them to the Sprint until its capacity is filled in the Sprint Backlog. Plan the Task Breakdown, breaking the Stories into trackable tasks that the Team assigns to Team members. Slide 64 Phase 1 Sprint Backlog Project Managers say Scope. ScrumMasters say Sprint Backlog. The Sprint Backlog is the defined and ranked set of requirements planned for implementation in a Sprint. Copyright 2010 cPrime, Inc. 64 The Sprint Backlog is the set of User Stories, Technical Stories and Defects planned for implementation in a Sprint. These requirements are also called Product Backlog Items, or PBIs, because they come from the Product Backlog of all feature requests and bugs over time. The PBIs in the Sprint Backlog must be ranked in the desired order of implementation, which is the Product Owners responsibility. The ranking reflects the urgency, or value, of the item along with any dependencies that exist between items. In an ideal case, all Team members work on PBI #1 until it is complete, meaning that the implementation has passed all acceptance tests. Only then do they begin work on PBI #2. This sequence continues until the Team has worked through all items in the Sprint Backlog. Slide 65 Phase 1 Sprint Backlog The chart shows a typical Sprint Backlog of Stories for implementation. Copyright 2010 cPrime, Inc. 65 The Sprint Backlog is a very useful Best Practice. The importance of ranking becomes clear when progress does not go as well as expected. Perhaps only 50% of the work required by the Sprint Backlog can actually be done in the time available. By working on PBIs in rank order, the Team can complete the most important half of the Sprint Backlog. A different kind of ranking, or parallel work across items, would have resulted in less or even no value delivered by the Sprint. Slide 66 Phase 1 Sprint Planning Meeting Project Managers say Productivity. ScrumMasters say Velocity. Velocity is the metric for a Teams ability to get work done in a Sprint. Copyright 2010 cPrime, Inc. 66 An essential Best Practice is the Sprint Planning Meeting. The ScrumMaster facilitates this Sprint Kick-Off meeting, which is attended by the Team members and the Product Owner. The purpose of this meeting is to select the Stories, or Product Backlog Items (PBIs), that the Team intends to implement in this Sprint. To accomplish this: The amount of work required to implement each item must be known. The sizes of the PBIs of interest are either estimated during the meeting or already known from previous estimation. Enough of the top-priority PBIs must have been ranked by the Product Owner, in advance, to fill the Team's capacity for this Sprint. The Team's capacity to do work in this Sprint, or its Velocity, must have been estimated prior to the meeting. Slide 67 Phase 1 Sprint Planning Meeting The Team estimates each Story in rank order. The most common estimation technique is "Planning Poker", a voting approach designed to avoid influence bias. The Team discusses each PBI, asks clarifying questions of the Product Owner and votes, in one or more rounds, until their estimates converge. The ScrumMaster facilitates this process and moves the PBI to the Sprint Backlog after each estimate is completed, until the Team's capacity for this Sprint has been filled. Copyright 2010 cPrime, Inc. 67 After the Sprint Backlog has been defined, the Team spends additional time creating a Task Breakdown of all tasks required to implement each PBI. This work is done in the way that works best for the Team. Some Teams do this work during the Sprint Planning meeting, which should be timeboxed to no more than 4 hours, or after the meeting. A good rule of thumb is that tasks usually take 2-16 hours to complete. All tasks are trackable and tracked. Slide 68 Phase 1 Task Breakdown Project Managers say Work Breakdown Structure. ScrumMasters say Task Breakdown. The Task Breakdown for a Story is the set of tasks whose execution implements the desired functionality and whose total effort defines the effort required for the implementation. Copyright 2010 cPrime, Inc. 68 Each task in the Task Breakdown contains essential information: Task Owner Task Status Pending, Started or Complete Estimated Time to Complete Actual Time to Complete Related User Story, Technical Story and Defect Names Slide 69 Phase 2 Develop & Test Project Managers say Execute. Scrum Masters say Develop and Test. Copyright 2010 cPrime, Inc. 69 Executing maps to the development and test work for implementing requirements, or Stories, in Scrum software development projects. Planning pays off! Follow the Task Breakdown and ask for help as early as possible if there are complications. Adjust the Task Breakdown if reality disagrees with the plan. Team members do the work collaboratively or individually as their assignments require and develop. Each Team member must update the completion of a task immediately! Most Teams empower each person to update their individual tasks in common applications. Slide 70 Phase 2 Stickies, Scrums & Burndown Project Managers say Monitor and Control. Scrum Masters say Move the Stickies and Have Daily Scrums. Copyright 2010 cPrime, Inc. 70 Monitoring & Controlling maps to updating the Burndown Chart and holding Daily Scrum Meetings. Moving the Stickies means adjusting the tasks and owners on the Task Breakdown. Daily Scrums are daily status meetings to resolve issues proactively. Typically the Team members do not repeat their status reports. The ScrumMaster can see that everyone is on track. The Burndown Chart can track the completion of Stories in the Sprint. Slide 71 Phase 2 Daily Scrums An important Best Practice is the Daily Scrum meeting. This minimalist status meeting is timeboxed to 15 minutes to ensure that: Questions are answered quickly Issues are identified and addressed quickly Team members have a common understanding of how the Sprint is progressing Copyright 2010 cPrime, Inc. 71 The Daily Scrum meeting should be held at the same time each day, at a time that works best for the Team. The meeting is a daily huddle to anticipate and identify problems. If someone is behind in their task, the problem must be solved fast after the meeting perhaps adjusting task assignments will prevent the adaptation of the scope to reduce functionality. Quality is important! Impacts to the software architecture can be called out and assessed more quickly. Testing can also be assigned based on who has time and visibility as the Sprint progresses. Slide 72 Phase 2 Daily Scrums The ScrumMaster facilitates this meeting, which all Team members attend. The ScrumMaster works to keep people focused and the meeting in its timebox, and makes sure that each Team member describes these three things: What I've done since the last Daily Scrum meeting What I plan to do before the next Daily Scrum meeting What issues I'm facing that may need help to resolve Copyright 2010 cPrime, Inc. 72 It is important that the issues be resolved, but afterwards, not in the meeting itself. Otherwise, the meeting grows, violates its timebox and wastes time for the Team members who are not involved with specific issues. Attendance by the Product Owner is optional and at the discretion of the Team. The Product Owner should only attend if his presence is useful. If the Product Owner does attend, his purpose is to take note of any Story, or requirements, issues so that he can address them with the relevant Team members after the meeting. Slide 73 Phase 2 Burndown Chart Project Managers say Estimate-to- Complete Chart. ScrumMasters say Burndown Chart. The Burndown Chart plots Actual Work Remaining versus Time by Day in a Sprint. The chart compares actual and expected progress, and shows whether the team is ahead or behind expectations. Copyright 2010 cPrime, Inc. 73 Slide 74 Phase 2 Burndown Chart At the start of the Sprint, the Team breaks down each item in the Sprint Backlog into tasks with a time estimate for each. Executing the tasks completes the implementation. During the Sprint, the Team member completes a task and immediately marks that task as complete. Copyright 2010 cPrime, Inc. 74 Plotting the amount of Uncompleted Task Work against Time from the start of the Sprint produces a Burndown Chart. Burndown and Burnup charts can also be plotted for multi- Sprint Releases, when longer time scales are of interest. Slide 75 Phase 2 Burndown Chart The diagonal line from top left to lower right shows the ideal "burndown" of Work versus Time. The line ends with zero remaining work at the end of the Sprint. Copyright 2010 cPrime, Inc. 75 The blue bars in the chart show the amount of work actually remaining each day. If the bars are below the diagonal line, the project is ahead of schedule. If the bars are above the diagonal line, the project is behind schedule. The green bars in the chart show the burnup status of the Sprint at PBI, or Story, granularity instead of task granularity. The green bars form the Burnup Chart showing Work Accomplished versus Time. Stories that passed Acceptance Testing and reached release quality are Work Accomplished. Slide 76 Phase 3 Demo, Release & Retrospective Project Managers say Close. ScrumMasters say Demo, Release and Have the Retrospective Meeting. Copyright 2010 cPrime, Inc. 76 Closing maps to demonstrating the completed work in the Sprint Review Meeting, releasing the updated product and holding the Retrospective Meeting to capture lessons learned. At this point, the cycle begins again. The next Sprint kicks off with the Sprint Planning Meeting using the updated Product Backlog. Slide 77 Phase 3 Sprint Review Meeting The Sprint Review Meeting, or Sprint Demo, is held at the end of the Sprint. In this meeting, the Team demonstrates the Sprint's completed Product Backlog Items to the Product Owner and other interested parties. This meeting gives the Product Owner a final chance to make a go/no-go release decision. It also gives the Team members a chance to show off their work. Copyright 2010 cPrime, Inc. 77 The Sprint Review Meeting provides the Product Owner a final opportunity to decide whether the completed work is as desired for release. Surprises are rare at this point because the Product Owner reviews the development status throughout the Sprint. Some companies replace this formal review meeting with PBI-level demonstrations to the Product Owner during the Sprint in order to achieve the same results. Slide 78 Phase 3 Sprint Retrospective Meeting The Sprints Retrospective Meeting is held after the Sprint Review Meeting. The Retrospective Meeting provides the Team with an opportunity to learn, and therefore improve, from the experience of the just-concluded Sprint. The Retrospective meeting is facilitated by the ScrumMaster. The Meeting is attended by the Product Owner, the Team members and anyone else whose contribution is desired. Copyright 2010 cPrime, Inc. 78 The ScrumMaster works to keep people focused, complete the meeting within its planned timebox of 1-3 hours, and make sure that each participant describes these three things: The ScrumMaster records this information and facilitates discussion during or after its collection to identify what changes the Team intends to implement for the next Sprint. What worked well and what we should do again What did not work well What changes we should make for next time Slide 79 Quiz 2 Scrum Projects Its time for a fast quiz to check your learning! Copyright 2010 cPrime, Inc. 79 If you would like to review any slide, use the Play, Pause and Stop buttons and the Outline tab to navigate the course. When you are ready, begin the quiz. If you answer a question incorrectly, you will be given 3 chances to answer. You will be able to review any slide during the quiz. Slide 80 Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 Scrum Projects Scrum Summary Test Course Copyright 2010 cPrime, Inc. 80 Slide 81 Scrum Summary Copyright 2010 cPrime, Inc. 81 Scrum uses standard Project Management concepts with different terminology and some new Best Practices. Scrum addresses customer satisfaction by optimizing turnaround time and responsiveness to customer requests. Scrum is a project management framework for software development with: A short, fixed schedule per Sprint with adjustable scope A repeating Cadence of events, milestones and meetings A practice of implementing and testing new Stories, to ensure some work is release-ready after each Sprint Slide 82 Scrum References Scrum and XP from the Trenches: How we do Scrum by Henrik Kniberg Agile Project Management with Scrum by Ken Schwaber Agile Project Management by Jim Highsmith Agile Estimating and Planning by Mike Cohn User Stories Applied by Mike Cohn Lean Software Development by Mary and Tom Poppendieck Agile Software Development by Robert Martin Agile Testing by Lisa Crispin and Janet Gregory Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt Collaboration Explained by Jean Tabaka The Software Project Manager's Bridge to Agility by Michele Sliger and Stacia Broderick Copyright 2010 cPrime, Inc. 82 Slide 83 Questions & Answers Resources: FAQ http://www.cPrime.com/about /scrum_faq.htmlhttp://www.cPrime.com/about /scrum_faq.html Course List http://www.cPrime.com/Training/courses.htmlhttp://www.cPrime.com/Training/courses.html Articles http://www.cprime.com/knowledge/articles.htmlhttp://www.cprime.com/knowledge/articles.html References http://www.cprime.com/knowledge/resources.htmlhttp://www.cprime.com/knowledge/resources.html Instructors: Instructor Questions & Answers http://www.cprime.com/forums/http://www.cprime.com/forums/ cPrime Training Center, [email protected], 877.7.Learn.0, 877.753.1760, [email protected] Copyright 2010 cPrime, Inc. 83 Slide 84 Test Scrum for Project Managers Its time for the test to earn your certificate of completion and 1 PDU of course credit! Copyright 2010 cPrime, Inc. 84 If you would like to review any slide, use the Play, Pause and Stop buttons and the Outline tab to navigate the course. When you are ready, begin the test. If you answer a question incorrectly, you will be given a second chance to answer. You will not be able to review any slides during the test. Slide 85 Course Survey Congratulations! You have successfully completed Introduction to Scrum for Project Managers! Did you enjoy the course? Please take a moment to complete the course survey as part of our continuous improvement of course material. You can also refer a friend to this course! For Scrum Workshops and Certified ScrumMaster classes, visit cPrimes Course List: http://www.cPrime.com/Training/courses.html http://www.cPrime.com/Training/courses.html Copyright 2010 cPrime, Inc. 85 Slide 86 Claim Your 1 PDU with PMI Congratulations! Register your completion of the cPrime course Introduction to Scrum for Project Managers with the Project Management Institute at: https://www.pmi.org/CCRS/ https://www.pmi.org/CCRS/ Copyright 2010 cPrime, Inc. 86 Slide 87 Quiz 1 Questions Scrum is a Lightweight Process Framework for software development. T/F Scrum customers want which of the following? Xchoice: All desired features, Immediate releases, Acceptable cost, All of the above Scrum freezes what constraint on project completion? Xchoice: Schedule, Scope, Schedule and Scope, Resources Developing one feature, or set of Stories, at a time achieves what best approximation of the ideals? Xchoice: Quick turnaround time, Most value for responsiveness, A and B, Less risk of failure, All of the above Match 3 Scrum practices and 3 Waterfall practices. Match: Scrum: Adjust the scope and freeze the Sprint, Develop brief User Stories, Technical Stories and Defects, Reduce risk with short Sprints; Waterfall: Increase the scope and then increase the schedule, Create extensive requirements documentation, Increase risk with one linear process Slide 88 Quiz 2 Questions Scrum User and Technical Stories include which information? Xchoice: Name and Description, How to Test, Who broke the functionality, Where to find screen shots, A, B and D above. A Story is solid enough when what happens? Xchoice: It just feels right even without a Sprint Backlog, The Team can estimate the Task Breakdown and Velocity, The ScrumMaster says so but isnt responsible, The Sprint is over but no features can ship, The budget runs out. Match the role with its responsibilities. Match: ScrumMaster: Problem resolution, Status and progress, Removing barriers between the Product Owner and Team; Product Owner: Single source of Story truth, Maintaining the Product Backlog, Interfacing between the Team and the customers and business ; Team member: Creating and adjusting the Task Breakdown, Collaborating on the top Story. Match the language of traditional project managers and ScrumMasters by the meaning of their terms. Match: Schedule = Sprint, Plan = Define Backlog and Plan Sprint, Scope = Sprint Backlog, Productivity = Velocity, Work Breakdown Structure = Task Breakdown, Execute = Develop and Test, Estimate-to-Complete Chart = Burndown Chart. Match the meeting with its purpose. Match: Retrospective = Lessons Learned, Sprint Planning = PBIs and Planning Poker, Daily Scrum = Daily Status and Problem Resolution, Sprint Review = Sprint Demo for Release, Cadence Practice = Not a Scrum Meeting. Slide 89 Test Questions Scrum freezes what constraint on project completion? Xchoice: Schedule, Scope, Schedule and Scope, Budget How does the Scrum process derive its founding principles? Xchoice: Scrum > Agile software development, Agile software development > Lightweight process framework > Scrum, Scrum > Waterfall, Scrum > Normal Project Management, Scrum > RAD Scrum gives customers what? Xchoice: Quick turnaround time, Most value for responsiveness, Acceptable cost, Less risk of failure, All of the above Scrum uses extensive requirements documentation. T/F How many Stories are in a Sprint? Xchoice: Only one in all cases, One or more if practical, One major User Story with supporting Technical Stories and Defects, Two User Stories with co-dependencies, The Team decides in the Sprint Planning Meeting. A Story is solid enough when what happens? Xchoice: It just feels right even without a Sprint Backlog, The Team can estimate the Task Breakdown and Velocity, The ScrumMaster says so but isnt responsible, The Sprint is over but no features can ship, The budget runs out. Match the Scrum phases and meetings. Match: Phase 1: Sprint Planning, Phase 2: Daily Scrum, Phase 3: Sprint Review, Retrospective. Match who is responsible for the following. Match: ScrumMaster: Problem resolution, Status and progress, Removing barriers between the Product Owner and Team; Product Owner: Single source of Story truth, Maintaining the Product Backlog, Interfacing between the Team and the customers and business; Team member: Creating and adjusting the Task Breakdown, Collaborating on the top Story. How long is a Scrum Sprint? Xchoice: 2-4 weeks, 5-9 weeks, 3 months, 1 week, As long as needed to complete the scope. If a project manager asks how a Scrum schedule comes together, which answer is correct? Xchoice: The Product Roadmap contains customer release cycles that contain 2-4 week Sprints, More Sprints are added to the schedule when the scope creep becomes unmanageable, Drive the budget and constrain the schedule until the budget runs out, Every Sprint must be a customer release, not just release-ready, 2-4 month stints have release cycles. Slide 90 Survey Questions How relevant is the course to your practice of project management, Agile and Scrum on a scale of 1 to 5? (Likert) Do you like the look and feel of the course? What could improve it? (Open text) Overall, how do you rate the course on a scale of 1 to 5? (Likert) Please add any comments you have about the course. (Open text) Did you need help from cPrime during the course? Please rate your experience on a scale of 1 to 5 or not applicable. If you have more questions, see the Questions & Answers slide to contact cPrime. (Likert) Did you need technical help from WebEx during the course? Please tell us what happened. (Open text) Slide 91 TDD/Notes only If for any reason you cannot access quizzes, tests and surveys, please contact WebEx Technical Support first. If this does not help, please contact the cPrime Training Center at [email protected], 877.7.Learn.0, 877.753.1760 or 650.931.1651, and we will help you or email the quizzes, test and survey to you.