Introduction to Scrum for Project Managers

2. Course Description Title: Introduction to Scrum for Project Managers Audience: Project Managers and Team Leaders Course Units: 1 PDU (PMI) Course Award: Certificate of Completion Course Time: 1 hour and 15 minutes Updated: January 27, 2010 Prerequisites: None Resources:http://www.cPrime.com/about /scrum_faq.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.

3. Course Goals The purpose of the course is to provide a perspective on Scrum that makes sense to experienced Project Managers (PMs) and Team Leaders. 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.

4. Course Outline Overview Scrum Process Scrum vs. Waterfall Scrum vs. Normal Project Management Quiz 1 – Scrum Process Scrum Concepts Scrum Roles & Team Cadence Scrum Project Phases Quiz 2 – Scrum Projects Scrum Summary Test – Course 4 Copyright 2010 cPrime, Inc.

8. Learning how to do Scrum takes days.

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

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

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

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

17. Provide the wrong features at any time

20. Features are desired when requested.

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

29. Plenty of implementation can be done quickly.

30. Long lead times are usually not a major issue.

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

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

36. Roles – ScrumMaster, Product Owner, Team

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

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

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

48. Designs all features

49. Implements all features

50. Tests all features

52. Designs a Story

53. Implements a Story

54. Tests a Story

55. Fixes all bugs for the Story

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

67. We are much more likely to deliver on a commitment to schedule than on a commitment to scope.

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

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

77. Technical Story, or supporting non-functional requirement

80. Descriptive text

81. References to external documents and screen shots

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

111. Task Status – Pending, Started or Complete

112. Estimated Time to Complete

113. Actual Time to Complete

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

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

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

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

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

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

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

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

129. What did not work well

130. What changes we should make for next timeThe 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.

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

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

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

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

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

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

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

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

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

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

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

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

Introduction to Scrum for Project Managers

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Introduction to Scrum for Project Managers

Ähnlich wie Introduction to Scrum for Project Managers (20)

Mehr von cPrime | Project Management | Agile | Consulting | Staffing | Training

Mehr von cPrime | Project Management | Agile | Consulting | Staffing | Training (10)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Introduction to Scrum for Project Managers