Introduction to Scrum for Project Managers

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

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

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

Course Outline
Overview
Scrum Process
Scrum vs. Waterfall
Scrum Concepts
Scrum Summary
Test – Course
5

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

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

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

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

Course Outline
Overview
Scrum Process
Scrum vs. Waterfall
Scrum Concepts
Scrum Summary
Test – Course
10

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

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

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

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

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

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

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

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

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

Course Outline
Overview
Scrum Process
Scrum vs. Waterfall
Scrum Concepts
Scrum Summary
Test – Course
20

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

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

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

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

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

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

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

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

Course Outline
Overview
Scrum Process
Scrum vs. Waterfall
Scrum Concepts
Scrum Summary
Test – Course
29

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

Scrum vs. PM – PM’s Iron Triangle
Start Project
Schedule
Scope
Budget
Resources
31

Scope Increases
Schedule
Scope
Budget
Resources
32

Schedule Increases
Schedule
Scope
Budget
Resources
33

Schedule Increases
Schedule
cPrime
Scope
Budget
Resources
34

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

Scrum vs. PM – Scrum’s Iron Triangle
Start Scrum Project
Schedule
Scope
Budget
Resources
36

Scope Increases
Schedule
cPrime
Scope
Budget
Resources
37

Adjust Scope to
Keep Schedule
Schedule
Scope
Budget
Resources
38

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

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

Course Outline
Overview
Scrum Process
Scrum vs. Waterfall
Scrum Concepts
Scrum Summary
Test – Course
41

Scrum Concepts
Story
Sprints
Self-Organization
Shipped!
42

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

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

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

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

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

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

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

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

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

Course Outline
Overview
Scrum Process
Scrum vs. Waterfall
Scrum Concepts
Scrum Summary
Test – Course
52

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

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

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

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

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

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

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

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

Course Outline
Overview
Scrum Process
Scrum vs. Waterfall
Scrum Concepts
Scrum Summary
Test – Course
61

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It’s time for a fast quiz to check your learning!
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

Course Outline
Overview
Scrum Process
Scrum vs. Waterfall
Scrum Concepts
Scrum Summary
Test – Course
80

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

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

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

Test – Scrum for Project Managers
It’s time for the test to earn your certificate of completion and 1 PDU of course credit!
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

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

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

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.

http://blog.rainwebs.net	470
http://www.slideshare.net	109
http://www.agilecorner.com	91
http://www.filipegb.com.br	20
http://agilecorner.com	12
http://www.lmodules.com	7
http://clickwatchlearn.blogspot.com	3
http://www.techgig.com	2
url_unknown	1
http://rainwebs.net	1
http://www.slashdocs.com	1

Introduction to Scrum for Project Managers

by cPrime | Project Management | Agile | Consulting | Staffing | Training on Mar 30, 2010

Accessibility

Categories

Upload Details

Usage Rights

11 Embeds 717

Statistics

Introduction to Scrum for Project Managers Presentation Transcript