Proven Scrum Master Certification Training For Agile 2026

This section discusses the Scrum org Professional Scrum Master certification, PSM I, which is the first step in a series of courses offered by Scrum org. The course also mentions the Product Owner certification, PSPO I, which has similar questions and is recommended to be attempted alongside PSM I. The PSM I certification assessment consists of multiple-choice questions, some of which have multiple correct answers. The passing score is 85%, and candidates have 60 minutes to answer 80 questions. Preparation strategies include watching the course, attempting mock exam questions, studying required reading material, and practicing with free Scrum questions available online. The course encourages candidates to visit the Scrum org website for more information and wishes them good luck.

Scrum org offers valuable and well-organized resources for free on its website, covering various aspects of Scrum. These resources cater to individuals interested in becoming Scrum Masters, Product Owners, leaders, or software developers. The website provides blogs, videos, and other formats to explore topics such as the agile manifesto, empiricism, scrum events, and the scrum goal. For instance, there are blog posts discussing the pillars of empiricism and videos explaining concepts like empiricism using relatable examples. Visitors can also find resources on developing people, managing products with agility, and more. Engaging with these resources not only enhances understanding of Scrum but also aids in applying it effectively in practice.

Scrum org offers a dedicated section for videos, providing a valuable resource for individuals who prefer learning through this format. Accessible from the top right corner of the website, this section contains numerous videos covering various aspects of Scrum. Exploring different resources, including videos, is recommended not only for preparing for the PSM I certification but also for staying updated on Scrum practices and theory changes. Continuously engaging with such resources helps in further solidifying one's understanding of Scrum.

As a Scrum Master, your primary responsibility is to establish Scrum practices defined in the Scrum Guide, helping the team understand theory and practice. You're accountable for the team's effectiveness by enabling improvements within the Scrum framework, essentially becoming the Scrum champion. Your role involves removing impediments and blockers to progress, serving as a true leader. While previously described as a servant leader, the Scrum Master serves the team, Product Owner, and organization, with a focus on embedding Scrum, enhancing team effectiveness, and providing leadership support.

This lecture introduces the role of the Product Owner in Scrum, a framework for managing complex projects. The Product Owner is responsible for maximizing the value of the product by prioritizing work tasks, defining the product goal, and ensuring the product backlog is transparent and understood. They are accountable for their decisions and work with stakeholders to understand customer needs. The organization must respect and trust the Product Owner's judgment, as their decisions contribute to the overall success of the product.

This lecture introduces the role of Developers in Scrum. Developers are cross-functional team members who work collaboratively to create increments of the product within each sprint. They are empowered and self-managed, responsible for planning, executing, and ensuring quality throughout the sprint. Developers are accountable for creating a sprint plan, adhering to the definition of done, adapting their plan daily, and holding each other accountable. The sprint backlog is the list of tasks for the sprint, the definition of done sets the criteria for completing tasks, and the sprint goal is the overall objective of the sprint. Developers should hold each other accountable and address issues as a team. Scrum teams typically consist of 3-9 members.

This lecture emphasizes the structure and size of a Scrum team, which consists of a Scrum Master, a Product Owner, and Developers. While the Scrum Master and Product Owner can also participate in development, the team should remain small and cohesive, ideally consisting of no more than 10 members to enhance communication and productivity. The importance of maintaining a nimble team is highlighted, as larger teams may hinder effectiveness. The Scrum Guide advocates for these principles to ensure the team can focus on achieving their product goal efficiently.

This lecture highlights the critical role of the Product Owner within the Scrum framework, emphasizing their responsibility to ensure that the team's work is valuable and aligns with the overall product vision and goals. The Product Owner plays a vital role in delivering a product that meets customer requirements and benefits the business. Participants are encouraged to reflect on past projects where roles may have been misaligned, particularly considering whether a Product Owner was present. By examining these roles retrospectively, individuals can better understand the importance of having a clear vision and effective communication among team members. This reflection can inform future projects, reinforcing the need for defined roles within Scrum to enhance outcomes.

Becky, the Product Owner, has been tasked by the bike club to create a website shop targeting young professional women aged 20 to 35, with a modern, feminine, and friendly aesthetic. The website needs to promote specific bike models based on supply and demand changes and have typical online shop functionalities such as search, sort, and filter options. Additionally, the site should include pages for articles, news, and search engine optimization. However, the bike club's requirements are somewhat vague, leaving room for interpretation. Becky anticipates that requirements may change during development, a concern stemming from past experiences with lengthy projects that didn't meet customer expectations. The goal is to use Scrum to iteratively develop the website, addressing uncertainties and ensuring customer satisfaction.

This lecture focuses on the significance of determining sprint length in Scrum, which is essential for establishing a consistent workflow. Sprints are fixed-length events, ideally lasting one month or less, and they should begin immediately after the conclusion of the previous sprint. The speaker recommends two-week sprints as a balanced approach, allowing for frequent inspection and adaptation without hindering progress. Each sprint encompasses several key events, including sprint planning, daily scrums, sprint reviews, and sprint retrospectives, all aimed at facilitating transparency and enabling teams to inspect and adapt their work effectively. These events help minimize the need for additional meetings while ensuring that communication remains a priority. The lecture concludes with a practical exercise of scheduling these events in Microsoft Outlook, reinforcing the structure of Scrum and its processes.

The focus now is on scheduling sprint events, ensuring they're in everyone's calendars as placeholders, even though scheduling around other commitments may be challenging. The first step is to plan a kickoff meeting to introduce the team, discuss the project, and explain Scrum principles. This meeting includes introductions, project overview, and Scrum framework explanation. Following this, the team will engage in a requirements gathering session to initiate the backlog. This session involves brainstorming and categorizing requirements, prioritizing them, and potentially considering risks and dependencies. The aim is to develop the product backlog for sprint planning. The meeting agendas include introductions, discussing known requirements, brainstorming, categorizing and prioritizing requirements, and setting the stage for sprint planning. While agendas may vary, the primary goal remains to initiate the backlog and prepare for sprint planning. Detailed agendas and stakeholder management discussions are covered in the practical section of the course.

In this section, you emphasize the importance of determining the sprint length in establishing the Scrum framework, highlighting that sprints cannot exceed one month. You propose bi-weekly sprints as a balanced choice to enable regular feedback while minimizing disruptions and stress the significance of consistency in the sprint start day. Key events include scheduling a three-hour sprint planning meeting on Tuesday at 10 AM, ensuring project names are included in the titles for clarity, and inviting relevant stakeholders to assist in planning. A structured agenda for the sprint planning meeting should include discussions on the sprint goal, product backlog review, and team capacity assessment to determine the sprint backlog. Additionally, you recommend setting the sprint planning as a recurring meeting every two weeks with a specified end date based on the project roadmap, and highlight the necessity of daily scrums to maintain communication and address impediments effectively.

The daily Scrum should be scheduled for 15 minutes at 9 AM, and it's essential for you, as the Scrum Master, to ensure that it stays within this time limit. The daily meeting should include the Scrum team, and it's common to hold it in a standing format to encourage brevity in updates. Participants should briefly share what they accomplished yesterday, their plans for today, and any blockers they're facing, based on guidance from the Scrum Guide. Following the daily Scrums, you need to schedule the sprint review and sprint retrospective, which will occur on the Monday after the sprint wraps up. It's crucial to ensure that all meetings are set for weekdays only, avoiding weekends to maintain professionalism. Before sending invites, make all necessary adjustments in your calendar to avoid multiple notifications and spam for recipients. Once everything looks good, forward the finalized invites to the team to maintain clear and efficient communication.

As we approach the end of our sprint on Monday, the 24th, we need to conduct a Sprint review, and I recommend having a dress rehearsal beforehand to ensure a professional presentation to stakeholders. This rehearsal can take about an hour in the morning, followed by the Sprint review at 2:00 PM, which should last no longer than two hours since we are working with bi-weekly sprints. We'll invite the Scrum team and relevant stakeholders, specifying a location for the meetings—either virtual or in-person. To provide context, we can refer to the Scrum Guide for a brief description of the Sprint review, which will include introductions, a review of the sprint goal, main tasks, and performance against the sprint objectives, followed by demonstrations from the developers and feedback from stakeholders. This structure allows us to assess our achievements and plan for the next sprint while also providing an opportunity for open discussion on any other business.

To conclude our sprint process, we will hold the Sprint retrospective, which provides a valuable opportunity for the team to reflect on the sprint's performance in a relaxed and informal setting. It's best not to schedule this meeting immediately after the Sprint review, as participants may feel fatigued. Instead, we'll allow for a break before starting the retrospective, keeping it concise at one hour. Although the ideal duration for a monthly sprint retrospective is up to three hours, this shorter format will maintain engagement.

We will invite the Scrum team and set a specific location for the meeting, ensuring that an agenda is in place, referencing the Scrum Guide for guidance. It may also be beneficial to utilize a free online tool for anonymous feedback during the retrospective, which I can assist with setting up in advance. This meeting will repeat every two weeks on Mondays, rounding out our sprint events: Sprint planning on Tuesdays, daily scrums every weekday, a Sprint review rehearsal before the official review, and the Sprint review itself. This comprehensive schedule ensures we cover all necessary activities to reflect on our progress and enhance our team's performance moving forward.

In addition to our established sprint events, it's beneficial to incorporate a backlog refinement session, which is often overlooked but crucial for the development team. Scheduling this session on Friday afternoons at 3:00 p.m. for a couple of hours allows us to consistently review and refine the product backlog. While the product owner primarily manages the backlog, developers can become so focused on meeting sprint goals that they neglect to consider the broader roadmap and future tasks. This time can be used to add new items, enhance existing backlog tickets with descriptions and time estimates, and break them down into manageable tasks.

By including this weekly refinement session alongside our bi-weekly sprint events, we ensure that our team maintains a clear and prioritized backlog, ultimately leading to more effective sprints. Setting up these meetings as early as possible in the calendar fosters consistency, enabling the team to stay organized and ready to engage fully in their sprint activities. Now, we're well-positioned to move forward with the creation of the Bikex Club website.

Sprints are the core of Scrum, each lasting one month or less, providing consistency and predictability. They facilitate inspection and adaptation through sprint events: sprint review, sprint retrospective, and sprint planning. Sprints start immediately after the conclusion of the previous one, ensuring continuous progress towards the product goal. Sprint planning sets the sprint goal, determining what the team aims to achieve in the sprint. Shorter sprints generate more learning cycles and limit risks, but excessively short sprints may hinder productivity. Burn-up and burn-down charts, although not part of the Scrum framework, aid in tracking progress and forecasting. Only the product owner has the authority to cancel a sprint if the sprint goal becomes obsolete. In such cases, a review, retrospective, and immediate sprint planning are essential for adaptation and continuous progress.

In summary, you've learned about the roles and events within Scrum and have set up consistent scheduling for these events. Now, it's time to delve into Scrum artifacts. There are three main artifacts: the product backlog, the sprint backlog, and the increment. Take a moment to jot down what you already know about these artifacts, as we'll explore them further in upcoming lectures.

This lecture focuses on the product backlog, which is an emergent, ordered list that outlines everything required to build and improve a product, serving as the single source of work for the Scrum team. It emphasizes the importance of having a singular source of requirements, eliminating confusion from conflicting documents. The product backlog is continually refined and prioritized, allowing the team to adapt as needed, with the product owner accountable for managing it effectively. This includes articulating the product goal, defining backlog items, and ensuring transparency. The product goal, such as creating an enticing, user-friendly website shop to convert visitors into customers, guides the team's planning efforts and highlights that Scrum can encompass more than just software development. Next, we will explore product backlog refinement.

This lecture discusses the product backlog as an emergent list of tasks essential for building a product, starting with high-level items like Epics, which are large bodies of work that can be broken down into smaller tasks. For instance, in creating a website, an Epic could be "design the website," while others might involve setting up technical architecture or creating necessary images. As these high-level tasks require more detail, ongoing product backlog refinement becomes crucial. This involves adding descriptions, ordering items, and estimating time to complete tasks. While the Scrum Guide does not specify a time commitment for backlog refinement, it historically recommended that this process should consume no more than 10% of the Scrum team's capacity, underscoring its importance despite being considered outside of formal Scrum events. It's vital for developers to break down backlog items into manageable tasks they can complete within a single sprint, allowing for better estimation and planning, as they are responsible for assessing the time and effort required. Overall, the product backlog is maintained throughout the product's lifecycle, ensuring it remains relevant even post-launch, as maintenance and improvements will still be necessary. Next, we will put this theory into practice with product backlog refinement

In summary, before delving into sprint planning, it's crucial to establish the backlog, which requires gathering requirements. The initial information from the customer outlines the objective of creating a user-friendly website that converts visitors into customers. To monitor this objective, key results are defined, such as the percentage of visitors converting into customers. Other objectives include ensuring the site's safety, reducing bounce rates, encouraging repeat visits, and optimizing user-friendliness. The target customer base and desired functionality, akin to leading web shops like Amazon, further guide the requirements. A brainstorming session involving the entire Scrum team, customers, stakeholders, and relevant experts is scheduled to flesh out these requirements using the MoSCoW categorization method, which prioritizes must-haves, should-haves, could-haves, and won't-haves.

Find my reference to OKR definitions here:

https://www.workfront.com/strategic-planning/goals/okr

https://www.workfront.com/strategic-planning/goals/okr/okr-examples

This lecture focuses on the importance of identifying and understanding stakeholders when developing a website, emphasizing the need to consider their perspectives to gather relevant requirements. Stakeholders can be internal, such as employees and company owners, or external, including customers and suppliers. The discussion highlights the difference between website users and customers, underscoring the significance of user-focused design. It introduces Agile terminology, such as initiatives, epics, and user stories, illustrating how these concepts can help articulate requirements clearly. For example, user stories are crafted from the end user's perspective, ensuring that the development process remains aligned with their needs. The lecture stresses the necessity of continuously engaging stakeholders throughout the project, ensuring that all relevant parties are identified and involved, ultimately enhancing the website's effectiveness. Additionally, concepts related to a PSM may be relevant in guiding the team through stakeholder collaboration and Agile project management methodologies.

This overview emphasizes the effective management of requirements and their translation into a backlog for software projects, particularly in the context of Scrum Master principles, using tools like Google Sheets or Excel. Initially, these documents capture key requirements—such as the need for the website to be enticing, user-friendly, and effective at converting visitors into customers—before being transferred to a project management tool like Trello or JIRA, ensuring no duplication occurs. Requirements are categorized into epics, such as website shop features, news areas, and performance/security aspects, with user stories illustrating needs from different perspectives, like those of website visitors and customer managers. Prioritization into Must Haves, Should Haves, Could Haves, and Won’t Haves guides the focus on creating a Minimum Viable Product (MVP) through iterative development, a core tenet of Scrum. This process distinguishes between functional requirements (direct features) and non-functional requirements (usability factors) while utilizing empirical evidence and user feedback for ongoing adaptation. The goal is to transition seamlessly from the initial requirements sheet to the backlog, using it as a reference during sprint planning to ensure an effective and user-focused software development process.

Trello is a colorful and user-friendly work management tool that visually organizes tasks as tickets, allowing teams to move them through various stages from backlog to completion. As part of the Atlassian software suite, Trello serves as a simplified version of JIRA, which is more powerful and capable of generating detailed reports. In this session, I will demonstrate how to create a product backlog and manage Scrum fundamentals using Trello, specifically for a bike club website project. After signing up for a free Trello account, I’ll create a new workspace and invite team members using their corporate email addresses. We'll set up our board with essential columns such as Product Backlog, Sprint Backlog, To Do, In Progress, and Done. Each requirement will be added as a card, complete with user stories, definitions of done, and color-coded labels for epics to enhance clarity and organization. This approach allows for quick adjustments to requirements and ensures transparency, as team members can track progress through the checklist feature. By refining and decomposing tasks throughout the sprint events, teams can adaptively build the product without needing to finalize every detail upfront. Additionally, as a certified Scrum Master, I emphasize the importance of iterative development and continual inspection and adaptation to meet project goals effectively.

In our first backlog refinement session, we’ll focus on preparing for the initial sprint by examining a variety of tickets, particularly prioritizing those that will drive our early work. Not every ticket requires immediate attention; instead, we should concentrate on high-priority items to ensure we can start the sprint effectively. It’s essential to consider dependencies, such as selecting the website's architecture and hosting platform, before diving into the build process. Design efforts should align with the company’s branding guidelines, allowing our designer, Amy, to begin sketching out the website layout. The developers will collaborate to finalize the website architecture, while Josh, our marketing expert, will assist Amy in designing promotional materials. As we identify additional tasks during this brainstorming phase, we'll refine our backlog further. One of the key tasks will be to gather the company's branding rules, ensuring they are documented and accessible for the team, which will help us maintain consistency across our design efforts. This task will involve working with the marketing department to obtain existing guidelines or creating new ones if necessary. We’ll also engage with senior management for final approval. In terms of user stories, we'll emphasize user perspectives, focusing on the need for a stable and secure website that users can navigate easily. Each task will include a "definition of done," which outlines necessary steps for completion, such as producing an architecture document, selecting technology stacks, and ensuring user testing is incorporated into the development process. User-friendly design is crucial, necessitating the creation of a user group to gather feedback and validate that our designs meet user expectations. This collaborative approach, involving contributions from the entire scrum team, will help us refine our definitions of done over time, improving our overall ticket quality and ensuring we align with the standards of our organization as we progress.

The decision matrix is a powerful tool for making informed choices by evaluating and prioritizing alternatives based on predefined criteria, making it particularly useful for complex decisions involving multiple factors. To use a decision matrix, first identify the criteria relevant to your decision, such as cost, user-friendliness, features, and customer support. Next, assign weights to each criterion based on its importance, then list the alternatives you’re considering. After that, score each alternative against the criteria using a numerical scale, and calculate the total scores by multiplying the scores by the assigned weights. Finally, select the alternative with the highest total score as the most favorable option. For instance, in choosing project management software, you might weigh cost at 30%, user-friendliness at 25%, features at 30%, and customer support at 15%. By engaging your team in this structured approach, you not only make a logical decision but also demonstrate your skills as a certified Scrum Master in facilitating collaborative decision-making processes.

The sprint backlog is akin to the product backlog but owned by developers, serving as a plan for them during the sprint. It's a dynamic list updated throughout the sprint, ensuring tasks have enough detail for daily scrums. Comprising the sprint goal, selected items, and delivery plan, it's crucial for achieving sprint objectives. Developers commit to the sprint goal, which is set during sprint planning, allowing flexibility in execution. The goal fosters coherence, focus, and teamwork, aiding in scope negotiation within the sprint. Only the product owner can cancel a sprint if the goal becomes obsolete. With the product backlog refined, the sprint planning session is imminent, marking the next step in the Scrum process.

This lecture discusses increments, and essential steps toward the product goal, such as adding a blog section or online ordering system in website development. Each sprint should produce an increment, with Scrum 2020 allowing for multiple increments to be presented to stakeholders before the sprint review, preventing bottlenecks. Increments must be additive and thoroughly tested for compatibility within the larger product. The "Definition of Done" formalizes quality standards, ensuring transparency among team members. Items that do not meet this definition cannot be shown at the sprint review and must return to the product backlog. Organizations may have minimum standards, including testing and branding guidelines; if not, the Scrum team must establish their own. Multiple Scrum teams working on the same product need a unified definition of done. Once developers meet this definition, an increment is ready for stakeholder presentation and potential user release, without waiting for the sprint review.

Establishing a clear "definition of done" for the increment is vital for ensuring transparency and maintaining standards in the Scrum process. It sets clear guidelines that must be met before an increment can be considered complete. The definition of done should be clear, testable, measurable, concise, and realistic. Obtaining input from relevant departments or personnel in the organization can help establish appropriate standards. The definition of done checklist typically includes testable criteria such as meeting style guides, optimizing images for the web, peer code reviews, integration testing, user testing, accessibility standards, performance testing, and adequate documentation. Non-functional requirements such as user-friendliness, security, performance, and design considerations should also be incorporated into the definition of done. Metrics and key performance indicators (KPIs) can be used to monitor and evaluate the performance of the increment against these criteria. Regular reflection and refinement of the definition of done, along with input from stakeholders and peers, can help improve the quality of increments over time.

This lecture discusses the final stages of a sprint, emphasizing the importance of verifying that the created increment—such as a "Coming Soon" page—meets the standards outlined in the definition of done. A checklist is utilized to ensure all criteria are met, including performance metrics like visitor counts and user sign-ups. The lecture also highlights the value of standardizing the definition of done for future increments and potentially creating a template for efficiency. Ultimately, while the development team ensures the increment is ready, the decision to release it to users rests with the product owner, reinforcing the importance of adherence to quality standards and strategic timing in product management.