Introduction to Scrum for Project Managers
Upcoming SlideShare
Loading in...5
×
 

Introduction to Scrum for Project Managers

on

  • 44,175 views

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

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

Statistics

Views

Total Views
44,175
Views on SlideShare
43,246
Embed Views
929

Actions

Likes
55
Downloads
2,898
Comments
0

20 Embeds 929

http://blog.rainwebs.net 617
http://www.slideshare.net 109
http://www.agilecorner.com 91
http://rainwebs.net 36
http://www.filipegb.com.br 20
http://agilecorner.com 12
http://www.lmodules.com 7
https://twitter.com 7
https://madspace.pleio.nl 7
http://www.techgig.com 4
http://www.linkedin.com 4
http://translate.googleusercontent.com 3
http://clickwatchlearn.blogspot.com 3
https://www.linkedin.com 2
http://searchutil01 2
https://m.facebook.com&_=1371851909973 HTTP 1
https://m.facebook.com&_=1371652994174 HTTP 1
https://m.facebook.com&_=1371618937415 HTTP 1
url_unknown 1
http://www.slashdocs.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Introduction to Scrum for Project Managers Introduction to Scrum for Project Managers Presentation Transcript

  • 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 cPrime, Inc.
  • 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.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, learn@cPrime.com, 877.7.Learn.0, 877.753.1760, 650.931.1651
    2
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    3
    Copyright 2010 cPrime, Inc.
  • 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
    4
    Copyright 2010 cPrime, Inc.
  • 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
    5
    Copyright 2010 cPrime, Inc.
  • Overview
    Scrum makes sense to trained Project Managers and Team Leaders.
    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.
    6
    Copyright 2010 cPrime, Inc.
  • Overview
    Scrum arises from basic principles.
    Define success.
    Define failure.
    Optimize the process for success.
    7
    Copyright 2010 cPrime, Inc.
  • 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
    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.
    8
    Copyright 2010 cPrime, Inc.
  • Overview – Agile Software Development
    Individuals and interactions are more essential, productive and important than processes and tools.
    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.
    9
    Copyright 2010 cPrime, Inc.
  • 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
    10
    Copyright 2010 cPrime, Inc.
  • Scrum Process
    Scrum is a Lightweight Process Framework for Agile Software Development.
    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.
    11
    Copyright 2010 cPrime, Inc.
  • 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
    As a result, Scrum projects achieve higher customer satisfaction rates.
    12
    Copyright 2010 cPrime, Inc.
  • 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!
    Failure
    • Provide the right features at the wrong time
    • Provide the wrong features at any time
    • Many software failures mean company failure!
    13
    Copyright 2010 cPrime, Inc.
  • Scrum Process – The Right Time
    The customer determines the right time.
    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.
    14
    Copyright 2010 cPrime, Inc.
  • 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.
    Project Managers must meet customer and project needs.
    15
    Copyright 2010 cPrime, Inc.
  • Scrum Process – What is Success?
    How is project success related to the schedule of feature delivery? Success depends on feature delivery NOW.
    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.
    16
    Copyright 2010 cPrime, Inc.
  • Scrum Process – Achieve Success
    How can we approximate the ideal of success in the real world? We develop a few features quickly!
    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.
    17
    Copyright 2010 cPrime, Inc.
  • Scrum Process – Approach the Ideal
    Scrum is a project management framework designed to address rapidly-changing customer needs.
    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.
    18
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    19
    Copyright 2010 cPrime, Inc.
  • 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
    20
    Copyright 2010 cPrime, Inc.
  • 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
    Scrum Characteristics
    • Meetings – Sprint Planning Meeting, Daily Scrum, Retrospective Meeting
    • Roles – ScrumMaster, Product Owner, Team
    • Artifacts – Sprint Backlog, Product Backlog, Burndown Chart
    21
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    22
    Copyright 2010 cPrime, Inc.
  • Scrum vs. Waterfall – Meetings & Activities
    The diagram shows how the different meetings and activities relate to each other.
    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.
    23
    Copyright 2010 cPrime, Inc.
  • Scrum vs. Waterfall – Meetings & Activities
    Release planning and Sprint planning occur next, with the Sprint Planning Meeting to kick off the Sprint.
    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.
    24
    Copyright 2010 cPrime, Inc.
  • Scrum vs. Waterfall – Scope
    Scrum optimizes the balance of schedule and scope, unlike Waterfall project management.
    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
    25
    Copyright 2010 cPrime, Inc.
  • Scrum vs. Waterfall – Adjust Scope
    Scrum adjusts the scope, not the schedule. Know what to freeze (the schedule) and what to adjust (the scope).
    Waterfall schedulesdisappoint 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
    26
    Copyright 2010 cPrime, Inc.
  • Scrum vs. Waterfall – 1 Feature at a Time
    Scrum produces one feature at a time during a Sprint.
    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
    27
    Copyright 2010 cPrime, Inc.
  • Scrum vs. Waterfall – Feature Complete
    Each Story in a Scrum Sprint feels complete.
    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.
    28
    Copyright 2010 cPrime, Inc.
  • 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
    29
    Copyright 2010 cPrime, Inc.
  • Scrum vs. Normal Project Management
    Customary practices are “normal” PM
    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.
    30
    Copyright 2010 cPrime, Inc.
  • Scrum vs. PM – PM’s Iron Triangle
    Start Project
    Schedule
    Scope
    Budget
    Resources
    31
    Copyright 2010 cPrime, Inc.
  • Scrum vs. PM – PM’s Iron Triangle
    Scope Increases
    Schedule
    Scope
    Budget
    Resources
    32
    Copyright 2010 cPrime, Inc.
  • Scrum vs. PM – PM’s Iron Triangle
    Schedule Increases
    Schedule
    Scope
    Budget
    Resources
    33
    Copyright 2010 cPrime, Inc.
  • Scrum vs. PM – PM’s Iron Triangle
    Schedule Increases
    Schedule
    cPrime
    Scope
    Budget
    Resources
    34
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    35
    Copyright 2010 cPrime, Inc.
  • Scrum vs. PM – Scrum’s Iron Triangle
    Start Scrum Project
    Schedule
    Scope
    Budget
    Resources
    36
    Copyright 2010 cPrime, Inc.
  • Scrum vs. PM – Scrum’s Iron Triangle
    Scope Increases
    Schedule
    cPrime
    Scope
    Budget
    Resources
    37
    Copyright 2010 cPrime, Inc.
  • Scrum vs. PM – Scrum’s Iron Triangle
    Adjust Scope to
    Keep Schedule
    Schedule
    Scope
    Budget
    Resources
    38
    Copyright 2010 cPrime, Inc.
  • Scrum vs. PM – Product Management
    Scrum is different from traditional ProDUCT Management.
    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.
    39
    Copyright 2010 cPrime, Inc.
  • Quiz 1 – Scrum Process
    It’s time for a fast quiz to check your learning!
    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.
    40
    Copyright 2010 cPrime, Inc.
  • 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
    41
    Copyright 2010 cPrime, Inc.
  • Scrum Concepts
    Story
    Sprints
    Self-Organization
    Shipped!
    42
    Copyright 2010 cPrime, Inc.
  • 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.
    There are three types of Stories:
    • User Story, or user-facing functional requirement
    • Technical Story, or supporting non-functional requirement
    • Defect, or bug report
    Solid Stories give enough detail to estimate the Task Breakdown and the Velocity of the Sprint.
    Stories use a common format for easy reading.
    43
    Copyright 2010 cPrime, Inc.
  • 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.
    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
    44
    Copyright 2010 cPrime, Inc.
  • Scrum Concepts – Technical Story
    A Technical Story is a non-functional requirement that describes the functionality supporting the user-facing features in User Stories.
    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
    45
    Copyright 2010 cPrime, Inc.
  • 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.
    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
    46
    Copyright 2010 cPrime, Inc.
  • Scrum Concepts – Sprint
    Project Managers say “Schedule”. ScrumMasters say “Sprint”!
    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!
    47
    Copyright 2010 cPrime, Inc.
  • Scrum Concepts – Sprint
    Team Members
    Collaborate and “self-organize”
    Track their progress and update tasks when finished
    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.
    48
    Copyright 2010 cPrime, Inc.
  • Scrum Concepts – Self-Organize
    Teams self-organize to best apply member skill sets – coding, test development, testing.
    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.
    49
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    50
    Copyright 2010 cPrime, Inc.
  • Scrum Concepts – Shipped!
    At the end of a Sprint, completed Stories are Shipped. Incomplete Stories are not.
    No exceptions! The schedule is not extended to complete work.
    51
    Copyright 2010 cPrime, Inc.
  • 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
    52
    Copyright 2010 cPrime, Inc.
  • 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
    53
    Copyright 2010 cPrime, Inc.
  • 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
    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.
    54
    Copyright 2010 cPrime, Inc.
  • Scrum Roles – ScrumMaster
    The 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
    55
    Copyright 2010 cPrime, Inc.
  • 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.
    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
    56
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    57
    Copyright 2010 cPrime, Inc.
  • 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
    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.
    58
    Copyright 2010 cPrime, Inc.
  • Scrum Cadence
    A Scrum schedule, or Sprint, is really a Cadence, a repeating sequence of meetings, activities, milestones and events.
    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.
    59
    Copyright 2010 cPrime, Inc.
  • Scrum Cadence – Development Team
    A Development Team Cadence repeats every 2-4 weeks.
    60
    Copyright 2010 cPrime, Inc.
  • 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
    61
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    62
    Copyright 2010 cPrime, Inc.
  • Phase 1 – Define Backlog & Plan Sprint
    Project Managers say “Plan”. Scrum Masters say “Define the Backlog and Plan the Sprint”.
    Planning maps to defining the Product Backlog and planning the next Sprint.
    Begin with the previous Sprint’s Retrospective Meeting, a familiar Best Practice in project management.
    Review and revise the Product Backlog and rank the Stories going into the next Sprint. The Product Owner and Team write any new Storiesfor the Sprint. Determine the Definition of Done for the top Stories.
    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.
    63
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    64
    Copyright 2010 cPrime, Inc.
  • Phase 1 – Sprint Backlog
    The chart shows a typical Sprint Backlog of Stories for implementation.
    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.
    65
    Copyright 2010 cPrime, Inc.
  • Phase 1 – Sprint Planning Meeting
    Project Managers say “Productivity”. ScrumMasters say “Velocity”. Velocity is the metric for a Team’s ability to get work done in a Sprint.
    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.
    66
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    67
    Copyright 2010 cPrime, Inc.
  • 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.
    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
    68
    Copyright 2010 cPrime, Inc.
  • Phase 2 – Develop & Test
    Project Managers say “Execute”. Scrum Masters say “Develop and Test”.
    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.
    69
    Copyright 2010 cPrime, Inc.
  • Phase 2 – Stickies, Scrums & Burndown
    Project Managers say “Monitor and Control”. Scrum Masters say “Move the Stickies and Have Daily Scrums”.
    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.
    70
    Copyright 2010 cPrime, Inc.
  • 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
    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.
    71
    Copyright 2010 cPrime, Inc.
  • 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
    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.
    72
    Copyright 2010 cPrime, Inc.
  • 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.
    73
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    74
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    75
    Copyright 2010 cPrime, Inc.
  • Phase 3 – Demo, Release & Retrospective
    Project Managers say “Close”. ScrumMasters say “Demo, Release and Have the Retrospective Meeting”.
    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.
    76
    Copyright 2010 cPrime, Inc.
  • 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.
    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.
    77
    Copyright 2010 cPrime, Inc.
  • Phase 3 – Sprint Retrospective Meeting
    The 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.
    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:
    • What worked well and what we should do again
    • What did not work well
    • What changes we should make for next time
    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.
    78
    Copyright 2010 cPrime, Inc.
  • Quiz 2 – Scrum Projects
    It’s time for a fast quiz to check your learning!
    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.
    79
    Copyright 2010 cPrime, Inc.
  • 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
    80
    Copyright 2010 cPrime, Inc.
  • Scrum Summary
    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
    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.
    81
    Copyright 2010 cPrime, Inc.
  • Scrum References
    Scrum and XP from the Trenches: How we do Scrum by HenrikKniberg
    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 VenkatSubramaniam and Andy Hunt
    Collaboration Explained by Jean Tabaka
    The Software Project Manager's Bridge to Agility by Michele Sliger and Stacia Broderick
    82
    Copyright 2010 cPrime, Inc.
  • Questions & Answers
    Resources:
    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, learn@cPrime.com, 877.7.Learn.0, 877.753.1760, 650.931.1651
    83
    Copyright 2010 cPrime, Inc.
  • Test – Scrum for Project Managers
    It’s time for the test to earn your certificate of completion and 1 PDU of course credit!
    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.
    84
    Copyright 2010 cPrime, Inc.
  • 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 cPrime’s Course List: http://www.cPrime.com/Training/courses.html
    85
    Copyright 2010 cPrime, Inc.
  • 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/
    86
    Copyright 2010 cPrime, Inc.
  • 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
  • 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.
  • 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.
  • 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)
  • 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 learn@cPrime.com, 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.