Scrum Project Management

This Scrum project management training equips team members and managers to apply Scrum roles, events, and artifacts to deliver projects iteratively and improve team collaboration.

My workspace26 minFree to watchDownloads

What you’ll learn

01Scrum Project Management: Overview and Business ContextWelcome. Over the next several sessions, we will work through Scrum as a delivery framework, and focus on what you, as accountable professionals, actually do with it. Our promise is practical. You will run events with purpose, refine backlogs deliberately, and forecast probabilistically, using trends rather than single data points. Now, why this matters today. Eighty-four percent of organizations now use AI in delivery, yet only forty-nine percent have governance guardrails in place. So adoption is outpacing oversight. Keep one point clear as we go. Scrum is a framework for complex products, not a governance replacement. It defines accountabilities, events, and artifacts, and the rules that bind them. It does not replace your audit, risk, or control obligations. In the room, we have project managers, Scrum Masters, product owners, delivery leads, and team members, and the tension we need to resolve is real. Fixed scope, auditability, and distributed teams pushing against empiricism. In practice, this means a delivery lead may hold a fixed compliance date, while the product owner still adjusts backlog order each Sprint. Both can be true. Here is our agenda. Foundations, accountabilities, events, metrics, scaling, adoption, and a simulation. Start with the foundations, because the rest builds on them. Next, we move from predictive to empirical, and look at matching your approach to context.scrumguides.org scrumguides.org scrumguides.org+22 min
02From Predictive to Empirical: Matching Approach to ContextLet's look at how context should shape your approach. Cynefin gives us five domains. Clear and Complicated are ordered, meaning analysis works before action. For example, an infrastructure upgrade with known requirements is Complicated. You bring in experts, analyze, and plan. Complex and Chaotic are unordered, where cause and effect only become clear in retrospect. Launching a new product is Complex. You probe with small experiments, sense what happens, and respond. The practical rule is simple. Match your response to the domain. Categorize in Clear, analyze in Complicated, probe in Complex, and act in Chaotic. Confused programs, where parts of the work feel different, need to be decomposed into separate workstreams, each managed in its proper domain. Start by asking which domain your current workstream truly belongs to. That tells you whether to plan or to probe. Next, we will look at the accountabilities that support this in Scrum: Product Owner, Scrum Master, and Developers.frameworklist.com pmstudycircle.com bvop.org+22 min
03Accountabilities: Product Owner, Scrum Master, and DevelopersLet's look at the three accountabilities in a Scrum Team, and where each one actually sits. Start with the Product Owner. The Product Owner maximizes value, orders the backlog, and can say no. In practice, this means when a stakeholder asks for one more feature mid-Sprint, the Product Owner decides whether it belongs in the backlog, not the Scrum Master. Next, the Scrum Master. The Scrum Master coaches team effectiveness. They remove impediments, facilitate events, and help the organization apply Scrum well. But they hold no delivery authority and no direct reports. No one on the team reports to the Scrum Master, and they cannot fire or assign work. Then the Developers. Developers are self-managing, and they collectively deliver a usable Increment every Sprint. Self-managing means the team decides how to do the work, not that anyone does whatever they like. Now, the practical distinction many of you will face. The Scrum Master coaches and enables. A project manager commits on scope, schedule, and budget. Those are different accountabilities, and someone must own each. Watch for three anti-patterns: a proxy Product Owner who lacks real decision rights, a part-time Scrum Master stretched across several teams, and command-and-control behavior dressed in Scrum titles. In many hybrid organizations, a delivery lead handles the commercial work while the Scrum Master protects the team. That can work well, but the boundaries must be explicit. So take one next step. Look at your own team and ask who owns each of these three accountabilities, and whether those boundaries are clear to everyone. Next, we turn to Scrum Events: Cadence, Purpose, and Facilitation.atlassian.com scrum.org projectmanagementformula.com+22 min
04Scrum Events: Cadence, Purpose, and FacilitationLet's look at the Scrum events and how they fit together. The Sprint is the container: one month or less, fixed length, and every other event happens inside it. Start with Sprint Planning. The product owner brings a clear Sprint Goal, and the team forecasts against real capacity, not wishful thinking. For a two-week sprint, that session is timeboxed to around four hours, and eight hours maximum for a month. In practice, this means confirming who is actually available before you commit. Next, the Daily Scrum. Fifteen minutes, for the Developers to inspect progress and adapt toward the Sprint Goal. It is a planning session, not a status report to the Scrum Master. Then the Sprint Review, where you inspect the Increment with stakeholders and adapt the backlog. Treat it as a sign-off checkpoint. The Retrospective closes the sprint. Aim for one to three improvements, each with a named owner and a check-in date. Refinement runs continuously, not as a single event. One note: the November 2020 Scrum Guide remains the current official version, so keep that as your reference. For remote teams, prepare asynchronously twenty-four to forty-eight hours ahead, and rotate meeting times so the same people are not always joining at inconvenient hours. Artifacts and the Definition of Done.divim.io codelucky.com iworkfh.com+22 min
05Artifacts and the Definition of DoneNext, let's look at how artifacts connect to quality. In Scrum, three artifacts carry the work: the Product Backlog, the Sprint Backlog, and the Increment. The Product Backlog is your single ordered source of truth, refined continuously by value and risk. The Sprint Backlog belongs to the Developers and updates daily as they learn. The Increment is the usable, potentially releasable result of their work. Commitments bind each artifact to intent: the Product Goal, the Sprint Goal, and the Definition of Done. Keep the Definition of Done separate from acceptance criteria. The Definition of Done sets quality standards for all work. Acceptance criteria describe the functional needs of one story. Here is the decision rule. When a team creates its own Definition of Done, it correlates with high performance. Imposed checklists do not. So build it together, keep it to eight to twelve testable items, and never weaken it under deadline pressure. Finally, estimates must include Definition of Done work: review, testing, and deployment, not just coding. Start with one honest standard you can meet every sprint. That sets up our next topic: Estimation, Throughput, and Probabilistic Forecasting.2 min
06Estimation, Throughput, and Probabilistic ForecastingLet's turn to estimation and forecasting. Start with planning poker: everyone reveals at the same time, anonymously, which cuts anchoring bias. If one number is far off, the team discusses the work, not the person. Velocity is a forecast input, never a performance target. Treating it as a target invites inflated estimates. Then watch flow metrics. Throughput counts items finished. Cycle time measures work start to finish. Lead time starts at the request. WIP is work in progress. Work item age tells you how long an item has been open. As Daniel Vacanti puts it, no WIP limit means no flow, which means no predictability. For real forecasts, use Monte Carlo. It runs one thousand to ten thousand simulations from your historical data. Then read the percentiles: the fiftieth for internal planning, the eighty-fifth for commitments, the ninety-fifth for contractual dates. And keep your data clean. Use at least six sprints, twenty to thirty items, calendar days, and data under six months old. That foundation sets up our next topic: Scaling Scrum: Coordination Layers and Framework Choices.2 min
07Scaling Scrum: Coordination Layers and Framework ChoicesLet's look at scaling Scrum, and how to choose your coordination layers. The first rule is simple. Scale only for a real binding constraint. That means a constraint that is actually blocking delivery, such as heavy cross-team dependencies, a broken funding flow, or audit evidence your regulators require. If you cannot name it, you are not ready to scale. In practice, this means the framework matters less than the fit. SAFe is prescriptive and portfolio-aware. It suits eight or more teams in regulated enterprises, and it is the only one that directly addresses funding flow. LeSS is minimal. It fits two to eight teams on one product with one Product Owner and one backlog. Nexus sits in the middle, for three to nine teams on one product, adding a Nexus Integration Team to own integration. Here is a decision rule. If your problem is portfolio prioritization, look at SAFe. If it is integration across a few teams, look at Nexus or LeSS. Keep in mind that around seventy four percent of organizations run hybrid models, so context fit beats framework brand. Start with the smallest intervention that resolves your constraint, then review it each quarter. Next, we turn to governance, funding, and portfolio alignment.2 min
08Governance, Funding, and Portfolio AlignmentLet us turn to governance, funding, and portfolio alignment. Start with the core problem. Fixed-scope annual budgets create stop-start delivery and use-it-or-lose-it spending. In practice, this means a product owner may be forced to spend budget before year end rather than fund the highest-value work. The alternative is to fund value streams, not projects. Give a stable team a fixed capacity, and let priorities flex inside that budget as evidence changes. This is the heart of Lean Portfolio Management: value stream funding, Lean guardrails, and decentralized decisions. Cadence matters. Hold quarterly strategy and budget reviews, and monthly portfolio syncs with roadmap updates. Lean governance also automates compliance and builds audit evidence into delivery, so the Value Management Office is not chasing documents at the end. As a delivery lead, track flow efficiency, lead time, throughput, work in progress age, and unplanned work against your objectives and key results. Watch for this blocker pattern: agile teams with centralized project management office decisions and siloed budgets. That combination quietly stalls delivery. Next, we will look at the adoption roadmap: readiness, pilot, and expansion.2 min
09Adoption Roadmap: Readiness, Pilot, and ExpansionLet's walk through the adoption roadmap, from readiness to expansion. Start with diagnosis. Before adding any Scrum roles, identify your actual condition. Is the work genuinely complex, or is there a trust deficit? Are leaders giving contradictory mandates, or is uncertainty causing paralysis? The right response depends on the diagnosis. In practice, this means assessing readiness across five areas: culture, leadership, funding, structure, and technology. Then pilot two real value streams with an empowered Product Owner and real work. Not a sandbox. Real customers, real commitments. Beware of agile theater. New rituals layered over unchanged budgets and command-and-control decision rights change nothing. One fintech rolled out Scrum across three hundred engineers, yet prioritization still happened in a political committee, and delivery decisions bottlenecked in a central office. The ceremonies were flawless. Nothing moved faster. So fix funding, decision latency, and technical capability before you add coordination roles. The sequence matters. Next, we turn to evidence-based management and measuring outcomes, not activity.2 min
10Evidence-Based Management: Measuring Outcomes, Not ActivityNow let us look at Evidence-Based Management, and how we measure outcomes rather than activity. Start with the four Key Value Areas. Current Value measures what the product delivers today, like customer satisfaction, retention, and revenue per employee. Unrealized Value measures the potential you have not captured yet, like the satisfaction gap or the market gap. Ability to Innovate measures how well you can deliver new capabilities, through innovation rate and defect trends. And Time to Market measures how quickly you deliver and learn, through cycle time, lead time, and release frequency. Here is the critical point. Velocity and story points show capacity. They never show customer value. As a product owner or delivery lead, set goals in terms of customer outcomes, then inspect that evidence at the Sprint Review and the Retrospective. And consider this. Only about fifty-two percent of organizations can measure business outcomes effectively. That gap is your opportunity. In practice, this means choosing two or three outcome measures now, and reviewing them every sprint. Next, we will apply this in the Practice Lab: Simulating a Sprint Cycle.2 min
11Practice Lab: Simulating a Sprint CycleNow let us put the full cycle into practice. In this lab, you run Planning, Daily Scrum, Review, and Retrospective in one compressed sprint, and you role-play the friction that usually breaks them: bypassing a stakeholder, silent writers, and one dominant voice. Start with the backlog. Refine it, write one unifying Sprint Goal, and order items by cost of delay. Then estimate using an anonymous planning poker reveal, so no one anchors on the loudest estimate, and follow it with a Monte Carlo forecast at the fiftieth, eighty-fifth, and ninety-fifth percentiles. Use the eighty-fifth for commitments. Next, co-create a Definition of Done of eight to twelve items, and re-estimate one story with that DoD work included. In practice, this means coding, review, tests, and deployment all belong in the estimate. Close with a debrief. Each participant names one event-level change they will make next sprint. That single commitment is how the lab becomes real improvement. Next, we look at Career Paths, Certifications, and Sustained Improvement.divim.io codelucky.com iworkfh.com+22 min
12Career Paths, Certifications, and Sustained ImprovementNow let's talk about where your career goes from here. The 2026 role shift is clear: admin-heavy facilitation is shrinking, while hybrid delivery and coaching roles are expanding. If you are a Scrum Master, your leverage comes from three things: owning outcomes, fluency with AI tooling, and systems thinking. In practice, this means tying your coaching to a business metric, not just a cleaner board. On credentials, start with PSM or CSM. PSM needs no training, costs about two hundred dollars for one attempt, requires eighty five percent to pass, and is valid for life. CSM requires a two-day course, costs roughly one thousand to fourteen hundred dollars, requires seventy four percent to pass, and renews every two years. A sensible path is entry certification, then twelve to eighteen months of real practice, then advanced certifications, then coaching tiers. Remember, certification alone no longer differentiates you. Capability and results do. Let's move into your knowledge check, action planning, and next steps.atlassian.com scrum.org projectmanagementformula.com+22 min
13Knowledge Check, Action Planning, and Next StepsLet's close with a knowledge check, a plan, and your next steps. First, verify your footing across five domains. One, distinguish the accountabilities of the Product Owner, the Scrum Master, and the Developers. Two, match each artifact to its owner and its commitment. Three, classify the Cynefin situation, then pick the matching approach. Four, separate leading delivery metrics from outcome measures. Five, find the binding constraint and choose the lightest framework that fits. In practice, this means you decide, not just discuss. Individually, commit to one Sprint change, one metric to track, and one conversation with a leader. As a team, pick one improvement in event facilitation, Definition of Done or backlog hygiene, or a flow-measurement step. Set the cadence now. Review progress in your Retrospective, check your metric at thirty days, and hold a fuller review at sixty to ninety days. For reference, rely on the November 2020 Scrum Guide, the Scrum.org Evidence-Based Management resources, and community forums. Thank you for your attention and engagement throughout this course. Keep the changes small, keep inspecting, and keep improving. You are ready to lead the next step.scrumguides.org scrumguides.org scrumguides.org+22 min

Take the deck with you

Download this course as a file — free, no sign-up needed.

PDF handoutEvery slide page, ready to print or share.14 pages · 3.7 MBDownload
Narrated PowerPointThe deck that presents itself — every slide carries the digital human's narration video.14 pages · 27.5 MBDownload
PowerPoint slidesThe full deck as a .pptx — open it in PowerPoint, Keynote, or Google Slides.14 pages · 3.6 MBDownload

Free to use in your own training — please keep the PersonWise credit page at the end.

Have your own deck? Turn it into a course

Sources consulted

Web sources consulted while building this course.