Are you sure you want to cancel your subscription?

If you cancel, your subscription will remain active through the paid term. You will be able to reactivate the subscription until that date.

Sorry to see you go

Your subscription will remain active until . If you change your mind, you may rectivate your subscription anytime before that date.

Are you sure you want to reactivate?
Welcome Back!

Your subscription has been reactivated and you will continue to be charged on .

Reactivate Subscription

Thank you for choosing to reactivate your subscription. In order to lock in your previous subscription rate, you owe: .

Your Subscription term is from - .

Questions? Call Sales.

Payment Due:

Auto-Renew Subscription

To auto-renew your subscription you need to select or enter your payment method in "Your Account" under Manage Payments.

Click continue to set up your payments.

CBT Nuggets License Agreement

Unless otherwise stated all references to “training videos” or to “videos” includes both individual videos within a series, entire series, series packages, and streaming subscription access to CBT Nuggets content. All references to CBT or CBT Nuggets shall mean CBT Nuggets LLC, a Delaware limited liability company located at 44 Country Club Road, Ste. 150, Eugene, Oregon.

A CBT Nuggets license is defined as a single user license. Accounts may purchase multiple users, and each user is assigned a single license.

  • GRANT OF LICENSE. CBT Nuggets grants you a non-transferable, non-exclusive license to use the training videos contained in this package or streaming subscription access to CBT content (the “Products”), solely for internal use by your business or for your own personal use. You may not copy, reproduce, reverse engineer, translate, port, modify or make derivative works of the Products without the express consent of CBT. You may not rent, disclose, publish, sell, assign, lease, sublicense, market, or transfer the Products or use them in any manner not expressly authorized by this Agreement without the express consent of CBT. You shall not derive or attempt to derive the source code, source files or structure of all or any portion of the Products by reverse engineering, disassembly, decompilation or any other means. You do not receive any, and CBT Nuggets retains all, ownership rights in the Products. The Products are copyrighted and may not be copied, distributed or reproduced in any form, in whole or in part even if modified or merged with other Products. You shall not alter or remove any copyright notice or proprietary legend contained in or on the Products.
  • TERMINATION OF LICENSE. Once any applicable subscription period has concluded, the license granted by this Agreement shall immediately terminate and you shall have no further right to access, review or use in any manner any CBT Nuggets content. CBT reserves the right to terminate your subscription if, at its sole discretion, CBT believes you are in violation of this Agreement. CBT reserves the right to terminate your subscription if, at its sole discretion, CBT believes you have exceeded reasonable usage. In these events no refund will be made of any amounts previously paid to CBT.
  • DISCLAIMER OF WARRANTY AND LIABILITY. The products are provided to you on an “as is” and “with all faults” basis. You assume the entire risk of loss in using the products. The products are complex and may contain some nonconformities, defects or errors. CBT Nuggets does not warrant that the products will meet your needs, “expectations or intended use,” that operations of the products will be error-free or uninterrupted, or that all nonconformities can or will be corrected. CBT Nuggets makes and user receives no warranty, whether express or implied, and all warranties of merchantability, title, and fitness for any particular purpose are expressly excluded. In no event shall CBT Nuggets be liable to you or any third party for any damages, claim or loss incurred (including, without limitation, compensatory, incidental, indirect, special, consequential or exemplary damages, lost profits, lost sales or business, expenditures, investments, or commitments in connection with any business, loss of any goodwill, or damages resulting from lost data or inability to use data) irrespective of whether CBT Nuggets has been informed of, knew of, or should have known of the likelihood of such damages. This limitation applies to all causes of action in the aggregate including without limitation breach of contract, breach of warranty, negligence, strict liability, misrepresentation, and other torts. In no event shall CBT Nuggets’ liability to you or any third party exceed $100.00.
  • REMEDIES. In the event of any breach of the terms of the Agreement CBT reserves the right to seek and recover damages for such breach, including but not limited to damages for copyright infringement and for unauthorized use of CBT content. CBT also reserves the right to seek and obtain injunctive relief in addition to all other remedies at law or in equity.
  • MISCELLANEOUS. This is the exclusive Agreement between CBT Nuggets and you regarding its subject matter. You may not assign any part of this Agreement without CBT Nuggets’ prior written consent. This Agreement shall be governed by the laws of the State of Oregon and venue of any legal proceeding shall be in Lane County, Oregon. In any proceeding to enforce or interpret this Agreement, the prevailing party shall be entitled to recover from the losing party reasonable attorney fees, costs and expenses incurred by the prevailing party before and at any trial, arbitration, bankruptcy or other proceeding and in any appeal or review. You shall pay any sales tax, use tax, excise, duty or any other form of tax relating to the Products or transactions. If any provision of this Agreement is declared invalid or unenforceable, the remaining provisions of this Agreement shall remain in effect. Any notice to CBT under this Agreement shall be delivered by U.S. certified mail, return receipt requested, or by overnight courier to CBT Nuggets at the following address: 44 Club Rd Suite 150, Eugene, OR 97401 or such other address as CBT may designate.

CBT Nuggets reserves the right, in its sole discretion, to change, modify, add, or remove all or part of the License Agreement at any time, with or without notice.

Billing Agreement

  • By entering into a Billing Agreement with CBT Nuggets, you authorize CBT Nuggets to use automatic billing and to charge your credit card on a recurring basis.
  • You agree to pay subscription charges on a monthly basis, under the following terms and conditions:
    • CBT Nuggets will periodically charge your credit card each monthly billing cycle as your subscription charges become due;
    • All payments are non-refundable and charges made to the credit card under this agreement will constitute in effect a "sales receipt" and confirmation that services were rendered and received;
    • To terminate the recurring billing process and/or arrange for an alternative method of payment, you must notify CBT Nuggets at least 24 hours prior to the end of the monthly billing cycle;
    • You will not dispute CBT Nugget’s recurring billing charges with your credit card issuer so long as the amount in question was for periods prior to the receipt and acknowledgement of a written request to cancel your account or cancel individual licenses on your account.
  • You guarantee and warrant that you are the legal cardholder for the credit card associated with the account, and that you are legally authorized to enter into this recurring billing agreement.
  • You agree to indemnify, defend and hold CBT Nuggets harmless, against any liability pursuant to this authorization.
  • You agree that CBT Nuggets is not obligated to verify or confirm the amount for the purpose of processing these types of payments. You acknowledge and agree that Recurring Payments may be variable and scheduled to occur at certain times.
  • If your payment requires a currency conversion by us, the amount of the currency conversion fee will be determined at the time of your payment. You acknowledge that the exchange rate determined at the time of each payment transaction will differ and you agree to the future execution of payments being based on fluctuating exchange rates.

CBT Nuggets reserves the right, in its sole discretion, to change, modify, add, or remove all or part of the Billing Agreement at any time, with or without notice.

Scrum Certification

Preparation for Scrum Master, Product Owner, and Scrum Team Certification

Course Duration: 15:18:45
Introduction to Scrum
This Nugget provides an overview of Scrum. This overview includes a description of Scrum Roles like Scrum Master, Product Owner and the Scrum team. An introduction is also given of some of the key Scrum activities, (known as Scrum Rituals) such as the Daily Scrum, Scrum Planning Meetings. It also defines Scrum management tools like Scrum Burn Down Chart, Velocity and User Stories.
Scrum versus Traditional Development
This Nugget provides an overview of Agile Scrum by doing a specific comparison between Scrum and traditional development approaches. At the most basic level, Scrum development is no different than traditional development as analysis, design, development, testing, documentation and implementation take place independent of the approach. However, this is also a very significant difference in approaches, as Scrum does many iterations of analysis through development incrementally developing the final product while traditional approaches do each activity once with a single implementation. The Scrum iterative approach provides a much more flexible approach as the objectives are adjusted with each iteration. The principles of Scrum are further reviewed by reviewing the Agile Manifesto and the 12 Principles of Agile development developed by the Agile Alliance in February of 2001.
Scrum Roles
This Scrum Master training video will review all the roles associated with a Scrum Project: Scrum Master, Product Owner, Scrum Team, Subject Matter Experts, business owner and the rest of the organization. While Scrum is a lightweight approach to project delivery, there are a number of key roles that must be in place to ensure that Scrum principles are applied. This Nugget reviews how the two key roles, the Scrum Master and the Product Owner, provide the guidance that the project needs. The Scrum Master is a facilitator and coach responsible for ensuring that Scrum principles are applied. The Scrum Master has no direct managerial authority on the project. The Product Owner, by contrast, is 100% responsible for the definition of and acceptance that the project satisfies the business requirements. The final member of the Scrum is the project team, a self-organizing, self-managing group collectively responsible for delivering the project results. The remaining three roles (Subject Matter Experts, business owner and rest of the organization), are reviewed as to their interaction with the project.
Scrum Meetings
Scrum Meetings, often called Scrum Rituals, are the core of Scrum. This Nugget reviews the activities to be completed in the four Scrum meetings: Daily Scrum, Planning Meeting, Sprint Review and Sprint Retrospective. The Daily Scrum, most likely the most recognized of the Scrum Rituals, is a brief, 15-minute meeting to review the results of yesterday’s work, plans for the current day, and problems, issues and warnings. In this Nugget we will review the basic rules for running an effective Daily Scrum where attendance is mandatory for all team members, side-bar conversations are avoided and consistency in time and place are critical. Next, this Nugget reviews Sprint Planning Meetings. While the pure definition of Scrum addresses only the Sprint Planning Meeting, this Nugget also reviews the purpose of two prerequisite meetings, the Product Planning and Release Planning Meetings. The Nugget concludes with a review of the two meetings that take place at the end of each Sprint. The Sprint Review meeting presents and confirms the results of the work done in the Sprint and Sprint Retrospective provides time for review of successes and challenges with a focus on process improvements.
Scrum Artifacts
This Agile Scrum Master Nugget reviews the four Artifacts, or deliverables, associated with Scrum delivery. These are the User Story, Product Backlog, Sprint Backlog and Progress Charts. Unlike traditional development approaches where software tools are required to develop and maintain project deliverables, Sprint focuses on non-software based artifacts. User stores are created, by hand, on standard index cards, and the Product Backlog and Sprint Backlogs are nothing more than cork boards where the User Stories are moved through the planning process by pinning them to the appropriate backlog and moving the stories as the plans are evolved. The key reason for this low-tech approach is based on simplicity and visibility. Keeping this theme of simplicity and visibility, the Nugget concludes with a review of the approaches for creating Progress Charts, such as Burn Down and Burn Up Charts, as re-usable laminated graphs which are posted in the team workspace.
Scrum Master
This Nugget drills into the roles and responsibilities of the Scrum Master and the process to be followed to become certified in Scrum, including Certified Scrum Master. There is an overview of six different Scrum certifications from the Agile Alliance, discussing the differences between the basic, practioner and consultant Scrum certifications. Additional details on the personal characteristics and attributes of a Scrum Master are reviewed and the roles and responsibilities of a Scrum Master are examined in detail in this Nugget.
Product Vision and Product Backlog
This Nugget focuses on the most important artifact in Scrum, the Product Backlog. But first, the Nugget discusses a prerequisite to the Product Backlog, the Product Vision. The Product Vision, a pre-Scrum document, is developed by the business owner and the Product Owner and defines the business objectives of the project. The Nugget reviews the relationship the Product Vision has on Scrum as it provides the overall guiding direction to the Scrum Team's daily actions, ensuring that the work is directly related to achieving the Product Vision. This Nugget then expands on the definition of the Product Backlog from earlier Nuggets. Key features of the Product Backlog reviewed are the evolutionary and dynamic characteristics of the Product Backlog. A key Scrum principle is that the Product Backlog changes, often daily, as the Product Owner evolves the definition of stores, adding stories and story detais, prioritizing and even removing stories no longer needed through a Scrum process called Grooming. Another key concept of the Product Backlog discussed in this Nugget is that it contains not only Business Stories but also team- and technology-focused stories, ensuring that the Product Backlog truly represents every piece of work to be completed by the team.
What is done?
This Nugget covers an often overlooked, but key concept in Scrum – defining the criteria for validating that the work on a Story, a Sprint, a Release and the Product is done. This Nugget differentiates “what is done” from traditional acceptance criteria as it is much lighter weight than traditional acceptance. What is done is defined as an informal “OK, the work is fine." As there are many stories and many Sprints in a Scrum project, having a well-established definition of "done" is important to ensure these many “OKs” are easy to obtain. This Nugget reviews the processes for ensuring that the Scrum team gets an OK for each Story, Sprint, Release and Product.
Release and Sprint Planning
This Nugget provides an in-depth review of the two Scrum planning activities, Release and Sprint. The Release Plan process is reviewed, highlighting that Release Planning is an optional, but highly recommended Scrum activity to provide a high level 2-3 month target of the expected results of the Sprints to be completed in that timeframe, specifically the business functionality that should be ready to be implemented into the organization. The Nugget then focuses on Sprint Planning, outlining the activities to be completed in the two parts of the Sprint Planning process – Story Selection and Plan Confirmation. Story Selection reviews each story to ensure that there is enough detail to allow it to be completed in the Scrum. Once the stories are confirmed, the effort to complete the stories is reviewed to ensure that there is capacity in the Scrum to complete all selected work. With the stories for the Sprint confirmed, the Nugget then reviews the second part of the Sprint Planning process – confirmation of the plan. During this activity, specific plans are made for how the work will be assigned and completed in the Sprint. The Nugget concludes with a discussion on Story Points, which is a standardized measure of the effort to complete a Story; and on Velocity, which is the sustainable amount of work the team is able to complete during a Sprint, i.e. the number of story points that can be accomplished in the Sprint.
Scrum Estimating
This Nugget reviews the estimating process for Scrum development. The previously introduced Scrum Estimating basis, Story Points, is fully developed by defining what a Story Point is and how to develop realistic Story Point estimates. In its most basic form, a Story Point is an agreed upon standard amount of effort to develop a story of a known size. Often, a Story Point is based on the amount of effort to develop the most simple story on the Product Backlog, typically a simple menu. All other stories are then compared, on a relative basis, to determine the number of Story Points required to complete the story, i.e this story is three times more complex than the simplest story so it should take 3 Story Points of effort to complete. Velocity is then developed over time based on the actual number of story points the team is able to complete per Sprint. The Nugget concludes with a review of two Story Point estimating methods to help the team develop and agree on the number of Story Points per story.
A Sprint
This Nugget reviews one of the core elements of Scrum, the Sprint. A Sprint is the repeating process that develops the working software to satisfy the stories assigned to the Sprint. This Agile Scrum training reviews the guiding principles of a Sprint, and reintroduces the previously discussed Sprint Rituals and Artifacts, showing each of these in context to the Sprint activities. Finally, this Nugget discusses how a project determines the ideal length for a Sprint and closes with a discussion on how to deal with the inevitable – changes to the agreed upon Sprint plan.
Daily Scrum
This Nugget reviews the other common element of Scrum – the Daily Scrum. This Agile training will review the details of what a Daily Scrum is, what the Daily Scrum isn’t, and most importantly, what happens as a result of the Daily Scrum. The Daily Scrum is a brief, 15-minute maximum daily team meeting where everyone reviews what they did since the last Scrum, what they plan to do before the next Scrum and any issues and impediments that are having. The key to running a successful Daily Scrum is to ensure detailed discussions are deferred until after the Scrum. This keeps the Scrum brief and focused, yet identifies all the followup discussions needed to complete the stories in the Sprint. These follow-up meetings are the most important product of the Daily Scrum as it ensures that all team members are aware of each other’s work and when and where additional discussions are needed to keep the work on track.
Tracking Progress
This Nugget re-presents the Scrum Artifacts for tracking progress in Scrum: Burn Down, Burn Up and Sprint Backlog. As well a new tracking process, the Done Chart is introduced to provide more granularity to daily progress tracking during a Sprint. The most widely known chart for Scrum progress tracking is the Burn Down (or Burn Up) chart. These charts track daily progress against the number of stories, number of story points and/or number of task points in the Sprint. The Nugget presents pros and cons of tracking progress by stories, story points, or task points based on the tradeoffs between effort to track progress versus value of the information. Similarly, pros and cons of a Burn Down versus Burn up chart are reviewed to guide the selection the charting method that provides the most value to the Sprint. Next, the Nugget reviews the Done Chart, which tracks progress on the “done tick boxes” for each story. The benefit of the Done Chart is that is an extremely low-cost progress tracking tool that focuses the team on completion work while at the same time providing a very high degree of granularity of the daily progress being made in the Sprint. Finally, the Nugget reviews how the Sprint Backlog and Done Board provide significant low-cost progress tracking for the Sprint.
Dealing with Changes
This Nugget reviews how and where Scrum supports change and where (at the Sprint) change is discouraged. In a nutshell, Scrum is designed to support change as all work is done in small, incremental sprints.Any changes not directly impacting the current Sprint are encouraged; in fact, that’s why we use Scrum, as any changes to the product, and release and backlog are encouraged. As the Product Owner and the business discover new stories, make changes to existing stories and/or remove stories, Scrum supports the change, ensuring that the ultimate code delivered is 100% in support of current business needs. The one point where change is discouraged is within a Sprint, where, while change is still possible, it is discouraged, as a sprint is relatively short and where possible the team prefers to maintain its momentum by completing the release as planned and then accommodating the change in the next Sprint. However, where changes to a Sprint are required, the Nugget reviews the process for making changes or cancelling a release.
The Product Owner
This Nugget focuses on the Product Owner’s role during a Sprint and the roles and relationships the Product Owner should have with the Team and the Scrum Master. The Product Owner’s role begins as the owner of both the Product and Sprint Backlogs, but specifically to this Nugget, the Product Owner is the absolute owner of the Sprint Backlog. No changes to the stories in the Sprint Backlog can be made without the absolute approval of the Product Owner. The Product Owner has total responsibility for ensuring that the Sprint delivers the business value. This Agile training reviews how this ownership begins with the Grooming process where the Product Owner either personally grooms the stories ensuring they are ready for the team or approves the grooming completed by the SMEs, giving the “OK” for each story during the Sprint Review.
Sprint Review and Retrospective
This Agile Scrum training is focused on closing each Sprint, specifically the Sprint Review and the Sprint Retrospective. The focus of this Nugget is efficiency in completing these rituals as it is critical that they are completed for each Sprint. A new ritual, the Introspective, is introduced to do on-demand retrospective to deal with issues immediately as identified. The Nugget presents a number of techniques and tips to ensure these rituals are completed efficiently and justification is provided to help defend the need for complete the review and retrospective on every Sprint to management.
Backlog Grooming
This training Nugget reviews the details of backlog/story grooming. To ensure that Grooming is done properly, the Nugget first presents the definition of what a well-groomed Story is, and what an over-groomed story looks like. The Scrum training Nugget then reviews story prioritization to ensure that only the right stories (those to be completed in the next few Sprints) are groomed. Story Time and/or Grooming parties are introduced as a typical method for Story Grooming, a scheduled activity where the Product Owner, SMEs and Team get together to groom the highest priority stories by adding more detail to the story definition and/or Definition of Done. The Nugget concludes with a discussion on Epic Grooming. Epics are groomed in the same way as stories, where highest priority epics are groomed when the stories to be derived are expected to be scheduled into a Sprint in the near future. Epics are presented as key to successful backlog management as Epics help keep the backlog manageable, as it is far easier to manage 10 future Epics than the potential 45 stories which would be derived from the Epics.
Writing User Stories
This Nugget reviews the details of how good User Stories are written. This training Nugget first does a review of what a good user story looks like and what an appropriate definition of done is. Procedures and expectations for writing good stories and appropriate definitions of done are presented and reviewed to ensure that they adhere to the characteristics of a good story. A good story is defined as one that: is self-sufficient, delivers business value, can be estimated and tested, is small and most importantly delivers minimal functionality. Recognizing that while most stories will define business requirements, there will be other stories required to complete analysis activities or explore alternate methods for addressing a need, the Nugget then reviews the different types of stories that are typically encountered in a Sprint. Examples of the various types of stories are presented to help the viewer better understand the differences in the different story types. Finally, Storyotypes are presented. A Storyotype is simply a sample, representative or template that the project can use to develop new stories more efficiently. The Nugget concludes with a review of what to do with the back of the story card. While it has already been discussed that the back of the card is a good place to support the “done tickboxes," the rest of the space on the back of the card should be used by the team member working on the story to record notes, clarifications and other information gathered during the conversation with the Product Owner to preserve this clarifying information for the life of the project.
Team and Business Dynamics
This Agile Scrum Nugget focuses on ensuring that the relationships between the Scrum Team and the Business that are necessary to ensure that Scrum is effective in the organization are well defined and understood. The Nugget’s first focus is on ensuring that an effective working relationship is in place with the organization in general, but specifically with the Subject Matter Experts (SMEs). The relationship with the SMEs is explored in depth to ensure that the SMEs are available to support the project and most importantly to ensure that the part-time involvement of the SMEs does not introduce any challenges due to their other priorities and responsibilities. Next, the Nugget discusses the challenges the Scrum Master often experiences working with the organization at large when trying to remove project roadblocks. The relationship between the traditional IT organization, specifically PMs, Architects, DBAs and BAs is then explored to better understand how these roles can be best integrated into a Scrum project. This training Nugget closes by presenting scenarios to deal with typical resistance to Scrum: Traditional development approaches are needed for some project and how compliance and certification can be accomplished with Scrum approaches.
Technology and Process Debt
This Nugget focuses on a number of Agile principles that are critical to ensure that the technology direction for the project is appropriate. Technology and Process Debt is re-introduced and discussed in detail as Technology Debt is inevitable in Scrum because of the core Scrum requirement to do just enough code. Each time a story does "just enough" the overall architecture and structure for the project may be compromised. Once enough compromise is done, technology debt is introduced into the project, where the code works, but needs to be improved. A team has to be committed to removing technology debt once it is recognized and the product owner has to be committed to ensuring that team stories to remove technology debt get planned into the Sprint backlog. The Nugget then goes on to review the issues with Architecture Definition and Database Design in Scrum projects - where the architecture and database design is done incrementally on a story-by-story basis, ensuring that just enough architecture and database design is completed. The concept of Sprint Zero is introduced as an optional "pre-startup" activity to ensure that the required infrastructure for the project is in place. The Nugget closes with a review of the concept of Refactoring - taking "bad" code and making it better. While the definition of Refactoring is very simple, the Nugget reviews the processes to be followed for Refactoring as it is critical to remove technology debt and to allow for continuous architecture and database definition.
Agile Development Techniques - 1
This Nugget is the first of 2 that introduces a number of Agile development techniques that are very applicable to Scrum work. The first technique reviewed is Test-driven Development. Test-driven Development is one of the most misunderstood Agile development techniques as it "does development backwards" by writing detailed test cases first to validate the story's requirements are satisfied, and then writing the code focused on ensuring each test case passes (as opposed to writing code that satisfies the story requirements). The Nugget presents the reasons why Test-driven Development is a very sound development approach for Scrum Development than can result in a 40-100% reduction on the number of defects. The next Agile development technique reviewed is Pair Programming. The Nugget reviews several approached to Pair Programming and presents compelling reasons why Pair Programming should be considered for at least some of the stories in each Sprint. Next, the Nugget reviews the Agile development technique for Refactoring. Refactoring is a critical Agile development technique that should be used on every Scrum project to ensure that the bad code that is created as a result of iterative, just in time development, is improved and remains resilient for future change. Refactoring is the one Scrum approach where "future focus" is important as bad code is often directly related to buggy code. With a continuous focus on quality, refactoring is critical for the removal of potential buggy code. The Nugget closes with a discussion on the concept of collective ownership. Collective ownership is based on the concept that no one owns a piece of code, the team owns all code. This is very important for Scrum development as each piece of code will be modified many times as new stories are developed. With collective ownership, any team member has to have the confidence of modifying any code as stories are completed. Without collective ownership, Sprints will quickly become bottle-necked waiting for a specific developer to have the availability to work on a story as they "own the code."
Agile Development Techniques - 2
This Nugget is the second of 2 that introduces a number of Agile development techniques that are very application to Scrum work. The first technique reviewed is Continuous Integration, required technology that is in place to support automated builds and testing with every code check in. The Nugget reviews a number of techniques for implementing Continuous Integration while continuing to support efficient development. Next, the Nugget reviews the Agile development techniques of Spikes. Spikes are deliberate exploration for the best/preferred way of accomplishing something within the Scrum project. Spikes give the Scrum project the confidence that incremental architecture and database design is workable, as Spikes give the team time to explore the best alternative to accomplish a required architectural or business requirement. Next, the Agile principle of Branching is introduced. A branch is very much like refactoring in that it takes complex code makes it better. The key difference between refactoring and branching is the "severity" of the issue - refactoring is focused on BAD code, while Branching will take perfectly acceptable, but complex, code and decompose the complex code into a number of smaller and simpler code packages. The Nugget closes with a review of a number of special stories required to deal with missed requirements and/or prepare the code for implementation.
Delivering Large Projects with Scrum
This Nugget is focused on defining how to scale Scrum, Scrum Rituals, Scrum Artifacts and Scrum Roles to support large projects with thousands of stories, and multiple Scrum teams. The Nugget also covers how to keep the multiple teams synchronized and aligned. The first aspect of scaling Scrum discussed is scaling the teams, which is as simple as having multiple Scrum teams, each team following the standard rules of Scrum. The only difference is that multiple teams are selecting stories from the Project Backlog, but each team develops its own Sprint Plan, conducts its own Scrum meetings and follows all Scrum principles. The next issue of scaling Scrum is scaling the Product Owner, which requires a lot more time and attention than scaling the teams. This Nugget presents concepts and suggestions on how a single Product Owner could support a number of Scrum teams through more aggressive use of Subject Matter Experts. The Nugget then goes on to discuss ways in which multiple Product Owners can be effective with well-defined Roles and Responsibilities. This Nugget then discusses that the Product Backlog doesn't scale - no matter how large the Scrum project gets, there has to be a single Product Backlog, as all Scrum teams have to work from a common Product Backlog to ensure that it represents the entirety of the business requirements. The Nugget reviews how Epics and Automated Scrum tools can be used to have a common Product Backlog and keep it manageable. The Scrum of Scrums process is introduced as a common tool for helping align multiple Scrum teams working on a large project, where the Scrum of Scrums follows the basic approach of the Daily Scrum, with little more leniency, with the key difference that only 1 team member (often the Scrum Master) attends the Scrum of Scrum.
Distributed Scrum
This Nugget focuses on how to adopt Scrum to support a distributed team. Scrum absolutely supports distributed, but does require a little more time, attention and focus to make it work. This Nugget reviews the pros and cons and recommendations for ensuring the distributed Scrum teams work effectively. The two key methods discussed are a stringent focus on communications and inter-team relationships and the use of automated Scrum tools. The other key consideration for distributed Scrum discussed is that "just a little more" words are required - stories need a little more detail, documentation and training needed to be more detailed, etc. - because the author of the story, documentation, etc., may be on the other side of the world which makes the need for each artifact to be standalone and less reliant on ad hoc conversations.
Scrum Process Improvement
This Nugget addresses a number of ways in which a team and an organization can continually get better at Scrum. Scrum innovations are relatively easy to implement as there are very few Scrum rules constraining innovations and improvements. The most common way of implementing Scrum improvements is to incrementally implement Scrum and Agile principles. This Nugget explores ways in which incremental implementation of these principles can be applied specific to project and organizational requirements and characteristics. As previously discussed, the Sprint Retrospective is the key process improvement approach in Scrum. This Nugget expands on the importance of adhering to the Sprint Retrospectives and adds the concept of Organizational Retrospectives, which focuses on making the overall organization more effective at using Scrum. Next, the Nugget presents how gathering and analyzing metrics helps identify key areas for process by comparing how a team or project is performing against other projects in the organization or how the organization compares to industry norms. This Nugget explains the phrase "Scrum takes hours to understand and years to perfect" - process improvements are the steps taken toward perfecting Scrum in an organization.
How to Deal with Organizational Resistance
This Nugget discusses a number of areas where you as a Scrum Master might expect to see resistance. The Nugget starts with a discussion on team resistance. The expectation is that team resistance will be minimal, as most Scrum teams are composed of individuals who are interested and excited about being on a Scrum project. Nevertheless, there will be some team resistance, specifically the standard fear and doubt about anything new, even if they are excited about the change. The Nugget will review answers to questions like “What if I don’t like it? What if I am not good at it? What if Scrum doesn’t last?" Another key area for team resistance is fear about career path, promotions and raises as “all Scrum team members are equals on a self-managed team." This Nugget also provides suggestions for how to deal with these concerns. Next, the Nugget addresses business/product owner resistance. The first area of discussion is that if there is too much resistance in this area, Scrum will probably not succeed, as these roles are critical to Scrum success. However, even the most committed businesses/product owners will probably have concerns with Scrum approaches as there is perception that there are “no guarantees” for delivery and the lack of predictability on releases. As with the team resistance, this Nugget presents a number of suggestions for dealing with these areas of resistance. Next the Nugget focuses on general organizational resistance. The most common form of resistance in this area is the “Scrum is just another IT fad; why bother with it, it will come and go with no impact." The main argument to this resistance is that Scrum is neither a fad, it is over 10 years old and has been delivering results for some time. Other defences to organizational resistance include helping executives understand that Scrum does not support organizational anarchy. Next, the Nugget provides support for dealing with Administrative resistance from the HR and Facilities departments. And, finally, the Nugget provides support for dealing with a very common area of resistance, our own IT department.
How to Get Started with Scrum
This Nugget walks through a number of options for getting started with Scrum. The first area discussed is how “big” an organization's first Scrum step should be. The Nugget presents pros and cons for starting small (a single team), medium sized (6 teams) and large (going all-in on day 1). The next topic discussed relates to the best approach for developing Scrum expertise in your organization. Options presented are to grow from within, while others opt to hire Scrum expertise and others choose to bring in consultants with the required expertise to complete knowledge transfer. Next, the subject of starting Scrum with a large public announcement versus starting Scrum quietly with little to no organizational awareness until success can be declared. Again, pros and cons of each approach are presented in the Nugget. The final discussion for Scrum start-up reviews the pros and cons on whether a designated pilot project is the best approach for introducing Scrum into an organization. The Nugget closes with a discussion on the next steps to ensure that Scrum adoption continues in the organization.

No Bookmarks

This series will provide a comprehensive review of the Scrum development approaches and provide the background needed to become a Certified Scrum Master.

Trainer Steve Caseley provides an overview of Scrum, including the roles, activities and project management tools. Steve breaks down the specific duties of each Scrum Role: Scrum Master, Product Owner and Scrum Team, as well as the Scrum rituals that form the core of Scrum. The series also explores the similarities and differences between Scrum and traditional development approaches and examines the six different Scrum certifications from the Agile Alliance.

This training has been approved for Category A PDUs. For a listing of how many PDUs are earned for this training, please visit our PMI R.E.P. FAQs on our Forum.

Introduction to Scrum

00:00:00 - Welcome to this series on scrum master preparation.
00:00:05 - Scrum is a very widely recognized agile development process.
00:00:11 - This nugget is going to introduce you not only to scrum but introduce
00:00:15 - you to the specifics of scrum master certification or the process
00:00:21 - to follow to become a scrum master.
00:00:26 - In this introductory series we're gonna cover the very high
00:00:30 - level of what scrum and scrum mastering is all about. We'll give
00:00:34 - you an overview of the scrum process. We'll describe the scrum
00:00:39 - roles of which the scrum master is one. But there are other key
00:00:43 - roles involve with scrum project work. We'll talk about the key
00:00:49 - principle of scrum development which is we develop in releases
00:00:53 - and within the releases we develop in individual sprints where
00:00:58 - a sprint has a very defined time box.
00:01:06 - Then we'll talk about some of the scrum rituals.
00:01:10 - You're going to hear or you've probably heard terms such as the
00:01:14 - daily scrum, the sprint review process, the retrospective, and
00:01:21 - so on. So we'll orient you to the various scrum rituals or processes
00:01:25 - to be followed in a scrum development project. And we'll talk
00:01:30 - a little bit about scrum management. There is management process
00:01:35 - in scrum and, again, there are probably a few terms that you've
00:01:38 - heard of such as the daily burn down chart, the story burn up
00:01:41 - chart and so on. That will give you an overview of what scrum
00:01:46 - management is all about because there is a management process
00:01:50 - in scrum. And finally, we'll talk about or differentiate the
00:01:54 - differences between scrum and other agile development processes.
00:02:00 - But, first, let's roll up our sleeves and focus on what is
00:02:04 - scrum. So probably the very hardest thing I had to do in this
00:02:09 - nugget series is to give a definitive definition of scrum.
00:02:14 - What is scrum? Is a systems development approach? Yes. Is scrum
00:02:21 - exclusive for systems development? Absolutely not. Anything
00:02:28 - and I even hesitate to use the word thing but anything you want
00:02:33 - to do that requires a level of work typically of a unique variety
00:02:39 - because scrum is not truly designed for routine day to day production,
00:02:45 - doing the same thing manufacturing widgets day in day out. That's
00:02:49 - not scrum. So I would start to say scrum is based on project
00:02:56 - based work,
00:03:00 - where a project is a unique undertaking to develop, to deliver,
00:03:06 - to produce something new and unique.
00:03:11 - Does it have to be software?
00:03:15 - No. Typically, when we discuss scrum and most of the approaches
00:03:20 - we're gonna discuss in this nugget series are based on software
00:03:25 - development undertakings.
00:03:27 - And I really struggle with using the word project because most
00:03:32 - agilist and most scrum specialist try to differentiate between
00:03:37 - what we do with scrum approaches and traditional project approaches,
00:03:43 - and that is very, very true. Scrum is very different than traditional
00:03:49 - approaches and we'll discuss that in a future nugget. But I
00:03:53 - will continue to largely call out the work we're doing within
00:03:58 - scrum as project based work simply because it's unique and
00:04:05 - it has a goal.
00:04:08 - So when I refer to projects, I'm talking about something, some
00:04:11 - piece of work, something that we're going to do that is unique
00:04:15 - and has a goal and requires work. So again I
00:04:21 - have found I use the word project most comfortably. As I say
00:04:26 - there are other scrumists, agilists who prefer to not use the
00:04:31 - word project only because the word project takes us into more
00:04:35 - the traditional mindset. But in the pure textbook definition
00:04:39 - scrum is project based work often associated with software but
00:04:45 - not always. You can do anything in a scrum world. So enough
00:04:50 - with the definition. What is scrum? Scrum is very mush iterative.
00:04:56 - If we are to find a single word, in my humble opinion, that defines
00:05:01 - what scrum is, it's iterative. We do the project in pieces.
00:05:10 - And in a true sense of scrum we will do a project in many,
00:05:17 - many, many pieces.
00:05:22 - Each release
00:05:24 - that we discussed in the introduction and we'll talk more in
00:05:27 - this nugget is a part of the project. Within each release we'll
00:05:32 - have a sprint or a number of sprints that make up a release.
00:05:36 - An the sprint is developing a piece of a project. So that's why
00:05:40 - it's iterative. It's many, many, many pieces. And we'll talk
00:05:44 - about that aspect throughout this entire nugget series.
00:05:49 - Another key differentiator of scrum is it's very lightweight.
00:05:54 - You'll see by the time we finish this nugget series, there is
00:05:58 - some very sound, some very complete, some very robust
00:06:05 - definitions of developing working in a scrum environment, but
00:06:12 - there's not a lot. There is not a lot of memorization, there
00:06:16 - is not a lot of process, there is not a lot of predefined forms.
00:06:20 - As a matter of fact, there are no predefined forms associated
00:06:24 - with scrum. So it's very lightweight. It's easy to learn.
00:06:31 - Scrum is very, very easy to learn, but it's also hard to master.
00:06:38 - I hope by the time we finish this nugget series you have absolutely
00:06:42 - done all of the learning and are even well on the way to mastering.
00:06:48 - As I've already said, it's very simple to understand
00:06:52 - and it's based on these three principles.
00:06:56 - Transparent. There is nothing hidden.
00:07:03 - There's no traditional now the team is gonna go away for a period
00:07:08 - of time, two weeks, two months, et cetera, et cetera, and we're
00:07:12 - going to do some work and just trust us. There's none of that.
00:07:15 - Everything we do in a scrum environment is extremely transparent
00:07:20 - and, as we'll discuss in just a moment when we get into the roles,
00:07:23 - there's going to be a product owner.
00:07:27 - And the product owner represents the business.
00:07:31 - And the product owner is part of the scrum team. And the product
00:07:39 - owner is expected to participate
00:07:43 - daily in the scrum activity. So if you have your product owner,
00:07:51 - if you have the business sitting with the team for a significant
00:07:56 - part of everyday, there is no ability to be non-transparent.
00:08:02 - So scrum is designed to be extremely transparent. We want that
00:08:06 - product owner, we want them involved, we want a feedback, and
00:08:10 - we want to adapt and adjust
00:08:15 - which is the flexible and adaptable.
00:08:18 - And quality is built in. A lot of people, when they look at
00:08:23 - a scrum process or they first hear of scrum process and says,
00:08:27 - yeah, that's just the Wild Wild West. We just have a bunch rogue
00:08:31 - programmers out there writing code as they see fit and calling
00:08:36 - it scrum. It's absolutely not the case. Quality is built in throughout
00:08:43 - scrum. Each one of our iterations, each one of our sprints, and
00:08:49 - each one of our releases has the expectation that we're delivering
00:08:54 - functional, tested,
00:09:01 - implementable code. Or if you're interested in using scrum for
00:09:10 - non-development approach, each sprint results in meaningful results
00:09:16 - that the business can choose to use at the end of each sprint.
00:09:22 - So transparent, nothing is hidden. We want full active participation.
00:09:28 - We build quality in. It's not the Wild Wild West. It's tested
00:09:33 - implementable code at every step of the process. And, as we discuss
00:09:39 - some of the agile process that we're gonna apply continuous
00:09:43 - build, continuous integration, test driven development. What
00:09:48 - we deliver in a scrum environment is quality and it's flexible
00:09:52 - and adaptable.
00:09:54 - Because our sprints
00:09:57 - are short,
00:10:00 - if we find we made some mistakes, if we find our approach is
00:10:05 - not correct, if we find we need to fix things at the end of each
00:10:09 - sprint, we have a retrospective and in the retrospective we have
00:10:14 - the ability to be flexible and adaptable to improve continuous
00:10:18 - process improvement.
00:10:21 - So with this relatively brief introduction to scrum, I hope
00:10:25 - I've whetted your appetite on scrum and that you're ready to
00:10:28 - continue through this introductory nugget and certainly through
00:10:33 - this entire series to better understand scrum and to be better
00:10:37 - prepared to take your scrum master certification.
00:10:41 - So consistent with the fact that scrum is lightweight and easy
00:10:46 - to understand, there are five main roles defined in a scrum process.
00:10:54 - The key role
00:10:57 - is the scrum master. And I hesitated to say the key role is because
00:11:02 - most people will suggest the product owner is the key role in
00:11:06 - a scrum project.
00:11:09 - For the sake of this nugget series, I'm saying the key role is
00:11:12 - the scrum master because that's why we're developing, that's
00:11:16 - why we're taking this series, is to understand what scrum mastering
00:11:21 - is all about and to prepare you to become a certified scrum master.
00:11:27 - The scrum master is not
00:11:30 - a project manager.
00:11:35 - The scrum master is a guide.
00:11:39 - The scrum master is a facilitator.
00:11:44 - The scrum master may be a participating team member.
00:11:54 - The scrum master has no authority,
00:12:00 - but a lot of influence.
00:12:07 - I still believe the scrum master is key to the success of scrum
00:12:12 - processes because without any effective scrum manager filling
00:12:17 - these roles of the guide, the facilitator,
00:12:20 - able to work in a non-authoritative manner, but to influence
00:12:25 - the team and guide the team success,
00:12:28 - again, I believe the scrum master is certainly a key member of
00:12:34 - the scrum development team. If not the key as I say, a lot
00:12:39 - of other proponents of scrum will say the product owner is the
00:12:43 - key role because the product owner is the person with the authority
00:12:50 - on what
00:12:53 - is done.
00:12:55 - And that's where the product owner's authority stops. The product
00:12:59 - owner defines
00:13:01 - what it is the team is gonna develop. The product owner creates
00:13:06 - things called user stories. The product owner provides the details
00:13:11 - around what a user story is. And we'll talk much more about a
00:13:15 - user story later in the series. But the user story basically,
00:13:19 - again, identifies the what
00:13:21 - and the product owner identifies the priority
00:13:28 - in which the whats are gonna be done. And the product owner provides
00:13:33 - all of the details that the team needs to complete the whats.
00:13:38 - The team has the authority
00:13:44 - on how
00:13:46 - they accomplish the what.
00:13:50 - So the team is the people who work as a self-organizing,
00:13:56 - self-managing, self-controlled
00:14:01 - unit. There is no project manager in scrum. There is self-organizing,
00:14:08 - self-managing team that collectively determine how they're going
00:14:15 - to complete all of the work that the product owner has identified
00:14:18 - that needs to be done.
00:14:21 - The scrum master guides, facilitates, and influences the team,
00:14:26 - influence the businesses, and to me one of the key
00:14:30 - roles of the scrum master is removes the roadblocks to allow
00:14:34 - the team to get the work done. And these three are really the
00:14:39 - core team,
00:14:42 - and they're all participating members. As I said, we have transparency.
00:14:48 - The product owner is part of the team. The team does the work.
00:14:53 - And the scrum master ensures the team works in a scrum-like method
00:15:00 - and that is literary the core team. We have two other roles
00:15:05 - identified SME�s, subject matter experts. Subject matter experts
00:15:11 - are not part of the team. Subject matter experts are called in
00:15:16 - as needed.
00:15:19 - In a utopia world we would not need any SME�s because the product
00:15:25 - owner is all-knowing, all-seeing, all-wise.
00:15:30 - In most real life business environments a single person, the
00:15:35 - product owner, is not all-knowing, all-seeing, all-wise, so therefore,
00:15:39 - there will be instances where the product owner says, you know,
00:15:42 - I really don't know that answer, why don't you call Susan? And
00:15:45 - Susan becomes the
00:15:48 - SME. And then, finally,
00:15:51 - we have another key person and that's the business owner. That's
00:15:54 - the person with the dollars. That's the person with the need.
00:16:00 - And the product owner and the business owner may be one person
00:16:04 - but often not, the business owner is typically manager
00:16:10 - who has the power and the authority to commit organizational
00:16:15 - resources, i.e. dollars to the project, and managers don't have
00:16:20 - the time to sit with the team four hours every day to work on
00:16:25 - the scrum approaches. So the business owner appoints a product
00:16:30 - owner who does the day to day interaction with the team. The
00:16:35 - product owner typically organizationally
00:16:38 - reports to the business owner. And, typically, the product owner
00:16:42 - reports to the business owner from a project results viewpoint
00:16:45 - as well. And that's it. Those are all of the roles associated
00:16:51 - with scrum. Now, we have an entire nugget that's gonna go through
00:16:55 - the roles and responsibilities of these team members in much
00:16:58 - more detail, but at an introductory level these are our scrum
00:17:02 - roles. And if you'll excuse my drawing, I know I'm not the
00:17:06 - most artistically talented in the world, this diagram to me represents
00:17:11 - the concept of releases in sprints.
00:17:16 - Overall, this black area, and I deliberately did not draw this
00:17:20 - as square or regular object because projects are typically not
00:17:25 - that well defined. There's typically a lot
00:17:30 - changes, flexibility, well we're not gonna do this little piece
00:17:34 - here because that's better done inside the project and there's
00:17:38 - a significant amount of work here that's, again, business process,
00:17:42 - manual activities, as opposed to everything inside the black
00:17:48 - object is the product that our scrum team is gonna develop. And
00:17:56 - the developing this product may take a considerable amount of
00:18:00 - time. It may take six to 12 months
00:18:04 - to do all of the work associated with developing that product,
00:18:09 - taking on six to 12 months delivery as a single delivery is a
00:18:15 - traditional development project, and we know scrum is not a traditional
00:18:18 - development project because it's iterative with multiple releases
00:18:22 - and multiple sprints. So the business owner and the product owner
00:18:28 - work together to develop a release strategy. And they say this
00:18:33 - can be release number one and this can be release number two
00:18:37 - and release number three and so on. So if we deliver this functionality
00:18:42 - here, there's business value, let's call that a release. And
00:18:46 - then we augment that with some more business value here. Let's
00:18:50 - make that a release. So we'll release may be one to two months
00:18:55 - in length.
00:18:57 - And that, again, is far too much timeframe for a traditional
00:19:03 - scrum approach,
00:19:05 - so then we take each release and we break it into number of sprints.
00:19:09 - So this is sprint number one, sprint number two, three, and so
00:19:13 - on. And these sprints are in very short
00:19:18 - timeframes, where I am hesitating to tell a defined number for
00:19:25 - the length of a scrum sprint because there is some flexibility.
00:19:31 - But, typically, a scrum sprint is somewhere in the one to four
00:19:35 - week rage where, again, typically,
00:19:39 - a lot of projects don't work at the extreme so there's not a
00:19:42 - lot of sprints that are a week long or not a lot of scrum development
00:19:47 - approaches that take only one week sprints, nor are there a lot
00:19:51 - that take as much as four weeks because we lose some of the adaptability
00:19:55 - and flexibility so most sprints are in the two to three week
00:19:59 - window. And in each one of these sprints we deliver a little
00:20:04 - piece of the overall product. And when we combine sprints together,
00:20:13 - we get a release. And the release gives significant business
00:20:18 - value and, when we build all of the releases, we get the entire
00:20:22 - product. Now, a key concept of releases in sprints and scrum
00:20:29 - approaches in general is when the business owner and the product
00:20:34 - owner did the original plan this is what they thought the product
00:20:39 - was gonna look like but partway into it the product vision is
00:20:44 - going to change and we start to build that piece out there and
00:20:48 - we start to
00:20:50 - take this piece out and we build it and we reduce functionality
00:20:54 - and so on. And in a traditional approach, this is all done through
00:20:58 - change management and formal approval and formal authorization
00:21:03 - and work to do all of that. None of that happens in sprint because
00:21:07 - all of this change is outside of our current sprint. So if
00:21:13 - the business wants to add more functionality, we'll get to it.
00:21:17 - When's that schedule? Oh, that's gonna be in release number six,
00:21:20 - great. The business decided to remove functionality and that
00:21:24 - was gonna be done in release number five, awesome. So now, release
00:21:27 - number five can do this piece over here oops, five not two.
00:21:34 - So this is again part of the adaptability and flexibility of
00:21:39 - using scrum processes is it lets the business adjust and flex
00:21:45 - and deliver exactly what it is the business needs as business
00:21:50 - change happens and as the business requirements evolve.
00:21:56 - And consistent with being lightweight there are very few scrum
00:21:59 - rituals we need to concern ourselves with. There are four main
00:22:04 - scrum rituals and I presented this a little out of order. I presented
00:22:09 - the daily scrum first because my expectation is that's the first
00:22:13 - ritual you probably have heard off. That's the thing people think
00:22:17 - of most when they think of scrum development. And that's the
00:22:21 - daily scrum and this is your 15 minute stand up meeting
00:22:29 - where the team meets on a daily basis, hence, the term daily,
00:22:35 - for no more than 15 minutes. And in order to try to keep it to
00:22:39 - 15 minutes we recommend that this be a stand up meeting. If you're
00:22:44 - standing up and getting tired on your feet, you're not gonna
00:22:47 - be as prone to talk as opposed to, if you're sitting in comfy
00:22:51 - chairs with lots of sweets sitting on the table and some nice
00:22:56 - fresh coffee at the back, your 15 minutes stand up meeting quickly
00:23:00 - extends to an hour and a half because people just simply want
00:23:04 - to enjoy the soft chairs and the donuts and the fresh coffee.
00:23:08 - So, idea of the daily scrum, 15 minutes max, stand up, get
00:23:14 - it done and is what did we do?
00:23:18 - We do yesterday, what are we gonna do
00:23:25 - to do today and issues,
00:23:28 - problems, quick round the table, talk to every team member, awesome,
00:23:36 - we know what's going on. Joe, can you work with Betty to help
00:23:40 - Betty accomplish what she's gonna do? Fred, how did this go yesterday,
00:23:43 - did that approach work? Awesome. Why don't we try that going
00:23:46 - forward and so on and so on? It's a perpetual process improvement
00:23:52 - to ensure the team is on track to achieve the objectives of the
00:23:57 - sprint. The first ritual that we do in scrum, so again literary
00:24:02 - it should have happened up there, is the planning meeting. And
00:24:07 - the planning meeting actually is where the business
00:24:12 - requirements are presented, where the product owner selects the
00:24:16 - stories that are next most important to the business. Story 15,
00:24:22 - story 36, story 49, and story 2 are the next most important stories,
00:24:29 - pieces of business functionality that I want the team to focus
00:24:32 - on over the next sprint. So part one of the planning meeting
00:24:36 - is we select the stories.
00:24:39 - And when I say we select the stories, the product owner selects
00:24:43 - the stories based on priority. And in the second half of the
00:24:47 - planning meeting the team validates
00:24:52 - that they can accomplish the story selected, that there's enough
00:24:55 - information at hand, that they understand the stories well enough
00:24:59 - to do the work, that there's enough time, that the environment
00:25:03 - is prepared, et cetera, et cetera. So with the planning meeting
00:25:06 - done, we then start the sprint
00:25:10 - two to three weeks on average
00:25:15 - and we have a daily scrum for everyday of those two to three
00:25:19 - weeks where we ensure that we're still on track
00:25:24 - for our approach that we've delivered for the sprint.
00:25:28 - At the end of the sprint, we do a scrum review, where we represent
00:25:33 - the results.
00:25:38 - So business product owner, you asked us to do these stories,
00:25:43 - we're going to have a little show and tell. We're gonna show
00:25:46 - you the results, we're gonna prove to you that we achieved everything
00:25:51 - you asked us to do. Is that acceptance test? Kind of. Presenting
00:25:57 - the results should be short and sweet. This should not take a
00:26:00 - lot of time. We do not expect formal Power Point presentations.
00:26:05 - It's literary a roll up the sleeves and presents the results.
00:26:09 - Get confirmation that you have achieved the results, the expectation
00:26:13 - of the sprint, and declare the sprint done. And then, finally,
00:26:17 - have a quick retrospective to say, what worked,
00:26:24 - what didn't work,
00:26:28 - and start the process improvement.
00:26:31 - And the last key aspect to scrum work is there is a scrum management.
00:26:36 - Like everything else in scrum it's very lightweight.
00:26:41 - There aren't project management plans, there aren't formal Gantt
00:26:44 - schedules, there aren't most of the things we typically associate
00:26:48 - with project management, but there is scrum management at a very
00:26:53 - lightweight. And probably one of the main scrum management tools
00:26:57 - is the burn down chart. How well are we doing? Here is a graph
00:27:03 - for the sprint, day one, day two, through day
00:27:08 - ten or day 15, depending on whether there are two or three week
00:27:11 - sprint. Here's our objective. We wanted to do 14 stories. At
00:27:16 - the end of day one how many stories, at the end of day two, and
00:27:20 - so on, and we had a little lull in there where we had some complex
00:27:24 - stories and we're tracking our progress to see if we accomplished
00:27:29 - the expectations of the scrum.
00:27:34 - Talked about stories already. The story curds is where the
00:27:38 - product owner
00:27:43 - defines the whats.
00:27:47 - We don't do a large analysis document. We do a number of story
00:27:52 - curds. And most people recommend story curds are handwritten,
00:27:59 - so hopefully, your handwriting is better than mine, on index
00:28:02 - cards. And this index cards are used with thumbtacks and maintained
00:28:10 - on a peg board or corkboard. But the story curds are part of
00:28:16 - the management where we identify the whats that's gonna be required
00:28:20 - and we combine the story cards on that corkboard to give us the
00:28:25 - product release backlog.
00:28:29 - So here are all of the story cards that are required to satisfy
00:28:34 - all of the whats. The product owner goes to the product backlog
00:28:40 - as part of sprint planning and selects the next hire urgency
00:28:45 - prioritized stories and presents them to the team.
00:28:49 - We use that to develop the sprint backlog. The sprint backlog
00:28:53 - is obviously the input to the burn down chart and it identifies
00:28:58 - the 14 stories
00:29:01 - that we want to accomplish in the sprint. And the final aspect
00:29:05 - that we haven't discussed yet in this nugget as part of scrum
00:29:08 - management is this principle of velocity.
00:29:12 - How long
00:29:16 - does or is a story?
00:29:20 - How much work is required to complete the story and how much
00:29:26 - work can the team do
00:29:32 - in a sprint?
00:29:37 - So with this concept of velocity we're able to take that sprint
00:29:42 - backlog, validate that we have the ability to complete all the
00:29:46 - stories that the business has selected, and we can use our velocity
00:29:51 - to track how well to ensure the predictability of our burn down
00:29:57 - chart is allowing us to achieve our expectations of completing
00:30:03 - the sprint in ten days. And in a nutshell, that's it for scrum.
00:30:09 - Scrum is all about developing an agile approach to software development,
00:30:16 - which leads us to our next discussion point, what is the difference
00:30:20 - between scrum and agile? So where does agile fit in? Well, my
00:30:25 - first statement is scrum is agile. Agile to me is a lightweight
00:30:34 - software development process.
00:30:41 - Scrum is a lightweight software development process. The big
00:30:46 - distinction I make between scrum,
00:30:49 - and scrum is very focused on the "management",
00:30:55 - and I will definitely put that in quotation marks and I try to
00:30:59 - write it in the small of letters as possible and still allow
00:31:02 - you to read my horrible handwriting because scrum is management
00:31:07 - light as we've experienced, but scrum is the management process.
00:31:13 - It's identifying of the roles. It's identifying
00:31:19 - the rituals that we're gonna go through. It's identifying of
00:31:22 - the artifacts we're going to produce. So scrum is a way
00:31:27 - to develop lightweight software
00:31:30 - and scrum applies
00:31:33 - at your project discretion most of the agile development processes
00:31:38 - for software development such as test driven development. Write
00:31:43 - the test cases then write the code to ensure that test cases
00:31:47 - are successful. Ensures we're delivering quality. Where appropriate,
00:31:52 - scrum supports pair programming.
00:31:56 - Scrum absolutely expects that we're gonna do refactoring, that
00:32:00 - we are going to have technology debt, that we going to have to
00:32:03 - do process improvement, that, as we add new functionality in
00:32:07 - future sprints or future releases, that we're gonna break things
00:32:11 - and we need to do improvement, so we're gonna have refactoring
00:32:15 - recognizing the technology debt is inevitable in a lightweight
00:32:22 - incremental iterative software development process. Scrum recognizes
00:32:28 - the technology debt exists and must be removed through future
00:32:32 - sprints and future releases and absolutely supports the concept
00:32:37 - of continuous integration. You complete a piece of code, you
00:32:41 - check it into the repository, you run the build, and you make
00:32:44 - sure you didn't break anything. So the distinction between
00:32:49 - scrum and agile is scrum is one of the agile processes. Scrum,
00:32:56 - I believe, is one of the most popular and most successful agile
00:32:59 - processes because scrum has this very small letter, quotation
00:33:05 - marks management process, and when we apply our scrum processes
00:33:11 - and other proven agile development techniques, I believe we have
00:33:17 - an absolute recipe for success.
00:33:21 - So in this introductory nugget to the scrum master preparation,
00:33:25 - we provided a high level overview of scrum.
00:33:34 - We defined what scrum is. It's a lightweight
00:33:40 - iterative process
00:33:44 - with some very light management to help us develop
00:33:49 - traditional software but any project in an iterative flexible
00:33:54 - manner. We discussed scrum roles, the scrum master,
00:34:02 - the product owner,
00:34:07 - and the team
00:34:09 - as the three core roles to participate in a scrum project. We
00:34:15 - talked about releases and sprints combining to deliver the specific
00:34:19 - requirements of the business. We identified a number of scrum
00:34:24 - rituals where the daily scrum,
00:34:29 - the planning meeting,
00:34:32 - the scrum review,
00:34:37 - and the scrum retrospective
00:34:43 - allows us to keep the scrum project under control consistent
00:34:48 - with scrum management where we provide a very lightweight management
00:34:52 - approach. And we concluded with a review of scrum is one adaptation,
00:34:59 - one method of being agile.
00:35:02 - So with this introductory nugget concluded, I hope you've remained
00:35:07 - interested in scrum development that you continue your interest
00:35:12 - in becoming a scrum master. And I encourage you to continue through
00:35:19 - the rest of this nugget series and further explore and further
00:35:23 - understand this exciting world of becoming a scrum master. This
00:35:29 - concludes our nugget and scrum master preparation. I hope this
00:35:33 - module has been informative for you. And thank you very much
00:35:36 - for viewing..

Scrum versus Traditional Development

Scrum Roles

Scrum Meetings

Scrum Artifacts

Scrum Master

Product Vision and Product Backlog

What is done?

Release and Sprint Planning

Scrum Estimating

A Sprint

Daily Scrum

Tracking Progress

Dealing with Changes

The Product Owner

Sprint Review and Retrospective

Backlog Grooming

Writing User Stories

Team and Business Dynamics

Technology and Process Debt

Agile Development Techniques - 1

Agile Development Techniques - 2

Delivering Large Projects with Scrum

Distributed Scrum

Scrum Process Improvement

How to Deal with Organizational Resistance

How to Get Started with Scrum

This forum is for community use – trainers will not participate in conversations. Share your thoughts on training content and engage with other members of the CBT Nuggets community. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus
Community Standards

We encourage you to share your wisdom, opinions, and questions with the CBT Nuggets community. To keep things civil, we have established the following policy.

We reserve the right not to post comments that:
contain obscene, indecent, or profane language; contain threats or defamatory statements; contain personal attacks; contain hate speech directed at race, color, sex, sexual orientation, national origin, ethnicity, age, religion, or disability; contributes to a hostile atmosphere; or promotes or endorses services or products. Non-commercial links, if relevant to the topic, are acceptable. Comments are not moderated, however, all comments will automatically be filtered for content that might violate our comment policies. If your comment is flagged by our filter, it will not be published.

We will be continually monitoring published comments and any content that violates our policies will be removed. Users who repeatedly violate our comments policy may be prohibited from commenting.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer


Area of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development

Course Features

Speed Control

Play videos at a faster or slower pace.


Pick up where you left off watching a video.


Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

MP3 Downloads

Listen to videos anytime, anywhere
Your browser cannot access Virtual Labs
Add training to a playlist
or create a new list
Add to current playlist
or add to an existing list
Add to new playlist