Agile Product Delivery Fundamentals with Generative AI

Before your team can run sprints or manage a backlog, you need to understand the foundation every Agile practitioner builds on — the difference between Agile and Waterfall. In this lesson, you'll explore two fundamentally different ways of delivering products: the sequential, plan-heavy approach of Waterfall and the iterative, feedback-driven world of Agile. You'll learn where each methodology came from, why Agile was created, and — critically — when each approach actually makes sense. By the end, you'll have the conceptual foundation needed to make smart delivery decisions throughout this entire program.

Every product your team will ever build follows the same path, from the spark of an idea to the moment real users interact with it in production. In this lesson, you’ll walk through the seven phases of the Software Development Lifecycle (SDLC): Planning, Requirements, Design, Development, Testing, Deployment, and Maintenance & Feedback. You’ll learn what happens in each phase, why it matters, and critically how Agile fits inside the SDLC as a series of fast, repeating mini-cycles. By the end, you’ll have the full picture of how products get built.

Agile doesn’t just change how work gets done, it changes who does what. In this lesson, you’ll meet the three Scrum roles at the heart of every Agile team: the Product Owner, the Scrum Master, and the Developer. You’ll learn what each role owns, what it looks like in practice, and critically, how all three work together to deliver value every sprint. By the end, you’ll understand why Scrum distributes accountability across three distinct roles instead of concentrating it in a single project manager.

AI isn't replacing Scrum roles — it's raising the bar for what those roles must become. In this lesson, you'll see exactly how each Scrum role is evolving in the age of AI, what tasks are being automated, and where your irreplaceable human skills create your competitive edge. You'll be introduced to a concept that runs through this entire course: your Human Moat — the coaching, facilitation, and judgment that no tool can replicate. By the end, you'll know what it means to be an AI-era practitioner and how this course is designed to build both your Agile foundation and your AI literacy at the same time.

Every Agile sprint runs on a rhythm — a set of recurring events that keep the team aligned, moving, and improving. In this lesson, you’ll learn the four Scrum Events: Sprint Planning, the Daily Standup, the Sprint Review, and the Retrospective. You’ll understand what happens in each event, who participates, how long it runs, and — most importantly — what breaks down when any one of them is skipped or done poorly. By the end, you’ll have the full sprint rhythm in your hands and know exactly how to use it.

AI is already showing up in your Scrum ceremonies. Most teams just don't have a workflow for it yet. In this lesson, you'll get a clear map of exactly where AI helps inside Sprint Planning, the Daily Standup, Backlog Refinement, the Sprint Review, and the Retrospective. You'll see what each tool handles, what the human must still own, and the one principle that governs how AI and Agile work together. By the end, you'll know how to use AI to make every ceremony sharper, without losing what makes them valuable.

Speed without visibility is chaos. Scrum Artifacts are the tangible outputs that make your team’s work, plan, and progress visible at all times to the team and stakeholders. In this lesson, you’ll learn the three Scrum Artifacts: the Product Backlog, the Sprint Backlog, and the Increment. You’ll discover what each one contains, who owns it, and the commitment paired with it — the Product Goal, the Sprint Goal, and the Definition of Done. By the end, you’ll understand how these three artifacts connect into a continuous loop of visibility, commitment, and delivery.

You’ve learned the Scrum roles, the events, and the artifacts. Now it’s time to see how they all move together. In this lesson, you’ll follow a piece of work from the moment it enters the Product Backlog to the moment it reaches real users — tracing every stage of the Agile delivery flow. You’ll learn what happens during planning, development, testing, CI/CD, release, and the feedback loop that starts the next sprint. By the end, you’ll have a complete mental map of how Agile teams deliver working software, sprint after sprint.

You've built the foundation. Now let's reframe it for the world you're actually delivering in. In this closing lesson of Module 1, you'll see what Agile principles are permanent and what has genuinely changed in 2026. You'll understand the three-layer AI-era delivery stack, the five biggest shifts in how teams plan, run ceremonies, and measure outcomes, and the three mindset changes that separate good practitioners from great ones. By the end, you'll be ready to carry everything you've learned directly into Module 2.

Every product starts with a problem. But most teams skip the hardest part: defining that problem clearly before they start building. In Part 1 of this lesson, you'll learn the discipline of problem framing, a structured approach to identifying exactly what is broken, who it affects, why it matters, and what a solved state looks like. You'll work through four key tools: the four-component problem statement, the 5 Whys technique for uncovering root causes, the As-Is vs. To-Be framework for mapping the gap your product needs to close, and a ready-to-use problem statement template. By the end, you'll have a complete, precise problem statement, the foundation that every sprint, every story, and every product decision will trace back to.

You'll take the problem statement you built in the last lesson and turn it into something your whole team can rally behind — a product vision. You'll learn what a product vision is, why it matters, and how it serves three critical functions: aligning the team, filtering decisions, and sustaining momentum across every sprint. Using a simple, repeatable formula, you'll write a vision statement that is specific, testable, and directly traceable back to the root cause you defined. By the end, you'll understand the most important principle in product planning: a great vision is not invented — it is derived from the problem.

Stakeholder Engagement Plan examines the theory and practice of stakeholder identification and engagement planning in Sprint Zero. The lesson distinguishes between internal and external stakeholders, and establishes the critical difference between one-directional communication and two-directional stakeholder engagement. Learners apply the interest versus influence mapping grid to categorize stakeholders into four quadrants — Manage Closely, Keep Satisfied, Keep Informed, and Monitor — each with a corresponding engagement strategy. The lesson presents a four-column engagement plan format (stakeholder, what they need, how to engage, when/cadence) and illustrates its application through worked examples. The lesson concludes by connecting the stakeholder engagement plan to the Project Scope document as a Sprint Zero input.

Risk Management introduces learners to the foundational discipline of identifying, assessing, and planning responses to delivery risks during Sprint Zero. The lesson covers four categories of risk — scope, resource, technical, and external — and presents the risk register as the primary working tool, structured around probability, impact, and response plan columns. Learners apply the probability and impact matrix to prioritize risk treatment and examine four response strategies: avoid, mitigate, transfer, and accept. The lesson concludes by establishing how the risk register feeds directly into the Project Scope document, shaping scope decisions and sprint planning before delivery begins.

Project Scope functions as the synthesis lesson for Sprint Zero, consolidating the outputs of Lessons 1 through 4 into a single structured document. Learners examine the eight-section Project Scope format, identify which sections derive from previous lessons, and complete the document by adding in scope and out of scope boundaries, constraints, and assumptions. The lesson distinguishes between the Project Scope as a planning artifact and as a living document — establishing that it is version one of a reference that will be revised as the team progresses through Module 3 (User Stories & Backlog Design). Common errors in scope documentation are examined, with emphasis on ambiguity, locked scope, and insufficient stakeholder review.

Five earlier lectures built a problem statement, a vision, a stakeholder map, a set of assumptions and constraints, and a defined scope. This lecture teaches nothing new. It teaches assembly: how those five pieces combine into a project charter, the one-page agreement a sponsor actually signs before real work begins. Using the SmartStock scenario at VitaLink Medical Supply Co., students see a complete charter built from work they already did, then assemble their own from their own earlier lectures. Covers what a charter is and isn't, why an out-of-scope list protects a project as much as the in-scope list, and what happens when a charter gets skipped. The resulting document becomes the first artifact in the Sprint Zero Readiness portfolio.

A charter defines what a project is. A roadmap decides how the work gets sequenced over time, without pretending to promise dates it can't keep. This lecture teaches the roadmap hierarchy, vision, themes, epics, and releases, then builds a real SmartStock roadmap with a deliberate choice: Sprint 0 and Sprint 1 get planned in genuine detail, while everything further out is shown honestly as a collapsed, sequenced but undetailed bar. Covers the two habits that quietly ruin a roadmap, treating it as a fixed contract and over-planning sprints months away, and how a roadmap flexes as a team learns without turning into chaos. Ends with students building their own roadmap for their Sprint Zero Readiness portfolio.

By this point in Planning, a real vision, scope, and roadmap already exist, and each one felt solid the moment it was written. This lesson tests that feeling. It teaches how to use AI to pressure-test all three at once, checking whether the vision actually serves every stakeholder, whether the MVP scope has a gap nobody caught, and whether the roadmap's sequencing genuinely holds up. Students learn the upload-based workflow real teams use: genericize the documents, upload the Charter, Stakeholder Map, and Roadmap together, and read AI's findings with a critical eye. It closes with the same boundary held throughout the course: AI pressure-tests, the Product Owner decides. No code required.

Sprint Zero Readiness Package, Part 1: Planning Playbook Assignment

In this assignment, you will begin building your Sprint Zero Readiness Package by completing the Planning section of your Playbook Assignment.

Before You Begin

Download the following course resources:

• Capstone Case Study: the business scenario, problem, product context, and information you will use throughout the capstone.

• Planning Playbook: one working document containing all four deliverables for this section, in the order you should complete them, along with the AI pressure test process.

Read the Capstone Case Study before beginning. Use it, along with what you learned in this section, to complete the Planning activities.

What You Will Create

The Planning Playbook is a single document, four sections built in order, each one depending on the section before it:

1. Project Charter: the business problem, product vision, objectives, high-level scope, key stakeholders, assumptions, constraints, and dependencies.

2. Stakeholder Map: the people and groups who influence, support, use, or are affected by the product, with their role, interest, influence, and engagement needs.

3. Product Roadmap: how the product may evolve over time, with real detail close in and later work honestly collapsed rather than guessed at.

4. AI Pressure Test Log: upload all three completed deliverables together, run the pressure test prompt provided, and record what AI finds and what you decide to change.

Work through the Playbook front to back. Each section tells you exactly which earlier section to pull from.

Your Goal

By the end of this assignment, you should be able to clearly explain:

• Why the project exists

• What the product is intended to accomplish

• Who needs to be involved

• What is inside and outside the project boundaries

• What factors could affect the plan

• Where the product is headed at a high level

Complete and save your Planning Playbook. You will continue building on these deliverables as you move through the remaining SDLC phases and complete your full Sprint Zero Readiness Package.

Before writing a single requirement, learn how to identify who actually needs to be interviewed, ask questions that surface real evidence instead of leading answers, and turn raw notes into a persona built on fact rather than assumption.

In this lesson, you’ll take everything produced in your stakeholder interviews and discovery sessions and arrange it into a story map — a two-axis visual that restores the user’s journey to the backlog. You’ll learn how to build the three core layers, draw a release slice that commits the team to a scope, and produce the Use Case and Workflow Diagrams that feed the map.

In this lesson, you’ll learn how to prioritize Epics and Features using three explicit criteria — Business Value, Risk, and Dependencies — and apply two practical frameworks: MoSCoW for scope decisions and Value vs. Effort for sequencing. You’ll define a release boundary, document what’s deferred and why, and walk away with a prioritized backlog that the whole team can read and act on.

This lesson introduces two foundational scope-definition frameworks — the Minimum Viable Product (MVP) and the Minimum Marketable Product (MMP) — and establishes the critical distinction between them. Students will learn that while both frameworks apply the concept of minimization to product scope, they serve categorically different purposes: the MVP is a learning mechanism designed to validate a key product assumption with real users at minimal cost, while the MMP is a release milestone representing the smallest complete product that delivers sufficient value to satisfy a real customer.

Every piece of work in a sprint traces back to a user story. This lesson teaches you how to write them well. You’ll learn the three-part formula — As a / I want / So that — and how to write each component precisely: a named user, a single user-facing behavior, and a testable outcome. You’ll work through stories at four quality levels, identify the most common mistakes, and see how the outcome you write here becomes the source of your acceptance criteria in Lesson 6.

This lesson addresses one of the most critical — and most commonly neglected — practices in Agile product delivery: writing acceptance criteria (AC) before development begins. Students will learn to define the conditions a user story must satisfy to be considered complete, moving beyond vague story descriptions toward precise, verifiable behavioral specifications.

The lesson introduces the Given / When / Then (GWT) behavioral specification format, originating from Behavior-Driven Development (BDD), as the primary AC authoring method. Students apply the format to three distinct SmartStock feature areas — inventory alerting, order processing, and reporting — developing fluency with scenario construction across multiple functional domains.

This lesson introduces INVEST — a six-criteria quality framework developed by Bill Wake — as the primary instrument for evaluating user story readiness prior to sprint planning. Students will learn to apply each criterion (Independent, Negotiable, Valuable, Estimable, Small, Testable) to individual stories and use the framework as a structured pre-sprint quality gate during backlog refinement.

The lesson grounds each criterion in SmartStock user stories, presenting weak and sprint-ready versions side by side to illustrate specific failure modes and their corrections. A diagnostic decision framework is introduced: stories that satisfy all six criteria enter sprint planning; single failures are refined in-session; two or more failures return the story to the backlog.

By this point in Requirements, a Persona, a Workflow, a Story Map, a Backlog, and a set of User Stories all exist, and each one felt solid the moment it was written. This lesson teaches three moves for reviewing that work with AI: refining vague language into something precise, challenging entries to see whether they trace back to real evidence or just sound reasonable, and improving the documents by deciding what actually gets changed. Students use the same upload workflow built into their Requirements Playbook, all five documents together, one instruction, checking for gaps and contradictions across the set. It closes on the same boundary held throughout the course: AI refines and challenges, the person doing the work decides what improves.

This lesson introduces story points as the Agile standard for relative estimation and explains why hour-based estimates consistently underperform in team settings. Learners will understand the three dimensions that story points capture — effort, complexity, and risk — and see how the Fibonacci sequence structures those dimensions into a scale that forces meaningful size distinctions.

The lesson covers Planning Poker as the team practice that converts individual estimates into consensus, with particular focus on simultaneous card reveal as a mechanism for eliminating anchoring bias. Velocity is introduced as the output of estimation in practice — the historical data a team uses to determine what realistically fits in a sprint.

Applied examples use stories from the SmartStock AI Inventory Platform backlog, progressing from a simple read operation to a complex routing story that demonstrates when decomposition is required before planning begins. Common estimation pitfalls are addressed with specific symptoms and fixes.

Velocity tells a team what they have delivered. Capacity tells them what they can deliver this sprint. Most teams know the first number and skip the second and that is where sprint overcommitment begins.

This lesson teaches you how to calculate team capacity before sprint planning: counting available days, applying a realistic focus factor, converting to story points, and summing across every contributor.

You will also learn the six most common capacity reduction factors that change sprint to sprint, the three overcommitment failure modes teams fall into when they skip capacity planning, and exactly how capacity calculation fits into the sprint planning ceremony for each role.

Sprint Planning is the ceremony where estimation and capacity planning converge into a concrete team commitment. In this lesson, learners move from knowing how to size work and calculate capacity to running — or participating in — the Sprint Planning event itself. The lesson covers the full structure of Sprint Planning as defined by the Scrum Guide, including its two distinct parts, the sprint goal, story selection, task breakdown, and the specific roles the Scrum Master and Product Owner play throughout.

Every team has norms. The question is whether those norms are explicit or implicit. Implicit norms — the unspoken assumptions about how a team communicates, makes decisions, handles conflict, and approaches quality — cannot be challenged, updated, or enforced, because nobody ever agreed to them. Working agreements are the mechanism for making norms explicit. They are the team’s documented, team-created operating commitments: specific, behavioral, and owned by everyone who agreed to them.

This lesson covers what working agreements are and what distinguishes them from performance rules or management directives, why Agile teams need explicit agreements more than most teams do, the six categories of agreements that cover the full surface area of team operations, how to write agreements specific enough to actually change behavior, the collaborative process for creating them during Sprint Zero, how they function in daily sprint practice, and the Scrum Master’s role in creating, maintaining, and keeping them alive.

Sprint Planning committed the team to a set of stories. But commitment only has value when the team has a shared understanding of what "done" actually means. The Definition of Done — the DoD — is that shared understanding. It is a formal, team-owned checklist of criteria that every user story must satisfy before it can be marked complete and accepted into the product.

This lesson covers what the DoD is, why it exists, how it differs from acceptance criteria, what a complete DoD contains, how to build one as a team, how to apply it sprint by sprint, what happens when stories do not meet it, and the Scrum Master’s role in creating, maintaining, and enforcing it.

By this point in Sprint Planning, a Capacity Plan, a Sprint Plan, and a Definition of Done all exist, each one reasoned through carefully on its own. This short lesson teaches one pressure test with three closed questions: does the sprint commitment fit the team's capacity, does every backlog item serve the sprint goal, and does Done here match the standard already set in Requirements. Students learn why a narrow, closed-question prompt works better than an open one for this kind of check, and why the Team Working Agreement stays deliberately untested by AI, since culture isn't a calculation. It closes on the same boundary held throughout the course: AI checks the math, the team owns the commitment.

Agile teams get accused of skipping design. They do not skip it, they distribute it. In this lesson you will see where design actually lives inside the sprint cycle, why design work runs one sprint ahead of development, and what "ready for dev" really requires before a developer picks up a story. We cover the four design artifacts every Agile team should know, the common tensions between design and delivery pace, and the Scrum Master's role in protecting both tracks. By the end you will understand design as continuous risk reduction rather than a phase that slows the team down.

A written story tells the team what a user needs. A user flow and a wireframe let the team see it before anyone builds it. In this lesson you will follow one SmartStock story from words to visuals: breaking the story into the user, the goal, and the reason, mapping the happy path step by step, then hunting the error and alternate paths where most rework hides. You will see a low fidelity wireframe built from that flow, and learn the two minute check that connects ever

A screen design answers what the user sees. It does not answer where the data lives, who is allowed to change it, or what happens when a service goes down. In this lesson you will see both halves of the same SmartStock feature: the screens the analyst touches, and the six decisions that run behind them when the analyst clicks save. You will learn where the two sides shape each other, why a promise made on a screen must be kept by the system, and four questions any teammate can bring to refinement without writing a line of code.

AI will not replace design judgment, but it will get you to a reviewable draft in minutes instead of days. This hands-on lesson walks through a five step workflow: give AI the full context from your story and acceptance criteria, review the flow it returns, request a wireframe or working prototype, ask AI to critique its own output through four professional lenses, then run the human review that decides what gets built. You get two copy-ready prompts, a review checklist, and a data hygiene rule for keeping internal product names out of public AI tools.

This lesson introduces learners to the mechanics of sprint board management and task flow in Agile delivery. Learners explore the five column states of a sprint board — To Do, In Progress, In Review, Testing, and Done — and learn what each state means, what healthy flow looks like, and what diagnostic signals indicate a flow problem. The lesson covers WIP (Work in Progress) limits and why constraining simultaneous work increases throughput. Learners also examine the most common flow blockers in a sprint and learn which role owns resolution for each blocker type. The lesson concludes with a role-by-role breakdown of each team member's board responsibilities and a live read of the SmartStock sprint board.

This lesson covers the daily standup as a Scrum ceremony — its purpose, structure, and facilitation. Learners explore the three standup questions (What did I complete? What am I working on today? What's blocking me?) and learn how each answer connects to board state rather than personal activity. The lesson covers five things the standup is not — including a status report, a problem-solving session, and a progress report on individuals — along with the observable signals that indicate each misuse pattern. Six anti-patterns are examined in depth with specific Scrum Master intervention techniques for each. The lesson concludes with a minute-by-minute standup playbook and a VitaLink SmartStock standup simulation, with guidance on remote and hybrid standup adaptations.

A developer says the feature is finished. Two days later the card has still not moved, and the reason is rarely visible from the outside. This lesson walks the gates that sit between finished code and finished work: the repository that holds every change, the teammate who reviews it, and the automated checks that build and test it. Along the way the Scrum Master and Product Owner learn why acceptance criteria become the reviewer's checklist, why small frequent changes fail more cheaply than large ones, and what technical debt actually costs a team on every future change. No code, no tooling required.

AI now touches the sprint board, the standup, the review gate, and the debt conversation. This lesson gives Scrum Masters and Product Owners a frame that outlives any particular tool: AI summarizes, suggests, and flags, and the moment it appears to decide, a person handed over that authority. Along the way it covers where AI genuinely helps, why a summarized standup can quietly lose the blocker a teammate would have caught, how AI turns technical debt from an opinion into evidence a backlog conversation can use, and the four guardrails that belong in place before a tool arrives. No code required.

This lesson teaches the planning layer that sits between knowing what to test and actually testing it. Most teams skip this layer — they write test cases the day code arrives and wonder why QA always runs out of time. Test Plans, Test Scenarios & Test Coverage establishes the three-level structure every sprint needs: a test plan as the strategy, test scenarios as the meaningful user situations that drive coverage, and test cases as the executable checks derived from those scenarios. Using the SmartStock low-stock alert story, learners build a complete Sprint 1 test plan — six scenarios typed as functional, exploratory, or regression, each prioritized P1 through P3 — before any development work begins. The lesson closes with the timing principle that determines whether the test plan actually shapes the sprint: build it before Day 3, not after code arrives.

This lesson redefines the QA role in an Agile delivery team — moving it from a final gate at the end of the sprint to an embedded, collaborative practice that starts at story creation. Learners will understand the shift-left testing model, the three testing types every delivery team needs (functional, regression, and exploratory), and how QA analysts and developers collaborate across every sprint phase. Using the SmartStock AI inventory platform at VitaLink Medical Supply Co., the lesson demonstrates what testable acceptance criteria look like in practice and why the absence of QA early in the sprint creates the end-of-sprint testing crunch that most teams mistake for a capacity problem. The lesson closes with four QA anti-patterns that slow delivery and the mindset shift that prevents them.

User Acceptance Testing (UAT) is the final validation gate between your sprint and production. This lesson defines what UAT actually is, who runs it, and when it happens — and makes a critical distinction: UAT validates whether the software works for the people who need to use it, not whether the software works correctly. A feature can pass every QA test and still fail UAT. This lesson shows why, using the SmartStock inventory alert scenario to demonstrate the difference between functional correctness and real-world fit. Learners will understand how to structure a UAT session, who the right participants are, how UAT relates to Sprint Review, and what UAT anti-patterns create last-minute delivery surprises.

Most Agile teams know how to run a Sprint Review. Very few understand what it is for. The Sprint Review is not a demonstration event — it is an inspect-and-adapt event. Its purpose is to examine what was built, surface what the team learned, collect stakeholder input on what the product needs next, and update the backlog based on that conversation. When teams conflate the demonstration with the purpose, they produce well-organized meetings that leave the backlog unchanged and stakeholders with no new questions. This lesson defines what the Sprint Review actually is, teaches the five-element structure that makes it work, demonstrates what a productive SmartStock Sprint 1 review looks like in practice, and identifies the four anti-patterns that convert the Sprint Review into a status update nobody needed.

Testing has always been rationed by time. There was never enough of it to write every scenario a product deserved, so teams tested what they could reach and hoped the gaps were harmless. This lesson shows Scrum Masters, Product Owners, and business analysts how AI removes that rationing: drafting test scenarios in minutes, expanding coverage past what a tired team catches, and auditing an existing plan for what it missed. It also draws the line that does not move. Choosing which risks matter stays with the Product Owner. Acceptance in UAT stays a human signature. Includes two copy-ready prompts: one that generates a test plan from a story's acceptance criteria, and one that reviews an existing plan from four professional perspectives. No code required.

Sprint Zero Readiness Package, Part 6: Testing Playbook Assignment

In this assignment, you will continue building your Sprint Zero Readiness Package by completing the Testing section of your Playbook Assignment.

Before You Begin

Download the following course resource:

• Testing Playbook: one working document containing all four deliverables for this section, in the order you should complete them, along with the AI pressure test process.

Keep your Requirements Playbook, Sprint Planning Playbook, and Design Playbook open. This workbook tests the stories, flows, and commitments you already built. Nothing new gets designed here.

What You Will Create

The Testing Playbook is a single document, four sections built in order:

1. Test Scenarios and Coverage: for two or three of your stories, write scenarios covering the happy path, an edge case, and an error case for every acceptance criterion, then reflect on which scenarios would have been easier to catch if QA had been in the room when the story was first written.

2. UAT Script and Sign Off: a plain language walkthrough script written for a real business user, not a tester, with a sign off field to record whether it passed.

3. Sprint Review Talking Points: what gets demonstrated, the value story behind it, and prepared answers to the stakeholder questions most likely to come up.

4. AI Pressure Test Log: upload your Test Scenarios and UAT Script together, run the pressure test prompt provided, and record what AI finds and what you decide to change.

Work through the Playbook front to back. Everything stays inside this one document, there is no separate tool to learn in this section.

Your Goal

By the end of this assignment, you should be able to clearly explain:

• What it actually means for a story to have full test coverage, not just a passing test

• Why the happy path is never the whole test, and what an edge case and an error case each protect against

• How to write instructions a non-tester could follow to validate a feature themselves

• Why demonstrating a feature in a review and knowing it delivers real value are two different claims

Complete and save your Testing Playbook. You will continue building on these deliverables as you move through the remaining SDLC phases and complete your full Sprint Zero Readiness Package.

Most Agile teams know how to run a sprint. Far fewer know how to run a release. In this lesson, you will learn what separates a sprint from a release, who owns the release decision, and what a release planning meeting actually looks like from start to finish. You will walk through the VitaLink SmartStack scenario as the team prepares for their first production release — navigating scope decisions, QA sign-off, stakeholder approval, and an open dependency that puts the timeline at risk. By the end of this lesson, you will have a release planning meeting agenda, a readiness checklist you can use immediately, and a clear understanding of the four process failures that cause most release incidents.

Your team can finish every story in a sprint and still ship to production with no monitoring configured, no rollback plan documented, and no one briefed on what changed. That is not a code problem — it is a readiness problem. In this lesson you will learn the difference between sprint done and release ready, and walk through the five dimensions of launch readiness: Technical, QA, Stakeholder, Operational, and Communication. You will see how the VitaLink team ran the readiness check before their Sprint 3 release planning meeting — finding two action items and one at-risk dimension they would have missed entirely. You will leave with a 10-item pre-release checklist your team can run before every deployment.

The code has passed every review and every test. It is not in front of users yet, and that gap is where deployment risk lives. This lesson gives Scrum Masters and Product Owners a plain language understanding of how finished work reaches real users safely: blue green, canary, and feature flags, three different ways to control how many people are exposed to a change and how fast a problem gets caught. It walks one feature through all three approaches, shows what actually happens during a release window, and names who is watching and why. Closes with four questions any team member can ask before a release goes out, regardless of technical background. No commands, no configuration, no tooling names.

Every team that ships software will eventually need to roll something back. The teams that handle it well are not the ones with the best engineers — they are the ones with a plan documented before anything broke. In this lesson you will learn the three reasons rollbacks fail before they even start, the six elements every rollback plan must contain, and how to define a rollback trigger that removes the judgment call from the moment of maximum pressure. You will walk through the complete VitaLink rollback plan for SmartStack Sprint 3, learn how to assess release risk across four factors before every deployment, and get a framework for making the rollback call quickly when something breaks in production.

By now a pattern should feel familiar: AI notices faster, and a person still decides what the noticing means. This lesson closes the loop for deployment. It covers how AI forecasts release readiness from sprint data days before the sprint ends, how it flags risk signals during a live release faster than a person watching a dashboard alone, and how it drafts release notes and stakeholder summaries in minutes instead of an afternoon. It is equally clear about the limits: a forecast cannot see the vendor delay nobody logged, and a draft cannot know what a specific stakeholder needs softened.

In this lesson, you will learn what to watch — and how to watch it — after your product ships to production. The release is closed. The risk window is open. This lesson walks you through the four signal categories every Agile team monitors after go-live, how to structure a monitoring window with a named watcher and defined close condition, and how to distinguish between an automated alert and a human decision. Using the VitaLink SmartStock case study, you will see a real 90-minute monitoring window in action — including how the team handles a brief signal elevation without panicking or rolling back unnecessarily.

In this lesson, you will learn how to handle bugs and unplanned work without abandoning your sprint goal. Unplanned work arrives in every sprint — the difference between teams that absorb it and teams that derail is whether they have a system. This lesson covers a three-tier triage framework for classifying incoming bugs, how to build the right capacity buffer before the sprint starts, and how to track unplanned work so it feeds your retrospectives instead of disappearing. Using the VitaLink SmartStock case study, you will see a real mid-sprint bug handled from report to resolution — with the sprint goal delivered in full.

In this lesson, you will learn how to build a structured system for collecting, classifying, and acting on user feedback after each release. Feedback arrives through four channels — support tickets, sprint review sessions, direct interviews and surveys, and account team input — and most of it disappears without a system to capture it. This lesson covers the three-step sequence for moving raw feedback into the backlog, how to close the loop with users on every item, and the consistent rhythm a Product Owner needs to stay ahead of user needs sprint over sprint. The VitaLink SmartStock case study shows how cross-channel pattern recognition surfaces insights that no single piece of feedback reveals on its own.

In this lesson, you will learn how to run a retrospective that is built for the maintenance phase — where the team is in production, unplanned work is a regular reality, and user feedback is actively arriving. The format is the same as any other retrospective. What changes is the data the team brings and the questions they answer. This lesson covers the four data sources that should be prepared before every maintenance retro, the five questions that surface what actually happened, and the one commitment rule that ensures something actually changes. The VitaLink SmartStock case study walks through a complete Sprint 4 retrospective from data to decision.

In this lesson, you will learn the six Agile metrics every team should track in the maintenance phase — and how to use each one to make better decisions. The first three belong to the whole team: velocity measures delivery capacity, the burndown reveals mid-sprint risk, and cycle time shows where work slows in the workflow. The next three belong specifically to the Scrum Master: sprint goal achievement rate tracks delivery reliability, unplanned work ratio monitors interruption discipline, and the Cumulative Flow Diagram surfaces bottlenecks before they become blockers. Using the VitaLink SmartStock case study across four sprints, you will see how all six metrics work together to confirm patterns and support decisions — not to evaluate people.

By this point in Maintenance, a bug triage process, an unplanned work log, a retrospective, and a set of metrics all exist as real, repeated work. This lesson covers where AI genuinely helps with that repetition: drafting a first pass triage classification, surfacing patterns across sprints a single sprint view cannot show, preparing retrospective data so the Scrum Master stays in the room instead of in the notes, and reading metrics faster than a manual comparison ever could. It closes on the same boundary held throughout the course: AI drafts, flags, and summarizes, but priority and commitment decisions stay with a person.