+ All Categories
Home > Education > Introduction to Scrum for Project Managers

Introduction to Scrum for Project Managers

Date post: 19-Aug-2014
Category:
Upload: cprime-project-management-agile-consulting-staffing-training
View: 42,693 times
Download: 3 times
Share this document with a friend
Description:
Increase productivity and improve the predictability of software projects. Interest in the Scrum Agile process framework is exploding as companies discover that Scrum enables them to manage software projects with greater reliability and improve responsiveness to customers. This class introduces the skills that project managers and team leaders need to perform the basic steps of a Scrum process for software development. -Learn how Scrum practices relate to project management fundamentals -Learn the essentials of Scrum as a software development process -Learn the three Scrum roles, three Scrum meetings, and three Scrum artifacts -Project Managers and team leads learn basic planning, tracking, and management skills -Product Managers learn how to develop and prioritize requirements -Team members learn how to estimate and break down work
Popular Tags:
91
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.
Transcript
Page 1: Introduction to Scrum for Project Managers

Introduction to Scrum for Project Managers

cPrime, Inc.cPrime Training Center877.7.Learn.0 877.753.1760 [email protected]

Copyright 2010 cPrime, Inc.

Page 2: Introduction to Scrum for Project Managers

Course DescriptionTitle: Introduction to Scrum for Project ManagersAudience: Project Managers and Team LeadersCourse Units: 1 PDU (PMI)Course Award: Certificate of CompletionCourse Time: 1 hour and 15 minutesUpdated: January 27, 2010Prerequisites: NoneResources: http://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/ cPrime Training Center, [email protected], 877.7.Learn.0, 877.753.1760, 650.931.1651

Copyright 2010 cPrime, Inc. 2

Page 3: Introduction to Scrum for Project Managers

Course GoalsThe 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.

Page 4: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 4

Page 5: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 5

Page 6: Introduction to Scrum for Project Managers

OverviewScrum 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.

Page 7: Introduction to Scrum for Project Managers

Overview

Copyright 2010 cPrime, Inc. 7

Scrum arises from basic principles.– Define success.– Define failure. – Optimize the process for success.

Page 8: Introduction to Scrum for Project Managers

Overview – Scrum SummaryScrum 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.

Page 9: Introduction to Scrum for Project Managers

Overview – Agile Software DevelopmentIndividuals 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.

Page 10: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 10

Page 11: Introduction to Scrum for Project Managers

Scrum ProcessScrum 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.

Page 12: Introduction to Scrum for Project Managers

Scrum Process BenefitsAn 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.

Page 13: Introduction to Scrum for Project Managers

Scrum Process – Success and FailureSuccess– 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!

Page 14: Introduction to Scrum for Project Managers

Scrum Process – The Right TimeThe 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.

Page 15: Introduction to Scrum for Project Managers

Scrum Process – The Right TimeSome 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.

Page 16: Introduction to Scrum for Project Managers

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.

Page 17: Introduction to Scrum for Project Managers

Scrum Process – Achieve SuccessHow 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.

Page 18: Introduction to Scrum for Project Managers

Scrum Process – Approach the IdealScrum 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.

Page 19: Introduction to Scrum for Project Managers

Scrum Process – Who BenefitsBenefits 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.

Page 20: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 20

Page 21: Introduction to Scrum for Project Managers

Scrum vs. WaterfallHow 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

Page 22: Introduction to Scrum for Project Managers

Scrum vs. Waterfall – TimeboxesA 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.

Page 23: Introduction to Scrum for Project Managers

Scrum vs. Waterfall – Meetings & ActivitiesThe 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.

Page 24: Introduction to Scrum for Project Managers

Scrum vs. Waterfall – Meetings & ActivitiesRelease 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.

Page 25: Introduction to Scrum for Project Managers

Scrum vs. Waterfall – ScopeScrum 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

Page 26: Introduction to Scrum for Project Managers

Scrum vs. Waterfall – Adjust ScopeScrum 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

Page 27: Introduction to Scrum for Project Managers

Scrum vs. Waterfall – 1 Feature at a TimeScrum 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

Page 28: Introduction to Scrum for Project Managers

Scrum vs. Waterfall – Feature CompleteEach 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 SprintFeature 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.

Page 29: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 29

Page 30: Introduction to Scrum for Project Managers

Scrum vs. Normal Project ManagementCustomary 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.

Page 31: Introduction to Scrum for Project Managers

Scrum vs. PM – PM’s Iron Triangle

Start Project

Scope

Resources

Schedule

Budget

Copyright 2010 cPrime, Inc. 31

Page 32: Introduction to Scrum for Project Managers

Scrum vs. PM – PM’s Iron Triangle

Scope Increases

Resources

Schedule

Budget

Scope

Copyright 2010 cPrime, Inc. 32

Page 33: Introduction to Scrum for Project Managers

Scrum vs. PM – PM’s Iron Triangle

Schedule Increases

Resources

Schedule

Budget

Scope

Copyright 2010 cPrime, Inc. 33

Page 34: Introduction to Scrum for Project Managers

Scrum vs. PM – PM’s Iron Triangle

Schedule Increases

Resources

Schedule

Budget

cPrimeScope

Copyright 2010 cPrime, Inc. 34

Page 35: Introduction to Scrum for Project Managers

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.

Page 36: Introduction to Scrum for Project Managers

Scrum vs. PM – Scrum’s Iron Triangle

Start Scrum Project

Resources

Schedule

Budget

Scope

Copyright 2010 cPrime, Inc. 36

Page 37: Introduction to Scrum for Project Managers

Scrum vs. PM – Scrum’s Iron Triangle

Scope Increases

Resources

Schedule

Budget

cPrimeScope

Copyright 2010 cPrime, Inc. 37

Page 38: Introduction to Scrum for Project Managers

Scrum vs. PM – Scrum’s Iron Triangle

Adjust Scope to Keep Schedule

Resources

Schedule

Budget

Scope

Copyright 2010 cPrime, Inc. 38

Page 39: Introduction to Scrum for Project Managers

Scrum vs. PM – Product ManagementScrum 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.

Page 40: Introduction to Scrum for Project Managers

Quiz 1 – Scrum ProcessIt’s 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.

Page 41: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 41

Page 42: Introduction to Scrum for Project Managers

Scrum ConceptsStorySprintsSelf-OrganizationShipped!

Copyright 2010 cPrime, Inc. 42

Page 43: Introduction to Scrum for Project Managers

Scrum Concepts – StoryThe 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.

Page 44: Introduction to Scrum for Project Managers

Scrum Concepts – User StoryA 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

Page 45: Introduction to Scrum for Project Managers

Scrum Concepts – Technical StoryA 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

Page 46: Introduction to Scrum for Project Managers

Scrum Concepts – DefectA 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

Page 47: Introduction to Scrum for Project Managers

Scrum Concepts – SprintProject 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 starts—no change requests allowed!

Page 48: Introduction to Scrum for Project Managers

Scrum Concepts – SprintTeam 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.

Page 49: Introduction to Scrum for Project Managers

Scrum Concepts – Self-OrganizeTeams 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.

Page 50: Introduction to Scrum for Project Managers

Scrum Concepts – Self-OrganizeThe 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.

Page 51: Introduction to Scrum for Project Managers

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.

Page 52: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 52

Page 53: Introduction to Scrum for Project Managers

Scrum RolesThe 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

Page 54: Introduction to Scrum for Project Managers

Scrum Roles – ScrumMasterThe 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.

Page 55: Introduction to Scrum for Project Managers

Scrum Roles – ScrumMasterThe ScrumMaster’s 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

Page 56: Introduction to Scrum for Project Managers

Scrum Roles – Product OwnerThe 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

Page 57: Introduction to Scrum for Project Managers

Scrum Roles – Product OwnerThe 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.

Page 58: Introduction to Scrum for Project Managers

Scrum Roles – TeamThe 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.

Page 59: Introduction to Scrum for Project Managers

Scrum CadenceA 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.

Page 60: Introduction to Scrum for Project Managers

Scrum Cadence – Development Team A Development Team Cadence repeats every 2-4 weeks.

Copyright 2010 cPrime, Inc. 60

Page 61: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 61

Page 62: Introduction to Scrum for Project Managers

Scrum Phases – PM RenamedA 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.

Page 63: Introduction to Scrum for Project Managers

Phase 1 – Define Backlog & Plan SprintProject 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 Sprint’s 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.

Page 64: Introduction to Scrum for Project Managers

Phase 1 – Sprint BacklogProject 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 Owner’s 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.

Page 65: Introduction to Scrum for Project Managers

Phase 1 – Sprint BacklogThe 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.

Page 66: Introduction to Scrum for Project Managers

Phase 1 – Sprint Planning MeetingProject Managers say “Productivity”. ScrumMasters say “Velocity”. Velocity is the metric for a Team’s 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.

Page 67: Introduction to Scrum for Project Managers

Phase 1 – Sprint Planning MeetingThe 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.

Page 68: Introduction to Scrum for Project Managers

Phase 1 – Task BreakdownProject 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

Page 69: Introduction to Scrum for Project Managers

Phase 2 – Develop & TestProject 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.

Page 70: Introduction to Scrum for Project Managers

Phase 2 – Stickies, Scrums & BurndownProject 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.

Page 71: Introduction to Scrum for Project Managers

Phase 2 – Daily ScrumsAn 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.

Page 72: Introduction to Scrum for Project Managers

Phase 2 – Daily ScrumsThe 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.

Page 73: Introduction to Scrum for Project Managers

Phase 2 – Burndown ChartProject 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

Page 74: Introduction to Scrum for Project Managers

Phase 2 – Burndown ChartAt 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.

Page 75: Introduction to Scrum for Project Managers

Phase 2 – Burndown ChartThe 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.

Page 76: Introduction to Scrum for Project Managers

Phase 3 – Demo, Release & RetrospectiveProject 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.

Page 77: Introduction to Scrum for Project Managers

Phase 3 – Sprint Review MeetingThe 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.

Page 78: Introduction to Scrum for Project Managers

Phase 3 – Sprint Retrospective MeetingThe Sprint’s 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

Page 79: Introduction to Scrum for Project Managers

Quiz 2 – Scrum ProjectsIt’s 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.

Page 80: Introduction to Scrum for Project Managers

Course OutlineOverviewScrum ProcessScrum vs. WaterfallScrum vs. Normal Project ManagementQuiz 1 – Scrum ProcessScrum ConceptsScrum Roles & Team CadenceScrum Project PhasesQuiz 2 – Scrum ProjectsScrum SummaryTest – Course

Copyright 2010 cPrime, Inc. 80

Page 81: Introduction to Scrum for Project Managers

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

Page 82: Introduction to Scrum for Project Managers

Scrum ReferencesScrum and XP from the Trenches: How we do Scrum by Henrik KnibergAgile Project Management with Scrum by Ken SchwaberAgile Project Management by Jim HighsmithAgile Estimating and Planning by Mike CohnUser Stories Applied by Mike CohnLean Software Development by Mary and Tom PoppendieckAgile Software Development by Robert MartinAgile Testing by Lisa Crispin and Janet GregoryPractices of an Agile Developer by Venkat Subramaniam and Andy HuntCollaboration Explained by Jean TabakaThe Software Project Manager's Bridge to Agility by Michele Sliger and Stacia Broderick

Copyright 2010 cPrime, Inc. 82

Page 83: Introduction to Scrum for Project Managers

Questions & AnswersResources: FAQ http://www.cPrime.com/about /scrum_faq.html Course List http://www.cPrime.com/Training/courses.html Articles http://www.cprime.com/knowledge/articles.html References http://www.cprime.com/knowledge/resources.html

Instructors: Instructor Questions & Answers http://www.cprime.com/forums/ cPrime Training Center, [email protected], 877.7.Learn.0, 877.753.1760, 650.931.1651

Copyright 2010 cPrime, Inc. 83

Page 84: Introduction to Scrum for Project Managers

Test – Scrum for Project ManagersIt’s 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.

Page 85: Introduction to Scrum for Project Managers

Course SurveyCongratulations! 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 cPrime’s Course List: http://www.cPrime.com/Training/courses.html

Copyright 2010 cPrime, Inc. 85

Page 86: Introduction to Scrum for Project Managers

Claim Your 1 PDU with PMICongratulations!Register your completion of the cPrime course Introduction to Scrum for Project Managers with the Project Management Institute at: https://www.pmi.org/CCRS/

Copyright 2010 cPrime, Inc. 86

Page 87: Introduction to Scrum for Project Managers

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

Page 88: Introduction to Scrum for Project Managers

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 isn’t 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.

Page 89: Introduction to Scrum for Project Managers

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 isn’t 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.

Page 90: Introduction to Scrum for Project Managers

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)

Page 91: Introduction to Scrum for Project Managers

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.


Recommended