Agile Intermediate Project Management: Plan Releases, Lead Teams & Measure Success

1. Introduction: Hello, and welcome to the Agile Project Management sprinting at scale Master Class. If you've already learned the fundamentals of Agile and Scrum, it's time to take the next step. In this class, we'll move beyond managing a single sprint and start thinking like an Agile project leader. My name is Luke Phillips. I'm a project manager with around seven years of experience leading Agile teams and delivering projects across a variety of industries. Throughout my career, I've worked with Scrum, Camban and hybrid Agile approaches to help teams collaborate more effectively, adapt to changing priorities and deliver value consistently. In this course, I'll share the practical techniques I've used to manage projects beyond the basics. We'll begin by looking at the bigger picture, how individual sprints fit into project roadmaps and release plans. You'll learn how to plan multiple sprints and organize longer term project goals using tools like No and then next we'll dive deeper into estimation and forecasting. You'll learn how Agile teams estimate work, measure velocity, and make realistic predictions without pretending that every estimate is perfectly accurate. We'll also compare Scrum, Cam Ban and hybrid approaches, helping you understand when each framework works best and how to adapt your workflow to different types of projects. Communication is another major focus of this course. You'll learn how to work with stakeholders, manage changing requirements, run productive reviews, and communicate project progress clearly and efficiently. Finally, we'll explore Agile metrics, understanding what to measure, what to ignore, and how to use data to improve your team's performance instead of simply generating reports. By the end of this class, you'll have the knowledge and the practical experience to manage larger Agile projects, communicate more effectively, and make better project decisions with confidence. Let's get started. 2. Welcome to the Intermediate Project Management Course : Hello, and welcome to the intermediate Agile project management course. If you've already run a sprint or two and you're ready to think beyond a single two week cycle, this course is for you. We'll cover how to plan across multiple sprints, how to estimate honestly at scale, when to reach for Cam Ban instead of Scrum, and how to keep stakeholders informed without drowning in status updates. In this short opening lesson, we'll go over what you should already know before starting this intermediate course, what this course covers and what you will need to follow. So a quick recap of what you should already know before you start this intermediate course. You need the foundations of the Agile mindset and Agile manifesto. If any of this feels unfamiliar, you'll want to shore up your basics before continuing. So you should understand the Agile mindset and the manifesto, not just be able to recite the values, but recognize them in how a team actually works. Should know the three Scrum roles, product owner, Scrum Master, and the development team, what each team does and what each team doesn't do. You should be comfortable writing user stories, defining acceptance criteria, and knowing when something is actually done. You should also have a Trello and Notion workspace already set up with a populated backlog for the project you're working on. And most importantly, you should have run at least one sprint end to end, planned it, executed it, reviewed it, and then ran a retrospective. Lived experience matters here because everything in this course builds on that foundation. So let's have a look at what this intermediate course covers. We have six sections. The shift is from one sprint to many sprints. We'll cover building release plans that link multiple sprints together. We'll look at estimating and tracking velocity properly. We'll look at the differences between Scrum and Caban and how to choose. We'll look at managing stakeholders without being eaten alive, and we'll look at the metrics that actually matter plus the ones that don't. So by the end of this course, you'll know how to plan and run a series of sprints that build towards something bigger. And that's the main leap from running individual sprints to actually developing something meaningful through Agile. What you'll need. Here are the practical tools. You'll need Trello for your board. You'll need Notion for documentation. If you've already got those set up from previous work, you're ready to go. You will also want your project brief and your existing backlog in front of you. Most of this course builds on real work, so you will get the most out of applying it every lesson to a real project. So we are ready to begin. Thank you for joining me. In the next lesson, we will zoom out from a single sprint and look at the bigger picture, how individual sprints fit into releases, and why that matters. I'll see you there. 3. From Sprint to Release : Welcome back. In the real world, no team just runs one sprint. They run dozens, hundreds, or building towards something bigger. That something is called a release. By the end of this lesson, you'll understand what a release is, how sprints fit into it, and why thinking at the release level changes how you plan. So what is a release? A release is a meaningful chunk of work delivered to users. Not just a sprint's worth a chunk that's worth telling people about. It could be a new product version, a major feature, a campaign going live. Something that the outside world notices. For a software product, a release might be version two point oh with the new dashboard and the redesigned onboarding. For an event, the release is the event itself. For ecommerce, a release might be the Autumn product line, all six products, the new landing page, and the marketing campaign. Releases give your work shape. They are the milestones in the journey. So how sprints build towards releases. Each sprint is like a stepping stone. So most releases take multiple sprints. Three is common, six is not unusual. Some releases might take ten sprints. So here's the relationship. A sprint delivers an increment, a small piece of working output. A release is a collection of increments that together achieve something bigger. So picture it like this. Your sprint goal might be Learners can earn stars after completing lessons. It's useful, but on its own, it's a feature and not a release. Your release goal might be version two point oh, a fully gamified learning experience. That release includes the stars, plus streaks, plus badges, plus the parent dashboard. You have multiple sprints building together. This is important because each sprint should feel like progress towards the release. If you can't see how this sprint links to a release goal, you're either doing the wrong sprint. Or you don't have a clear release goal. So why think at the release level? Let's look at why it matters. There are three reasons that release level thinking matters. One, stakeholders care about releases, not sprints. Your manager doesn't care that you finished story 47 last Tuesday. They care that the new feature ships in three weeks. Talking in releases connects your sprint work to the things people actually wait for. Second reason, it surfaces dependencies early. When you plan three sprints together, you spot that story B depends on story A finishing first, and that dependency is invisible if you only ever plan one sprint at a time. Third reason is that it forces honesty about timing. So this release ships in eight weeks is a much harder claim than this sprint goal. You either believe it or you don't. Release planning is where wishful thinking gets exposed. So a release versus sprint planning, slightly different cadence and different precision. So a quick distinction sprint planning happens every two weeks. Release planning happens once per release. So sprint planning is detailed. You pick specific stories, you commit to them. You know exactly what you're doing in the next two weeks. Release planning is more rough. You group stories into themes, you estimate how many sprints each theme might need. You sequence them and you build a rough timeline. Both are very important. Sprint planning without release context produces busy work. Release planning without sprint discipline produces fantasy. So there are three traps to avoid when releases go wrong. So some common mistakes in release thinking. Number one is scope creep. The release starts with three themes. By sprint four, it's got six. Now you're behind. You have to be ruthless. Anything new goes into the next release, not this. Number two is hidden dependencies. You discover halfway through that two themes can't ship without a third. Surface dependencies during a release planning, not mid sprint. And the third is ignoring reality. The team's velocity says five sprints, but the leadership wants three. Releasing late is normal. Hiding that reality until the last possible moment is what gets people fired. So ignore that. Thank you for joining me. In the next lesson, we will dig into the three levels of planning that every Agile team uses, roadmaps, releases, and sprints, how they differ and how to keep them connected. So I'll see you there. 4. Three Levels of Planning: Welcome back. In the last lesson, we introduced releases. In this one, we will widen the lens even further. Every Agile team plans at three levels, the roadmap, the release plan, and the sprint. They look similar from a distance, but they answer very different questions. By the end of this lesson, you will know what each one is for and how to keep them connected without drowning in plans. So, the three levels of planning. Picture three concentric circles. From outside in, we have roadmap, release plan, and sprint. The roadmap is the outermost. It's the high level direction over six months, 12 months, sometimes even two years. It says, This is where we're going in broad themes. It's not specific features or themes. The release plan is the middle layer. It says, Here is the major delivery. It groups specific features and themes into a release. And this usually covers a few months. Sprint is the innermost. It says, This is exactly what we're doing in the next two weeks with specific stories, committed work, and each level answers a different question. Roadmaps answer Where are we going, releases answer, What's the next big thing, and sprints answer, What are we doing right now? So let's have a look at what goes in a roadmap. Road maps are thematic. They show direction but not commitments. Typical roadmap might have three to five swim lanes covering six to 12 months. Each lane is a theme. Inside the lane, you have rough chunks of work sized by quarter or by month. Avoid putting specific dates on roadmap items. Roadmaps are about direction and dates create false certainty. Oth quarter is fine. 15th of August is a hostage to fortune. Roadmaps are owned by the product owner or product manager, and they are shared widely. Stakeholders look at the roadmap to understand what the team is doing this year. Release plan, the middle circle. Release plans are more concrete. They turn a roadmap into a deliverable. So a typical release plan covers two to six months. It lists the major features or stories in the release in rough priority order. It does have a target release date, but the date is a target rather than a guarantee. Release plans also service dependencies. Story X depends on story Y. We can't ship the launch page without the products. We can't run the event without the venue. All these dependencies need to be visible at the release level, even if the detail lives in individual sprint plan. These plans are reviewed every sprint. They are living documents which are updated as you learn. And finally, we have the sprint plan. This is detailed, it's committed, and it's all about now. A sprint plan covers usually two weeks. It lists specific stories with acceptance criteria. It commits to a sprint goal. It includes capacity, risks, and dependencies for the next two weeks. Sprint plans are the most precise of the three levels because the work is happening right now, which means you can also be specific. The further out you plan, the less specific you can be without lying to yourself. Oh, some tips on keeping these three separate plans connected. The three levels only work if they're connected. So the first tip is every sprint goal should ladder up to a release outcome. If a sprint isn't moving towards the release, why are you even doing the sprint in the first place? Number two, every release should ladder up to a roadmap theme. If a release doesn't fit on the roadmap, the roadmap is wrong or the release is wrong. Three, review them in different cadences. Sprint plans every two weeks, review plans every sprint review, roadmaps every quarter. Four, use the same vocabulary across all three. If your roadmap says engagement and your release says intention and your sprint says stars, you've broken that link. Make sure the language is consistent. And the fifth tip is, keep them all in the same place, if possible. Notion works very well for this one page per level, all linked together. Okay, three levels, Roadmap, release and sprint connected through clear goals and shared language. Thank you for joining me for this lesson. In the next one, we will get hands on building an actual release plan for your project in Notion. I will see you there. 5. Building Your Release Plan: Hello, and welcome back. In this video, we're going to look at building your first release plan. We will do this inside Notion. First of all, I will go through the steps that we're going to take in order to build this page, and then I will show you the page all setup in Notion. I'll also show you how to add your bidirectional links, which will link the release with the sprint. Oh, first of all, what we're building, you're going to add to your existing Notion workspace. You're going to add a new sub page. You're going to add a new database. You're going to potentially use page templates. And then we're also going to look at how you add your bidirectional links, which connects the release to the sprint and the sprint to the release. First of all, step one is to create the sub page type forward slash page, name a new page called release plan inside your main project page. Number two is to add the database to that page. So forward slash table, and then you can configure the columns with the names name, release goal, target date, status, and sprint planned. Three is to populate your first release. So click the row and fill in your first release goal, your target, the status, et cetera. Step four is to structure the release page with five sections, with your themes, your sprint breakdown, the dependencies, the risks, and the progress. And then step five will be to link your sprint, which would be bidirectional linking from release to sprint and from sprint to release. So let's have a look at the setup in Notion. So I've added the page release plan here at the bottom, so I'll show you what this should look like. I've added a database. We've got the first release in here, which is release 1.0 for my project, which is an Ed Tech project. The first release is game fide Learning. I have the release goal here. The field I've selected there is text, which allows me to add by version 1.0, learners are motivated to return daily through stars, streaks and avatar customization. The next column is target date, where I've selected the input being date. It's 14 August 2026, six weeks from now, and I've clicked status, which is the select field, which allows you to then add the different statuses. I've added released active and planning, and then sprints planned. This input would be number. I've just put three. So we've got three sprints planned for this release. So let's have a look at the release page. So if you open the release page, you can then structure your release page as so. It's already got all of the information from the database above and below, here is where we have the structure. So we have themes with the star reward system, streaks and habits, and avatar customization. We have sprint breakdown with the first sprint and the link to the first print. We have the key dependency section with an animation library decision if needed by the end of sprint one, backend API endpoints for star assistant, design assets for avatar options. We have some risks at the bottom, animation complexity might bleed into sprint three. The mitigation is to spike early, and then streak logic, edge cases, missed days, time zone changes, et cetera. And at the bottom, we've got the progress, which is what you would fill in as you were doing the sprint. So how to add the link. Here, I've added the link to the first sprint, which is the Star reward system. So in order to do that, you just add the app sign, and then you start typing the name of the page, which is called star Reward system. You click it there, and it adds the link. And then when you click the link, it takes you to the star reward system sprint. And as you can see, we have the capacity. We have the selected stories, we have the risks and dependencies, and the commitment. This is the detail of the sprint. And at the top of here, I've put part of release plan. Again, to add the link, you just click. Type the at sign. Here you can search any name of any page that you have, and you can link to that page. So you've got here release plan. So just click release plan and we can see it's there. And this takes us back to the release plan, which we've got in this page here. So let me just quickly go back in there. I remove this. It's very easy to add your bidirectional links. I highly recommend doing this. It will keep everything nicely linked. So that's the end of the notion, step by step guide on how to set up your release page. Next video, we have a little practice exercise, which would be your release plan. So drafting a three sprint plan for your selected brief. That's up next. I'll see you in the next one. 6. Practice Exercise: 3-Sprint Release Plan: O Welcome back. It's time to put everything you've learned in this section into practice. In this little exercise, you will draft a three sprint release plan for your own brief, and by the end, you will have a real release plan in notion ready to use for the rest of this course. Your task, it has five steps. Take your time, but don't agonize over this. The first step is to define your release goal. It should be one sentence, which is outcome focused, and it's the thing that you want true at the end of three sprints. Step two is to identify three themes. Each one becomes the focus of one sprint and each theme should advance the release goal. Step three is to break down each theme into three to five stories, mostly stories that already exist in your backlog if you have one. Step four is to surface dependencies and risks, what needs to be true for this release to ship. And step five is pick a target date and be realistic. Six weeks is a good ballpark for a three sprint release. Now let's look at my EdTech worked example. This is what a good release goal looks like and what a finished plan might look like for my EdTech brief. So the release goal is by Version 1.0, learners aged four to eight are motivated to return through daily stars, streaks and personalization. Theme one is sprint one, the star reward system, the stories, stars after Lessons, star display and animation. Theme two is sprint two, which comprises of streaks and habits. Stories are daily streak counter, streak rewards, and lap streak handling, and then Theme three or sprint three is Avatar customization. The story is there. We have Avatar selection, Avatar persistent and avatar in essons. Some dependencies, the animation library chosen at the end of sprint one, the risks are that a streak logic might be more complex than expected, and the target date is six weeks from now. We have some common mistakes to avoid. Here are the big three. The first one is by making the release too big. For example, by version one, the app is perfect, which is this is useless. Pick a smaller narrower outcome. Two is if the themes don't fit into one sprint, if it needs two sprints, it's actually two themes, so split it up. And the third is ignoring capacity. Don't plan three sprints worth of work into two sprints. Check your velocity, which we will cover properly in the next section. So some sanity checks before you call it finished. One is, does the release goal feel achievable in three sprints with the team you've got? You have to be honest. Two is, if I shipped only the first sprint, would that be useful on its own? Good releases have early wins, not just a big finish. And Step three, can I explain the release in one sentence to someone who's never seen the project? If yes, it's clear, if you find yourself qualifying, the goal isn't tight enough. So save your release planning notion in the release plan database that you built in the last lesson and link it to your existing sprint planning pages so that the levels connect. And this is now your reference document for the next few sections. So every estimation or the metrics, stakeholder lesson in this course, will refer back to this. Up next in Section two, we have estimation and velocity. In this section, we've zoomed out a little from sprint one into release, and we have the page plan. So thank you for joining me. In the next section, we'll get serious about estimation and velocity and the techniques that make multi sprint planning actually credible. I will see you in the next section. 7. Why Estimation is Hard, and Often Wrong: Welcome back. In project management, estimation is one of the hardest thing that any team does, and it's one of the most misunderstood. Before we dig into the techniques in the rest of this section, we need to be honest about why estimation is so difficult. By the end of this lesson, you will understand the biases that make estimation unreliable and why that changes, how you should use estimates in the first place. First up, we have the planning fallacy. So start with the biggest problem. Humans are terrible at estimating how long things will take. There's a well known cognitive bias called the planning fallacy, first described by Daniel Carnman and Amos Tversky in the 1970s. The finding is simple. When people estimate how long a task will take, they consistently underestimate, not by a little, by a lot. Studies have found that even when people are told about the planning fallacy and asked to correct for it, they still underestimate. Why? Because when we think about a task, we imagine the ideal path. We picture ourselves working smoothly without interruptions, without setbacks, without discovering that the requirements were unclear. And reality is nothing like that. So why our work is worse? Now, the planning fallacy applies to everything, but some kinds of work are harder to estimate than others. And unfortunately, most of what we do falls into the harder category. You're painting a fence, for instance, you can estimate reasonably well. You've done it before. It's a physical task with visible progress, and there are a few unknowns. If you're building software, however, if you're running a campaign or you're organizing an event, everything is different. Every task is a little bit new. You're often solving a problem you've never solved before. Requirements shift as you learn, dependencies emerge that you did not anticipate, and you discover halfway through that the approach you picked doesn't work. And you need to try something else. That's why our estimates in this kind of work are usually wrong, not because we're bad at estimating, but because the work itself is inherently unpredictable. So some common biases in estimation. Beyond the planning fallacy, these are several other biases worth knowing about. First is optimism bias. We assume things will go well even when past evidence says otherwise, you forget the last three times your estimate blew up, you focus on the times it worked instead. Next is anchoring. The first number mentioned in a discussion becomes the anchor that everyone gravitates towards. If your manager say could this be done in two weeks? Suddenly two weeks feels reasonable whether or not it actually is. The next one is social pressure. Nobody wants to be the person saying this will take six months in a room full of eager stakeholders. So estimates drift down quietly to fit what people want to hear. And last, we have the cone of uncertainty. Early in a project, when you know the least, your estimates are the least reliable. But that's also usually when people want them the most. The cone gets narrower as you learn, but the earliest estimates are basically guesses. So what this means for how you estimate. So three practical implications. One, treat estimates as ranges, not points. This will take 2-5 sprints is more honest than this will take three sprints. Any single number estimate is hiding uncertainty. Two, track your estimates against reality. Over time, you'll learn your team's actual bias. If you consistently underestimate by 40%, you can start correcting for it, but you can't correct for what you don't measure. Three, use estimates for planning and not for promising. This is the biggest shift. An estimate is a tool for making decisions about what to work on. It is not a commitment to deliver on a specific date. The moment an estimate becomes a promise, you've broken the honesty that makes it useful. So why are we still estimate? Why bother? So, given all this, you might wonder why bother estimating at which, to be fair is a fair question, but the answer is even bad estimates help. They force you to think about the work. They surface unknowns. They give you rough sizing to compare options. So this is definitely bigger than that is more useful than the exact numbers. The techniques we'll cover in the rest of this section aren't all about producing accurate estimates. Nobody really produces accurate estimates all the time. They're about producing useful estimates, estimates that inform decisions that force honest conversations and that get better over time as you track how they compare to reality. Okay, estimation is hard, but being honest about that is the first step to doing it well. Thank you for joining me. In the next lesson, we'll take a proper deep dive into story points, what they are, how to use them, and how to avoid the traps that most teams fall into. I will see you there. 8. Story Points: Deep Dive: Welcome back. Story points are the most common estimation technique in Agile, but they're also the most misunderstood. In this lesson, we're going to go a bit deeper than surface level. We will look at what story points really are, why they work, and the specific practices that make them useful rather than performative. So what story points are? They are a unit for measuring the relative size of a piece of work. They combine three things, how much effort a story takes, how complex it is, and how much uncertainty it carries. Five point story is roughly five times the size of a one point story, not five times the hours, five times the size. Effort, complexity, and unknowns are all rolled together into one number. The point is that human brains are much better at comparing sizes than at estimating absolute durations. Ask someone how long a task will take in hours, they'll probably be ask them whether it's bigger or smaller than another task, they'll usually get it right. So the Fibonacci sequence properly explained. Most teams use the Fibonacci sequence one, two, three, five, eight, 13, 21, sometimes 40 and 100 for very large items. There are two reasons for this specific sequence. First, the gaps get wider as numbers get bigger. The difference 1-2 is small. The difference 13-21 is huge. And this mirrors real uncertainty. When something is small, you can actually see it clearly. When something is large, you probably don't understand it well enough to distinguish an eight from a nine. Second, the wide gaps force decisions. You can't sit on the fence between two adjacent numbers. Either it's a five or an eight, that force choice speeds up estimation and prevents endless debating. So anchoring your reference story. The most important practice with story points is choosing a good reference story. This is the anchor, a story that everyone on the team knows well, that you all agree is a certain size, usually a two or three. Every other estimate happens relative to this reference. A small reference story that is small enough to be easily understood, well documented, and already delivered, so everyone remembers how it went. Then when you estimate a new story, the question isn't, how big is this in the abstract. It's how does this compare to our reference? If your team is doing your project story about earning stars for lesson completion, on agrees that was a three. Then when you look at a new story like adding streaks, you ask, is this bigger or smaller than the stars? By how much, two times by half. Without a reference story, estimates start to drift. Each sprint, they mean something slightly different and the numbers stop being comparable over time. Planning poker properly. Story points work best when estimated by the whole team. Playing poker is the classic technique, but let me go deeper than the surface level. Everyone in the team gets a set of cards with the Fibonacci numbers. The product owner reads out story. The team asks clarifying questions briefly. Then each person picks a card in secret and everyone reveals at the same time. The critical moment is when the estimates disagree. Say three people said three and one person said eight, don't just average. Don't just take the highest or lowest. Ask the outliers to explain. Nine times out of ten, the person who estimated eight knows something that the others don't. Maybe there's a dependency or a complexity or a past failure that they remember, and that knowledge needs to surface. Once they've shared it, everyone else reestimates. The number then usually converges. If you're working solo, you are the whole team, which means you need to be extra rigorous. Try estimating the same story a day apart and compare. Look for consistency. Your first blush estimate is often quite optimistic. What story points or not? Some common misunderstandings. Get these wrong, and story points become pretty much useless. One, story points are not hours. Ten story points does not mean 10 hours or ten days or any specific time. The relationship between points and time only emerges over multiple sprints and only for that specific team. Two, story points are not a performance metric. If everyone tells you the team should be delivering 40 points per sprint, they've misunderstood. Story points are for planning. They are not a stick to beat teams with. Three, story points are not comparable between teams. Team A's five is not the same as team B's five because story points are collaborated to a team's specific reference story, they're only meaningful within that team. Four, story points are not fixed. If a story you estimated as a three turned out to be much bigger than you thought, you don't retrospectively update the estimate. You leave the estimate as is, and you use the difference to improve future estimates. When story points don't work, so they're not the right tool for every situation all the time. There are three situations where you might not need them. Very small teams doing very similar work. If you are solo and every story is roughly the same, you don't need points. Just count stories. Highly variable work if one sprint is heavy engineering and the next is light polish. Points won't be comparable, Cam Ban with the cycle team that might work better. Any situation where the estimate is being used to promise a date. If leadership will take your story point total and convert it to a deadline, the technique is being misused. It's better not to estimate at all than to feed a broken process. Story points done properly are a powerful planning tool. Done badly, they can become a source of confusion. Thank you for joining me in this lesson. In the next one, we'll look at what story points make possible across multiple sprints and tracking velocity. I'll see you there. Oh 9. Tracking Velocity Across Sprints: Welcome back. Now that we've covered story points, we can talk about the metric that they make possible, which is velocity. Velocity is one of the most powerful and more of the most misused metrics in Agile. In this lesson, we will cover what velocity is, how to track it well, and how to keep it useful without letting it become dangerous. So what velocity actually is. Velocity is simple. It's the total number of story points a team completes in a single sprint. Team finished four stories worth three, five, five, and eight points, their velocity for that sprint was 21. Notice, velocity counts only completed stories. Anything left in the doing in the end of the sprint does not count, and this is deliberate. Finished work is what matters the most. Partial credit encourages the exact behaviors you don't want like accumulating half done work. You calculate velocity for every sprint. Over time, you get a series of numbers that show how much your team consistently delivers. So very useful. Why it matters. There are three reasons that velocity is valuable once you've got a few sprints worth of data. One, it helps with sprint planning. If your average velocity is 25 points, don't commit to 40 in the next sprint because you'll fail. You'll overwork and your future estimates will be poisoned by this false data point. Two, it enables forecasting. If your remaining release has 100 points of work and your velocity is 25, you're roughly four sprints out. Exactly, but enough to make real plans. Three, it services problems. A sudden drop in velocity is a signal. Was someone off sick? Did you take on unusually complex work? Is the team burning out? Velocity data prompts the right conversations. How to track it well? So practical guidance. First, ignore the first three sprints. Every team's initial velocity is unreliable. You're still calibrating your story point sizes. Your reference story is stabilizing. So three sprints is roughly how long it takes for the numbers to start becoming meaningful. Second, use a rolling average, not a single sprint. Look at your last three or five sprints and take the mean average. This smooths out a single sprint to sprint noise. A single sprint with velocity 40 doesn't mean anything if your rolling average is 25. Third, track it visibly. A simple table works. Add a velocity log into your Notion workspace with one row per sprint. Columns, sprint number, planned points, completed points, and any notes about why the sprint went how it did. Over time, this data becomes gold. Fourth, review it every sprint. In your retrospective, look at your velocity trend, not to calibrate or to berate, just to notice patterns. We've dropped in each of the last three sprints. Why is that? You'll be able to find out. Next up, we have the dangers of velocity. Velocity is powerful, but it's also easily misused. There are four dangers to know about. One, velocity as a target. The moment velocity becomes a goal, it stops measuring what you thought you did. Teams inflate their story point estimates. Suddenly, a story that was a three is a five, velocity goes up, even though nothing actually changed. Two, velocity comparisons between teams. Team A does 40 points. Team D does 25. Team B looks lazy, but maybe they just estimate differently. Maybe their work is genuinely harder. Never compare velocity across teams. Three, velocity as productivity. High velocity is not the same as high value. A team could deliver 100 points of features that nobody uses. Story points measure size but not value. And for velocity used to shame. In too many organizations, velocity becomes a stick that leadership uses to press teams. This destroys the honesty that makes the metric useful in the first place. So adding velocity to your workspace. This could be a new Notion subpage with four columns. So open your Notion workspace, add a new subpage inside your main project page, call it velocity log. Inside that page, add a database with four columns, sprint number as a number. Points planned as a number, points completed as a number, and notes as text. Fill in one row per sprint as you complete them if you've already done a sprint or two, you can backfill them now because even rough historical data is useful than nothing, and over time, this becomes your team's memory. Now, team members can see the story, retros can point at the data, and forecasts can be grounded in reality. So absolute gold to a project. However, velocity can cause some wobbles. Some teams have wildly variable velocity sprint to sprint. If that's you, do not panic. There are three common causes of this. One, your reference story keeps shifting. Fix the reference, anchor on a story that everyone remembers. Two, your sprint length is inconsistent. If some sprint to two weeks and others are one week, of course, velocity is going to vary. Just fix the sprint length. Three, you're doing wildly different types of work each sprint. Some sprints are heavy build, some are testing. So are just polish. In that case, story points might not be the right tool for your team. We'll cover Caban as an alternative in the next section. Velocity used well is a genuine forecasting tool, but used badly, it becomes theater. So make sure you're using it correctly because used correctly, it can become gold. Thank you for joining me in this lesson. In the next one, we'll put velocity to work, forecasting how many sprints your release will actually take. I'll see you there. O 10. Forecasting the Release : Welcome back. Everything so far in this section has been the groundwork. Now we're going to put it to work. In this lesson, you'll learn how to answer the question every stakeholder eventually asks, How long is this going to take? By the end, you'll know how to produce a defensible and honest forecast without pretending to see the future. The basic calculation, this one line of arithmetic, it's quite simple, really, total remaining points divided by average velocity. So if your release has 100 story points of work left to do and your team's rolling average velocity is 25 points per sprint, then you'll need roughly 100/25, which is four sprints. This is simple and it's reliable enough for most purposes. But there is a little bit more to it than that because the calculation depends on two numbers that both carry a little uncertainty. The total points and the velocity. If you get either of these wrong, then the forecast is also wrong. So we start with the total point count. This assumes you've estimated every story in the release. When in practice, you rarely have. Some stories are well understood, but some are still vague and some might not even exist yet. There's this old rule in Agile not everything in the backlog is estimated. Only the stories that are close to the top of the backlog get proper estimates. Stories further down or placeholders ideas or even wishes. So when you're forecasting, be honest about what your point total actually represents. Is it a total of well estimated stories or is it a mix of solid estimates and rough guesses? Useful practice here for stories that aren't yet estimated, add a placeholder using your team's average story size. If your stories are five points, use five for anything that's vague. It's better than nothing, but flag it explicitly in the forecasting. Problem with velocity. Now, for the velocity side, your average velocity is only useful if the future looks like the past, and often it doesn't. Team members go on holiday, new people join, the work gets harder as you tackle the more complex stories left at the top of the backlog. Dependencies emerge that slow things down. A more honest forecast uses a range instead of a single number. So you look at your last five or six sprints, and the lowest velocity is your worst case. The highest is your best case. Average is your middle case. Then present three numbers. Best case is three sprints. Likely case is four sprints, and the worst case is six sprints. This is far more honest than saying four sprints and then pretending that you know. So, talking to stakeholders, here are some rules for the conversation with the stakeholders as how you communicate your forecast matters just as much as the numbers themselves. Do not give a single number. Don't say it'll ship in six weeks. This always ends badly. Reality never matches a single point estimate. Do give range with explicit context, though. Based on our current velocity, this release will take 4-6 sprints, but likely five. That range assumes no team changes and no major surprises. We'll refine the sprint estimate every sprint as we learn more. Do explicitly name your assumptions. This assumes we don't take on any other priorities. This assumes you don't lose anyone. This assumes the estimates we have are roughly correct, and stakeholders can then challenge those assumptions, which is exactly the conversation that you do update the forecast every sprint. Fresh forecast gives you fresh data, communicate the change openly. For example, two weeks ago I said four to six sprints. Based on this sprints data, it now looks like five to seven, and this normalizes change. Nobody expects a forecast made months ago to still be accurate. Here are some common mistakes to avoid. One is assuming velocity is stable, which it is. Some sprints are worse than others, so that's why we use ranges and not averages. Two, forgetting non story work, bug fixes, meetings, admin, tech debt, thesy inter capacity, but often aren't in your story point total, so you should adjust for those. Three, assuming the team can go faster, if we all work weekends, we'll deliver in three sprints. This is complete fantasy. Sustainable pace is what velocity measures. Working overtime does not scale, and it's not reality. Four, ignoring dependencies outside the team. If your release depends on another team, a vendor, a client or a stakeholder decision, your forecast is only good as their timeliness. Make the dependency visible in the forecast. So what if your forecast is unwelcome? In this case, you just have to be honest anyway. So sometimes your honest forecast conflicts with what the leadership wants, and this happens all the time. What do you do in those situations? Honesty is the best policy. Based on our velocity, this looks like a six sprint release. I know you wanted three let's talk about what we could do to hit that. Never quietly commit to a date that you can't hit. That doesn't buy you time. It just moves a failure to later, which where it'll just hurt more. If the pressure is severe, put it in writing. We agreed we tried for three sprints. Understanding this is well below our average velocity and would require dropping X, Y, and Z. This protects everyone if the schedule slips. So a forecast isn't a promise. It's a considered estimate made with the best data you have communicated with honesty about its limits. Thank you for joining me in this lesson. In the next one, we will put this exercise together, and you will estimate your own release and produce a real forecast. I'll see you in the next one. 11. Practice Exercise: Estimate and Forecast: Welcome back. It's time to put everything from this section into a proper hands on exercise. You're going to estimate the stories in your release, produce a real forecast and communicate it in a way that would work with real stakeholders. By the end, you'll have a defensible forecast for your release plan, backed by actual data. So first of all, set up your workspace, open Notion and Trello. So on your Trello, you have your board and you have your Notion workspace or documentation, you'll be working with both of these. In Notion, if you haven't already, add a velocity log sub page, a simple database with four columns. Sprint number, points planned, points completed, and notes. If you've already run a sprint or two, backfill your velocity log with what you actually delivered on those sprints. Rough estimates here are fine. Something is better than nothing. On your Trello board, make sure all the stories in your current release are visible. If they're spread across the backlog, group them somehow maybe with a label like release 1.0. This way, you can see the full scope in one place. Next up is to pick your reference story. This is the anchor that everything else hangs on. This is the first step of the exercise. So look at the stories you've already completed and pick one that's small, well understood, and that everyone can remember. Clearly. This is your anchor. Assign it a point value. Two is a good default. Now, write down what makes it a two, something like this is a simple UI change that took a couple of hours with no unknowns and no dependencies. It's our two. This description will help you calibrate other estimates in the future. Estimate every story in your release relative to your reference story. So go through your stories one at a time. For each story, ask, is this bigger or smaller than my reference? How much bigger? Pick a Fibonacci number, one, two, three, five, eight, 13, or 21. Some tips. If you find yourself hesitating between numbers, pick the larger one. Optimism bias is real. So if a story feels like an eight, estimate eight. If a story feels like a 21 or bigger, stop, it's too big and break it into smaller stories and then estimate those. If you genuinely don't understand the story well enough to estimate it, then mark it as needing refinement. Don't guess because that will give you false confidence. Aim for ten or 20 estimated stories, but don't try to estimate the whole backlog, this release. Add your estimate as labels in the card descriptions on Trello to keep it visible. Step three is to add it all up. Sum the points for all of your estimated stories. This is your total for the release. Look at your velocity log. If you have data from previous sprints, take a rolling average. If you don't have data yet, that's fine. You can make a rough estimate based on what your first sprint delivered, or you can estimate what you think a realistic sprint will produce. Divide the total release points by your velocity, and this is your basic forecast. Now do the range calculation, divide by your lowest velocity for the best case, by your highest for the worst case, and this gives you a proper range. Write the forecast in Notion is the next step, and this is the most important part. Open your release plan in Notion under your progress heading or add a new one called forecast. Write the following. The forecast range in sprints, best case, likely case, worst case, the data range those sprints correspond to, if a sprint is two weeks, four sprints is eight weeks from today. So write down the assumptions you made, the team availability, no scope changes, no major surprises, no refinement of estimates as you learn. The final thing is the confidence level based on three sprints of velocity data, medium confidence, or based on one sprint, low confidence. This is your forecast document, and this is what you would share with stakeholders. It's real, it's honest, and it's defensible. Golden data. Before you call it done, there are three checks that you really should make. One, does the forecast feel right? If it says three sprints and your gut says six, you really should trust your gut. Something's off either in your estimates or your velocity. Two, could I defend this to a stakeholder? If someone challenged the numbers, could you walk them through the working out? If yes, then it's good. If not, you need to add more detail. Three, what would change my mind? If a new dependency emerged or if the team shrank or if the story turned out to be much bigger, naming these makes them visible. So you now have a real and honest forecast for your release. So save this and update every sprint. Thank you for joining me for this section. In the next section, we will look at Scrum, Canban and how to choose the right approach for the work you are actually doing. I will see you there. 12. Scrum Revisited: When It Works, When It Doesn't: Welcome back. In this lesson, we're going to take an honest look at Scrum and do a quick recap of what it is. Scrum is the most widely used Agile framework in the world and for good reason, but it is not the right tool for every single situation. So by the end of this lesson, you'll know where Scrum genuinely shines and where it works quietly against you and how to spot the warning signs that it might be the wrong fit for your project. Okay, quick little recap of Scrum condensed down into 1 minute. Let's just make sure we're all on the same page here. In case Scrum is new to you, here's the whole thing in just 1 minute. Scrum organizes work into fixed length blocks called sprints, which are usually one to two weeks long. You plan a sprint, you commit to a set of work, and you protect the team from changes during that sprint, and at the end, you review what you built and reflect on how it went, and then you do it all again. Three roles, a product owner who decide what gets built and in what order, Scrum Master who helps the team work well and remove blockers and the team who actually do the work. There are a handful of regular meetings, planning at the start, a short daily check in, and the review and a retrospective at the end. That's Scrum. It's fixed rhythm with clear roles and a commitment each sprint. So Scrum is brilliant in the right conditions, and here's when it works beautifully. First, when your work can be planned a sprint ahead, if you can sensibly decide on Monday what you'll build over the next fortnight, and that decision mostly holds, Scrum gives you a very comfortable rhythm. Second, when the work fits into sprint sized pieces, building a new feature for our children's language learning app, for example, like a set of vocabulary quizzes, breaks down nicely into stories that you can finish inside a sprint. And that is ideal Scrum territory. Third, when your stakeholders value predictability, the fixed cadence means that everyone knows there'll be something to see at the end of every sprint. For a nervous stakeholder, that regular heartbeat is very reassuring. And fourth, when the team is stable and dedicated, Scrum assumes a consistent group of people focused on one product. When that's true, the team builds up a rhythm and a shared sense of pace. Let's have a look at where the Scrum framework struggles. So Scrum starts to fight you in a few common situations. The first is interrupt driven work. If your day is dominated by urgent things arriving unpredictably, like support issues or live incidents, the idea of committing to a fixed plan for two weeks just falls apart. Plan is out of date by the Tuesday. The second is work won't sit still. If priorities genuinely change several times a week, not because your stakeholders are being difficult, but because the situation is really that fluid, then a sprint planning becomes a fiction that you will end up rewriting constantly. The third is work that doesn't fit the sprint box. Some tasks are tiny and constant. Some are big and slow. If your work is a messy stream of wildly different sizes, forcing it into neat two week commitments creates more friction than flow. And the fourth is when the ceremonies feel hollow. If your daily checking has become a status report to a manager and your retrospective produces the same complaints every single fortnight with nothing changing, the framework has stopped serving you. So let's have a look at some warning signs that Scrum is fighting. How do you know Scrum is the wrong fit? Have a look for these telltale signs. Sign one, you carry workover at the end of almost every sprint. The occasional spillover is normal, but if unfinished stories roll into the next sprint again and again and again, your commitment isn't meaning anything. Sign two, planning feels like theater. You go through the motions of sprint planning, but everyone knows that the plan will be blown apart within days. If nobody trusts the plan, then why are you making it in the first place? Sign three. Changes arrive mid sprint constantly, and you keep letting them in. Scrum is meant to protect the sprint. If you're renegotiating the sprint every couple of days, you don't really have sprints. Sign four, the team dreads the ceremonies. Meetings that add value don't get resented. Meetings that have become ritual do. Your team size at the site of another planning session, that is data. None of these signs mean you failed. They mean the tool and the work have stopped matching, and that is worth taking seriously. So Scrum, by no means is the only way. So here's things that many teams miss. Scrum is not Agile. Scrum is one way of being Agile. Agile is the mindset, deliver value early, respond to change, and improve continuously. Scrum is one popular set of practices that supports that mindset. It is not the only one. If Scrum fits your project, wonderful. Use it well. But if you've been nodding along to the warning signs, is another approach that handles unpredictable, flowing, interrupt driven work far better. It's called Kanban, and it's where we're going next. So Scrum is a very powerful framework, but only when the work suits it. Knowing when it doesn't is a sign of maturity and not failure. Thanks for joining me in this lesson. In the next one, we'll take a proper deep dive into Kanban, how it uses flow and working progress limits to handle exactly the kind of work that Scrum struggles with. I'll see you there. 13. Kanban Deep Dive: WIP Limits and Flow: Welcome back. In this lesson, we're going to dig into Caban, the flow based approach to managing work. If Scrum is all about rhythm and commitment, Cam Ban is about flow and limits. By the end of this lesson, you'll understand what a Cam Ban board looks like, what working progress limits are, and why deliberately doing less at once can help you deliver more. Let's get into it. So Camban comes from Japanese manufacturing where it means a visual signal or card. In our world, it's a way of managing work as a continuous flow rather than in fixed sprints. There are no sprints in Cam Ban. There is no commitment to a two week batch of work. Instead, work flows across the board from left to right, one item at a time, and the team pulls in new work whenever they have the capacity to take it on. And that's the heart of it. Camban has three core practices. Visualize your work limit how much you work on at once and manage the flow so work keeps moving. We'll take each of those in turn. So first, start with visualizing the work. A Cam Ban board is a set of columns, and each column is a stage the work passes through. Here's a typical five column board for our children's language learning app. On the far left, we have the backlog, everything we might do in priority order. Next, to do the small set of things that are ready to be picked up. Then in progress, what's actively being worked on right now, then review work that's done and is waiting to be checked and finally done, which means finished and verified. Every piece of work is a card and it moves rightward through those columns as it progresses. At a glance, anyone can see exactly where everything is, and that visibility on its own is worth a lot. But the real power of Camban comes from the next. Which is working progress limits. So look again at the board. Notice the small numbers on the two of the columns. In progress has a limit of three. Review has a limit of two. These are working progress limits or WIP limits for shorts. WIP just means working progress. Anything you started but not yet finished. A WIP limit is a cap on how many items can be in a column at once. If an in progress limit has a limit of three, the team may have at most three things being actively work on, not four, not ten. Three. Now, here's what that means in practice. If in progress is full and you finish a card, you don't start something new from to do straightaway. First, you look at whether anything is stuck and you help it move along. You only pull in fresh work when there's genuinely room for it. The limit focuses the team to finish things before starting new things. Now, this feels a little bit counterintuitive at first, maybe. Surely, doing more things at once means getting more things done, but really it's the opposite, and it's worth understanding why. So why less is more. Three reasons limiting work in progress makes you faster not slower. The first, less switching. Every time you juggle another task, you pay a cost to switch between them. You lose your place, you reload the context, you make more mistakes. A team with five things on the go is constantly switching. A team with three finishes each one sooner. Second, bottle necks become visible. When review is capped at two and fills up, work stops flowing into it. That's not a problem to hide. It's only a signal. Tells you exactly where the jam is so the team can swarm on it and clear it. Without limits, work just piles up invisibly. And three, work finishes, a card sitting half done delivers, nothing. It's only valuable when it's finished and it's in someone's hands. Limiting work and progress pushes the team to drive all the things the way to done rather than starting lots and finishing little. Even a rough law behind this. The more things you have in progress at once, the longer each one takes to finish. Fewer things in flight equals faster delivery, and that's the whole game of Caban. So pull don't push. This gives Caban its defining rhythm. Pull, not push. In a push system, work gets handed to you whether you're ready or not. Your cue just grows. In a pull system, you only take on new work when you have the capacity for it. The WIP limits enforce that automatically. When a column has room, you pull the next item in. When it's full, you don't it's the difference between a kitchen where orders pile up faster than the cooks can handle and one where a new order is only started when a cook is free. Pull keeps the whole system flowing at a sustainable pace. So the mind shift at the heart of Cam Ban is flow not commitment. Cam Ban tells you to focus on flow, not a sprint commitment, but the flow and the smooth, steady movement of work from left to right. There are no sprints, you don't ask what will we commit to this fortnight. You ask, I work flowing well, and where is it getting stuck? You measure things like how long a card takes to cross the board from start to finish, and we'll come back to those flow measurements properly later on in the course. For now, the mindset the mindset shift is the important part from committing to a batch to keeping a steady stream moving. Now, this is why Cam Ban suits interrupt driven and unpredictable constantly changing work so well. There's no fixed plan to blow up. There's just the next most important thing. Pulled in when there's room for it. So Caban is deceptively simple. You visualize the work, you limit work in progress, and you keep it flowing. But those few ideas can transform how a team delivers. Thank you for joining me in this lesson. In the next one, we'll build a real Cam Ban board together in Trello step by step, so you can see exactly how it all comes together. I'll see you there. 14. Setting Up a Kanban Board in Trello: Welcome back. In this lesson, we're going to build a Cam Ban board from scratch in Trello. So Trello is free. It runs in your browser, and everything we do today works on the free plan with no paid features and no add ons required. So by the end of this lesson, you'll have a working five column cambabard for your project, complete with working progress limits. So let's begin. Quickly, let's have a look at what we'll build. Here's the plan. We're going to create a board with five lists, left to right, backlog to do in progress, review and done. Two of those lists in progress and review will have work in progress limits, which cap how many cards can sit in them at on. I'll explain it step by step, and then I'll show you what it should look like in Trello. So first of all, the WIP limit convention. Here is one of the downsides of the free Trello account. There is no built in feature that will physically stop you from adding a fourth card to a column limited to three. So instead, we'll use a simple but a reliable convention that uses nothing. We'll just put the limit right in the name of the list. So instead of it being called in progress, it'll be called in progress WIP three. So let's have a look at what the board should look like. So you have your backlog. I've added four cards into this one. Have to do with one card, I have Ding, which has a working progress limit of three. There's three cards in there. We have review with a working progress limit of two, and there are two cards in there, and I have a done column with two more cards in there. That's it. That's a simple Caban board. So very quickly, labels and pulling work, this is probably the most important part of any Caban board. When the team is ready to start something, they should drag the card from to do into in progress or to do. Watch the limit. In progress is capped at three. So before anyone drags a fourth card in, they stop and ask, can we finish or block something that's already here first, and work moves from left to right, one pull at a time, and it only moves into a column when that column has the room. So for example, we can move the progress badge from right to left from the backlog into to do. It's as simple as that. It's a very intuitive app. It's very simple to use, Trello, thankfully. But again, Caban is quite a simple concept. Before we finish some common mistakes to remember, first, don't skip the limit. A board with no working progress limit is basically just a fancy list with extra columns. The working progress limit is a concept of Caban, so do not skip it or else it's no longer a Caban board. Two, letting work done become a graveyard. So done genuinely means finished and verified. If it isn't checked, it has to stay in review, and it should only move when it has been checked and approved by either the product owner or the project manager. And finally, too many columns. So five is plenty to start. You don't need to add a column for every tiny step. Only add a stage later if a real one is actually missing, or else the extra columns will create busy work, and it'll make the board a little bit more confusing as well. So, so that's it. We've had a look at how to build a simple cambmbard from scratch in Trello. It's a very simple concept. It's a very simple thing to build in Trello, as well. On the free plan, it's very, very easily done. In the professional accounts, you do get the limits on WIP for each column, and you also get obviously some other features as well in the paid account. So in the next lesson, we will look at hybrid models, which is a little bit of both. So a mixture of Scrum and Caban, which is also known as Scrumban, and we will tailor it to Agile to fit how your team really works. So that is up next. Thank you for joining me in this lesson. I will see you in the next one. 15. Hybrid Models: Scrumban and Tailored Approach: Welcome back. In this lesson, we're going to talk about hybrids, mixing and matching Agile practices to fit your team. In particular, we will look at Scrumban, the most popular blend of Scrum and Cam Ban. So by the end, you'll understand what Scrumban is when it helps and the one rule that keeps hybrid approaches from turning into a complete mess. Let's start with a mindset point. Scrum and Cam Ban are not religions. They are tool kits. Nobody hands you a medal for following a framework perfectly, and nobody sensible will tell you your way of working is wrong just because it has a little bit of both in it. Real teams face real and specific situations, sometimes pure Scrum fits, sometimes pure Caban fits, and very often, the best fit is somewhere in between. The rhythm of Scrum with the flow control of Camban that in between space is where hybrids live, and the most common one has a name. Scrumban is exactly what it sounds like Scrum plus Caban. You keep some of the useful structure of Scrum and you add the flow tools of Cam Ban. In practice, a Scrumban team usually keeps a regular cadence, like a two week rhythm and keeps the useful ceremonies, like a planning conversation and a retrospective. But instead of committing to a fixed batch of work for the whole two weeks, they run at a Cam Ban style board with working progress limits, and they pull in new work continuously as capacity frees up. So you get the heartbeat and the rhythm of Scrum with the regular planning and the reflection, together with the flexibility of Cam Ban, the pull based flow that copes with change. For a lot of teams, that combination is the real sweet spot. So when Scrumban actually helps, when should you reach for Scrumban? There are three common situations. First is when your team wants a rhythm, but your work is unpredictable. Say, for example, our language learning app team likes meeting every two weeks to plan and to reflect, but half of their work is urgent bug fixes that arrive without warning. Scrumban lets them keep the fortnightly rhythm while handling the interruptions through a flow based board. Second, when you're moving from Scrum towards Cam Ban, switching a team's hallway of working overnight is jarring. Scrumban is a gentle bridge. You keep the familiar ceremonies while you introduce working progress limits and pull, and the team adjusts gradually. Third, when Scrum's commitment keeps falling but you don't want to lose its structure, if you're carrying workout over every sprint, but you'd miss the planning in the retrospective, Scrumban lets you drop the rigid commitment while keeping the parts that were actually helping in the first place. So tailoring beyond Scrumban, Scrumban is the famous hybrid, but tailoring goes further than that. Here are a few other sensible adjustments that teams often. You can run Scrum but add working progress limits to your board, so the team finishes work before starting more, even within a sprint. You can run Cam Ban but add a light regular cadence, like short review every Friday. So stakeholders still get a predictable moment to see the progress, and you can drop dead ceremonies that aren't earning their keep. If your daily check in genuinely adds nothing on a small co located team who already talk constantly, then it's fine to make it twice a week and see what happens. The point is to keep what helps and to quietly remove what doesn't help. So there's one rule, which is tailor deliberately. This keeps all of this healthy. Change things deliberately and inspect the result. There's a big difference between tailoring and drift. Tailoring is a conscious decision. We're dropping the fixed commitment because it keeps failing, and we'll check in once a month where the flow has improved. Drift is just quietly abandoning the hard bits because they are uncomfortable with no plan and no review. So whenever you adjust your process, do three things. Name the change, agree why you're making the change and set a time to look back and ask whether it actually help. If it did, keep it, if it didn't, then change again. That habit and changing on purpose and inspecting the result is Agile itself. The framework is just the starting point, but Agile is the mindset. So hybrids like Scrumban on are compromise. It's not a cop out. When they are done deliberately, they're often the most honest fit for our team really works. Thank you for joining me in this lesson. In the next one, we'll put all of this together, and we'll work out how to choose the right framework for your own project. I'll see you in the next one. 16. Choosing the Right Framework for Your Brief: Welcome back. We've looked at Scrum at Camban and at hybrid models like Scrumban. Now, the practical question, how do you actually choose? In this lesson, I'll give you a short set of questions to ask yourself about any project, and then we'll work through them together for our children's language learning app so that we can land on a real recommendation. So first of all, there is no universal answer. Let's kill that myth from the start. Anyone who tells you that Scrum is always right or that Cam Ban is always right is selling you something. The right framework depends entirely on your context, the kind of work you do, how predictable it is, and what your stakeholders need. The same team might use Scrum for one project and Cam Ban for another. So instead of picking a favorite and forcing your work to fit it, we start with questions about the work and let the answers point us to a correct framework. Here are the four questions that matter the most. Question one, is your work plannable or interrupt driven? Can you sensibly decide a couple of weeks of work in advance or does urgent stuff constantly arrive and reshuffle everything? Question two, does your work fit into sprint sized pieces? Are your tasks a fairly even size that finishes within a fortnight, or are they a wild mix of tiny and huge? Question three, do your stakeholders need predictable dates? Do they rely on knowing that something ships on a fixed rhythm, or do they mostly just want a steady stream of progress? Question four, is priority stable within a short window? Once you agree what's important this fortnight, does it hold or does it genuinely change every few days? Broadly, lots of planable, even sized, predictable, and stable points you towards Scrum. Lots of interrupt driven, mixed size, steady stream, and always shifting points you towards Camban. A mix points you towards Scrumban. Okay, applying it to our let's run our children's language learning app through those four questions. Question one, planable or interrupt driven. This app is mostly plannable. We are building features like quizzes and progress badges that can decide that we can decide on ahead of time. But there are some bugs. There's a steady trickle of bug fixes from live users, too, so it's mostly plannable but with some interruption. Question two, do tasks fit sprint sized pieces? Yes, largely a vocabulary quiz, a badge, summary email. These each break down into stories that we can finish in a fortnight. Question three, do stakeholders need predictable dates? Yes. Our stakeholders, including parents and the wider business, like the reassurance of seeing something new on a regular rhythm. Question four is priority stable within a fortnight, mostly, but not perfectly, a nasty bug affecting real children learning can jump in the queue. Finally, we have the verdict. So what is the verdict for our app? The answers lean towards Scrum. The work is mostly plannable sprint sized, and stakeholders value the rhythm. But that trickle of urgent bug fixes means pure Scrum would get disrupted. So the best fit here is Scrum with a touch of Cam ban discipline. So Scrum ban. We keep the fortnightly rhythm, we keep the planning and the retrospective because they suit the work, and they also reassure stakeholders. But we run a board with working progress limits, and we reserve a little capacity each fortnight for the urgent fixes that we know will arrive. No. Do the same for your own project. Answer the four questions honestly. Don't pick the framework because you like the sound of it or because you prefer it. Pick the one that answers point to. And remember, you can always adjust it later, deliberately as you learn. Okay, now, choosing a framework isn't about fashion or about dogma. It's about matching the tool to the work that is right in front of you. Answer the questions and follow where they lead and stay willing to change your mind. Thank you for joining me in this lesson. In the next lesson, you'll put all of this work into practice and you'll convert your project into a Cam Ban board yourself. I will see you there. 17. Practice: Convert Your Project to Kanban: Mm. Welcome back. This is a practice lesson, so it's your turn to do some work. We're going to take a project that's been running as sprints and convert it into a flowing Cam Ban board in Trello. Everything works on the free version of Trello. There are no paid features needed. Okay, here is what you are going to do. Take your existing board, keep the cards you've already written, and restructure the lists into a Caban flow. Add working progress limits to the active columns. Then reorder your backlog by priority and check that work can flow smoothly from left to right. Next thing is to set the limits. Remember, free Trello won't enforce these lists for you, so we use the naming convention. Change the name from doing to doing WIP three. The limits are now visible to the whole team. Last, make sure you also tidy your backlog and drag the most important card to the top, order the rest below it by priority. And then sanity check to flow. Is there a clear card ready to pull into or to do? Is anything stuck? A healthy Cam ban board has work flowing steadily rightward, and no column bursting past its limit. So what good looks like. When you have finished converting your board, check it against these three things. Your lists map the real stage as your work passes through. Your active columns have visible working progress limits, and your backlog is ordered top down priority with the most important work at the top. If all three are true, you've got a working Cam Ban board. Nicely done. Now you've taken a project from sprint to flow and you've got a Cam Bn board that you can actually run. Thank you for joining me. In the next lesson, we'll turn to the people around your project and start mapping and managing your stakeholders. I will see you there. 18. Identifying and Mapping Your Stakeholders: Welcome back. In this lesson, we're going to look at the people around your project. Every project has stakeholders, the people who are affected by what you build or who can affect it, and getting them right is often the difference between a smooth project and a painful one. By the end of this lesson, you'll know how to find all your stakeholders, how to sort them by how much they matter, and how much attention each one really needs. So, who is a stakeholder? Let's start with the definition because it's broader than most people think. A stakeholder is anyone who has a stake in what you build. They are affected by the outcome or they can shape it, and very often it's both. Some are inside the team, the people building the product, plus your product owner and your Scrum Master, but most are outside it. So your sponsor who pays for the work users for our children's language learning app, that means the children, but also their parents and their teachers. And the ones that are easy to overlook are the support staff and the legal or the compliance people that you only hear from when something goes wrong. If work touches them, they are a stakeholder. Before you can manage stakeholders, you have to find who they are, and the goal is to miss out nobody. There are two simple questions that surface almost everyone. First, who is affected, who uses the product, who pays for it, supports it, or has to live with the result. Second, who can affect us? Who can speed you up, slow you down, fund you or block a release. Then third prompt because these are the ones that bite you later. Who's easy to forget the quiet stakeholders. You end users who rarely sit in your meetings, your support team, that compliance person who says nothing for months, and then at the worst moment, says no, write all of these people down. A name on your list can be managed. A stakeholder that you forgot about cannot be managed. Now a long list isn't a plan. You can't give everyone the same amount of attention, and you shouldn't really try. So we sort them using a simple and a very well known tool, the power and interest grid. Picture a square split into four. The vertical as axis is power, how much influence this person has over the project. The horizontal access is interest, how much they care about it. This gives you four groups, and each one wants handling differently. Top right is high power and high interest. Manage these people closely. They are your key players, so involve them often. Top left is high power, but lower interest. Keep those people satisfied. Keep them happy and reassured, but don't drown them in detail that they don't want. Bottom right is lower power, but high interest. Keep them informed. They care a great deal, so keep them in the loop. And bottom left is low power and low interest. Just monitor these people. A light touch is plenty. So let's make all of that concrete with our language learning app. Your head of product has both power and keen interest. So they go into the top right. You manage closely and involve them in your reviews and your plan the company founder controls the budget, but isn't in the day to day, so they are top left, keep them satisfied, but spare them the detail. Teachers and parents have little formal power over your roadmap, but they care enormously. So they go in the bottom right, keep them informed, and legal and compliance sit in monitor for most of the project, low involvement, but note the catch, they must never be surprised. A quiet stakeholder can still stop a release. So what does each group actually get from you? Match the effort to the quadrant and you'll spend your energy where it counts. Manage closely means frequent and two way contact. They are in the room at reviews and planning. Keeps satisfied, means a short, regular summary, plus an early heads up before any big decision. Keep informed means a simple update they can read whenever they like, and crucially, no meetings. You're informing, not consulting, and monitor means a light touch only a quick word when something genuinely affects them and nothing otherwise. If you do this well, two things will happen important stakeholders will feel properly looked after and you'll stop pouring hours into the people who neither need nor want them. So yeah, very important to consider how much and how often. So find everyone, sort them by power and interest and give each group the right amount of attention. That map is the foundation for everything else in this specific section. Thank you for joining me. In the next lesson, we'll take your most important stakeholders and show them real work by running a sprint review that they actually value. I'll see you there. 19. Running a Productive Sprint Review: Welcome back. In this lesson, we're going to run a sprint review, which is the meeting at the end of a sprint where you show your stakeholders what you've built and gather their feedback. If this is done well, it can become one of the most valuable half hours in your whole process. But if it's done badly, it becomes like a dull status update meeting that nobody wants to attend. So by the end of this lesson, you'll know how to run a sprint review that earns you trust and actually gives you feedback that you can use. So let's just clear up what a sprint review is for because this is where some people can go wrong. Sprint review is showing a real working product. It's a live look at what got built. This sprint followed by an honest conversation about how it went. What it isn't is a slide show, and it's not a sign off ceremony, and it's not a rubber stamping ceremony. The old Agile phrase is working software over comprehensive documentation. And the review is where you live up to that. You showed the thing, not a slide deck about the thing. The point is the feedback that you can act on, not some applause. Great review needs about 10 minutes of preparation. And there are three main things. First, prep the demo. Have the working feature ready on a real device and test the happy path yourself first so that you're not debugging live in front of your sponsor. Second, invite the right people, the stakeholders who care about this particular work, the entire company. And third, set one goal, know the single question you most want answered by the time the room empties. Maybe it does the new quiz feel right to a teacher or something like this, walk in, knowing what you're there to learn. So here's a quick, simple agenda that works, and it's only four steps, and it'll be about half an hour in total. One is recap the sprint goal in a single line. What did we set out to do this sprint? Two, is demo the work, show it live and where you can, let them try it themselves. Number three, is to invite feedback, ask open questions, and then listen far more than you talk. Number four, talk about the next steps briefly. What does what we've just seen mean for the plan, and that's it. Recap, demo, feedback, and your next steps. If you take one habit from this lesson, take this one. Demo, don't present. Show the real thing on a device, don't talk about it on a slide. A working quiz, for example, that your stakeholder can actually tap on beats ten bullet points describing it every single time. There's nowhere to hide in a live demo, and that's exactly the point. Keeps everyone honest about what's really done. Two things make a demo land, Let them drive, hand over the device, and watch where they hesitate, where a real person pauses or frowns is worth more than any status report, and skip the polish. Rough but real beats slick but fake. You're not selling, you're learning. Show what genuinely works, what and so when the feedback comes and it will, three habits keep it useful. First, capture the feedback, don't defend, write it down and resist the powerful urge to explain why they're wrong. You asked for their view, so let them give it. Second, is Park scope changes. When someone says, Oh, could it also do this? That's a great idea for the backlog, not a change to this sprint. So note it, thank them and move on. Third, thank them genuinely. People who show up and speak up are genuinely doing you a favor even when the feedback hurts, especially then in handle the room like that, and people leave feeling heard, which means that they'll come back and they'll tell you the truth next time, as well. So a good sprint review is simple, really. Show some real work, listen very well, and then act on what you hear. So thank you for joining me in this lesson. In the next one, we'll deal with what happens when feedback changes the plan and how to absorb changing requirements without losing your focus. I'll see you in the next one. 20. Managing Changing Requirements: Welcome back. In this lesson, we're going to tackle something that every project faces. The requirements change. A stakeholder wants something new, a user does something you didn't expect, so priorities shift. In a rigid process, a change like this is crisis, but in Agile, it is normal. However, there is a real skill in absorbing change without your project descending into chaos, and that skill is what we will look at in this lesson. First up, a mindset shift in Agile, changing your mind is allowed. It is even expected and encouraged. The whole point of working in short cycles and showing real products is that you learn things, and learning should change what you do next. So the goal is not to freeze the plan and defend it. The goal is to change the plan on purpose deliberately rather than in a panic every time someone emails you a new idea. Welcoming change and losing control are not the same thing, and this lesson is about that key difference. So it helps to know where change tends to come from because none of these sources is a failure on your part. It's just reality. Stakeholders change their minds once they see the work. Often they only discover what they actually want when they look at what they've got. Real users behave differently to how you guessed that they would. The market moves, a competitor ships something else, a rule changes, a priority shifts above you and your own team learns as it builds, and the last one matters Information isn't a bug in your plan. It's the reason that you plan in short cycles in the first place. So, where should all this change actually land on your backlog? Think of the backlog as the shock absorber that stops every new request jolting the whole project. So three steps. First, capture it calmly. A new request becomes a note on the backlog, not an instant U turn. Second, don't act on reflex. Almost nothing has to change this very second. Let the dust settle before you make a move. Third, let the product owner reprioritize. The product owner or the PO weighs the new request against everything else that's waiting and decides where it really sits. That's their job, and it protects the team from being yanked around by whoever shouted something most recently. So how you absorb a change depends a little on which framework you're using, and we covered both earlier in this course. So in Scrum, you protect the current sprint. New work will wait for the next planning session. Today's commitment stays intact, so the team can actually finish what it started. In Cam Ban, there's no sprint to protect, so you simply reorder the queue. You can slot the new work in at the right priority and respect your working progress limits, which are the caps on how much progress can be simultaneously in progress. The tools differ, but the principle is identical. Change is handled deliberately at a sensible moment, not by dropping everything the instant a new request arrives. Here's a single phrase that will save you more project than almost anything else. Say yes to the what and negotiate the when. Say yes to the idea, then be honest about the trade off. So instead of a flat no or a reckless yes that quietly ruins your plan, you say something like, yes, we can add the parent dashboard, and here's what moves down the list to make room for that. You're not refusing the change. You are making the cost of it visible and you're letting the stakeholder help you choose. Nine times out of ten, once they see the trade off, they make a sensible call, and it's now their call rather than a fight. Stay flexible without drifting, a few guardrails can help you. Keep one clear priority order, a single ranked backlog, so the word important always has a meaning. Keep a definition of done that holds. Your quality standards don't get to flex just because they're planted. Handle change at the review by default, Batch feedback into that regular moment, rather than letting it arrive as a constant stream of interruptions and refuse gold plating. Say no to the shiny nice to haves that nobody actually asked for. Focus isn't something you have, it's something you choose again and again. So change is not a threat to a good Agile project. It is actually the fuel. The skill is about absorbing these changes on purpose through the backlog at the right moment. Thank you for joining me. In the next lesson, we'll look at status updates and how to keep your stakeholders informed without wasting anyone's time. I'll see you there. 21. Status Updates That Respect People's Time: Welcome back. In this lesson, we're going to have a look at how to write status updates that people actually read. So most updates are far too long or they're too vague or they are quietly ignored, but yours don't have to be. So by the end of this lesson, you'll have a simple structure that you can reuse every week, and you'll also have a good sense of when a status update requires a meeting and when it only requires a simple written note. Let's start with why so many updates fail because if you avoid these four traps, you'll be doing it correctly. First of all, they are too long, a wall of text that nobody finishes, where the one important line drowns in detail. Two, they're too vague. Making good progress tells a stakeholder precisely nothing. Third, they have no clear ask. If you need a decision, say so. And if you don't, ask yourself why that person's reading it at all. And four, it's the wrong audience. Deep engineering detail sent to a sponsor who only wants the headline. If you fix those four things, then you're already ahead of most teams. So here is the structure. Everything important fits under three headlines, and they all begin with P, so it's easier to remember. Progress, plan, and problems. Progress. What actually got done since last time, finish things, not in progress things. Plan what you're doing next and roughly when they'll see it and problems, what's blocked or what needs a decision stated specifically with a clear ask. And that is the whole template. If something doesn't fit under progress plan or problems, it probably doesn't belong in the status update in the first place. So here is a template that you can reuse, and let's fill it in for our language learning app so you can see how short a status update really can be. In progress, we've got the animals quiz shipped and progress badges are now live for 40% of users. Plan, the parents summary email is next, and we'll do a demo at Friday's review. Problems, there's an audio bug on the numbers lesson, and we need a decision on whether it delays the release. That is a complete, useful update in three lines. There's no filler, and the one thing you need from the reader, a decision is impossible to miss. Most updates don't need a meeting. So one decision you have to make is how to send this. The honest answer, most updates don't require a meeting at all, because your default should be written and asynchronous or async, which just means that people read it in their own time rather than all gathering at once. So a short skimmable note that lands in an inbox or a shared page, and that covers the large majority of updates. A meeting is only worth booking when you need discussion or you need a decision, something that back and forth writing can't handle very well. As a rule of thumb, a meeting whose purpose is only to share information is usually an email that got above its station, informing writing and meet to make decisions. So you have three headings, progress, plan and problems kept short and sent through the latest channel that does the job. So thank you for joining me. In the next lesson, it's your turn. We'll write a real stakeholder update for your own project together, and we will document it in Notion. I'll see you there. 22. Practice: Write a Stakeholder Update: Welcome back. In this practice lesson, you are going to do the work. We're going to write a real stakeholder update for your project using the three part structure from last time. I'll show you on one screen in Notion First, and then you can pause the video and you can write your own. So let's get started. So here's the exercise in four steps. Pick the audience, choose a single stakeholder or a group from your stakeholder map, and write specifically for them. Two, use the three parts, progress, plan and problems, and nothing else. Three, keep it short and sweet. If it doesn't fit comfortably on a phone screen, it's probably too long. And four, the most important step, send it. An update sending in your drafts is worthless. So writing it is the practice. Sending it is the job. So let's have a look at our Notion page. We have from before the stakeholder updates page. I'm going to open this page here, and I will show you the status report that I've added here for sprint one. I've added the date 22 May 2026 on a Friday, typically a good day to do status report. And the audience is head of product, which I've added here into this column sent to. And if we open this page, see the title sprint one status report with all the important information at the top. And in the body, we have the date, 22nd of May 2026, the status report with progress with two bullets, plan with two bullets and the problems with two more bullets. And it's as simple as that. Now, obviously, this is the status report that's been written. Now we need to send. If you click Share at the top here, if your stakeholders are in Notion, they have Notion accounts, you can send it to their Notion account through this field here or you can copy the link and you can just send them the link directly. And this is all available in Notion's free plan. You don't need any paid subscriptions to do this. So that's about it. So yeah, the most important thing is that you actually send it is the free page that you've added in Notion. So you can pause the video and you can write your own page now for one of your stakeholders. When you're done, check it against the four things that it fits on one screen, that it's short enough to read in under a minute, and that every line earns its place, so there's no filler, and if a line either informs nor asks for anything, cut it out. The ask is obvious. If you need something, it's impossible to miss, and it suits the reader pitched at what this particular audience actually cares about, not everything you happen to know. All four are true, then you've written an update that people will actually read. One last note here, the hardest part of the stakeholder communication isn't really the writing. It's the habit. A short and honest update sent every week routinely builds up more trust than a beautiful report sends once a quarter. So keep the structure the same each time, and it becomes a five minute job that you'll actually keep doing, and you will convey an attitude of competence and of proactiveness by doing this every week, and it shows good discipline in project management. So that's the end of this lesson. Well done for doing the practice exercise. Up next, we have measuring what matters most and the metrics. So the numbers that count. Well done for reaching the end of this lesson. Thank you for joining me, and I will see you in the next one. 23. Burndown and Burnup Charts Explained: Welcome back. In this lesson, we're going to look at the two most common progress charts in Agile, the burndown chart and the burnup chart. Both take a messy pile of work into a single line that you can read in seconds. So by the end of this lesson, you'll know how to read each one, what the shape of the line is telling you, and which chart to reach for depending on who's looking. So, why track progress visually? First, why bother at all? Because a picture beats a status meeting. One glance at a good chart should tell you whether the sprint is on track, and that quietly replaces 100 how's it going messages. So there are two things that make these charts worth a very small effort. They're fast. A trend line shows you in seconds what a paragraph update status can't they're honest, the line doesn't spin. It shows the real piece of work, whether that's comfortable reading or not. So here is burndown chart. Let's start with this one. The idea is in the name. Work burns down as it approaches zero. The vertical axis is the work remaining, usually in story points or number of tasks, and the horizontal axis is time, the days left of your sprint. At the start, all of the work is remaining, so the line starts high on the left. As the team finishes things, the line drops. If everything gets done, it reaches zero on the last day. The dash line is your ideal, a straight run from all the work down to zero at the pace you need to finish exactly on time. And the solid line is exactly what happened. The whole skill is reading the gap between the two so let's look at how we read a burndown chart. So what is the line telling you exactly? There are four shapes to recognize. If the actual line sits on the ideal, then you're roughly on schedule. You can carry on. If it stays above the ideal, then there's more work left than planned, so you're running behind. If it's below the ideal, you're ahead of schedule, or just as likely you over planned and didn't commit to enough work. And the one to watch for, which is a flat line where the line stops dropping for a day or two. That means that nothing is getting finished, something is stuck, and what's worth asking, and it's worth asking about at the next stand up. Now the burnup chart, this shows the same progress, but the other way up. So instead of work counting down, completed work climbs up. The rising solid line is the work you finished, climbing from zero, and there's a second line across the top, which is the total scope, the full amount of work that you're aiming to complete. Progress is the gap closing between the climbing line and the top line. When the completed line meets the scope line, you are done. So one of the superpowers of the burnup chart is the scope. Now, the top line might look like a small addition, but this is the superpower of the burnup because it shows you when the goalposts move. Here's the difference. On burndown, if someone adds work mid sprint, the line just dips oddly or flattens and you can't easily see why. Scope changes in this instance, are hidden. On a burnup, when the scope grows, the top line visibly jumps upward. The change is right there, it's honest and it's obvious for every that's exactly why a lot of teams prefer the burnup when they are talking to stakeholders. If the deadline slips because someone kept adding requests, the chart shows it wasn't the team that fell behind. I was the target that moved. The picture has the conversation for you. So which one should you use and when? Honestly, both of them are very useful you just choose them based on your audience. So you'd reach for the burndown inside the team because it's a simple daily check. Are we on pace to finish the sprint and then reach for the burnup with stakeholders because it shows progress and scope together, which means far fewer awkward surprises about why a date moved. But the real point is this, either chart beats no chart. A visible trend line changes the conversation from pinions to evidence. So just use one. So burndown counts work down, burnup, climbs it up, and the shape of the line does the talking. Thank you for joining me in this lesson. In the next one, we'll look at two key metrics for flow based work, the cumulative flow diagram, and lead time. I'll see you there. 24. Cumulative Flow and Lead Time: Welcome back. In this lesson, we are going to measure a Cam Ban system. So Cam Ban doesn't have sprints, so the burndown and burnup chart don't quite fit here. So instead, we watch the flow of work. We'll cover two tools that do most of the job, the cumulative flow diagram, and lead time. By the end, you'll be able to spot a bottleneck at a glance and say, honestly, how long your work really takes. So two Caban health checks. Because Caban has no sprint boundary, it measures flow instead, how smoothly work moves across the board, from left to right. Two tools carry most of the load. The first is the cumulative flow diagram which shows work piling up or moving smoothly across the board. The second is lead time, which shows how long work actually takes to get done. Together, they answer the two questions that matter the most in the flow based work. Is anything getting stuck, and how long are things taking? So let's have a look at the cumulative flow diagram, also known as the CFD, which stands for cumulative flow diagram. It looks a little bit complicated at first, but the idea is quite simple. Time runs along the bottom, and up the side are the number of cards. And each colored band is one stage of your board, and they're all stacked on top of the others. The bottom band is done, then you have in progress and then to do on top. Every day, you count how many cards are in each stage, and that sets the height of each band. So the whole picture shows you your work flowing upward and across. New cards join the to do band at the top, and then they travel down through the in progress into Dunn as they get finished. In a healthy Cam band system, the bands climb together in roughly parallel stripes. It's when the stripes stop being parallel that you actually learn something. Here's how to read the shape of these bands. Parallel bands means that everything is growing evenly, and it means healthy, steady flow work comes in and goes out at a similar rate. A band that suddenly widens is your warning sign. This shows a bottleneck, work piling up in one stage faster than it's leaving. If in the progress band balloons, you started form up far more than your finishing. A flat done band at the bottom is the worst of these. Nothing is actually being completed. And a flat top where no new work is arriving is usually fine, although occasionally, it's a hint that your backlog may be running dry. Now, let's look at lead time and cycle time, which is the second tool. These are easy to mix up, so let's pin them down using the board. So lead time is the whole journey from the moment a request lands in your backlog to the moment it's done. It's the clock that the customer feels because it starts the instant that they ask, and cycle time is shorter. It's the clock that starts when the team actually begins work on the card in progress, and it runs until it's done. Lead time is what your stakeholder feels and the cycle time is the team's working speed once they pick something up. If your cards sit in the backlog for weeks before anyone starts, your cycle time can look great while your lead time looks terrible, but only the customer will notice this. So what lead time tells you? Lead time is a single number, but it earns its keep in several different ways. First is predictability. Once your lead time is steady, you can make honest promises like most requests are done within two weeks. Second is early warning. If lead time starts creeping up, then something is clogging the flow, and you'll often see it here before it shows up anywhere else. And third is forecasting. Your past lead times are the best guide you've got to when a new piece of work will realistically be finished. So there's no guessing it's just what actually tends to happen in those cases. So the cumulative flow diagram shows you where work is stuck, and lead time tells you how long it really takes. Now, both of these turn a busy board into something you can actually reason about. So that's the end. Thank you for joining me in this lesson. In the next one, we'll step back and ask a bigger question. Are we measuring how much we produce or the difference it actually makes? I will see you in the next lesson. 25. Outcome Metrics vs Output Metrics: Welcome back. In this lesson, we're going to draw the single most important decision in measurement, the difference between output and outcome. It's the difference between being busy and being valuable, and getting it wrong is how teams end up working flat out while nothing that matters improves. So by the end of this lesson, you'll be able to tell the two apart and pair them up so your numbers actually point at value. So the most important distinction in this section is that output is what you produce, and outcome is the difference it makes. Output is the stuff that you ship, like features, tickets, story points, and outcome is what changes in the real world because of it. People learning more, coming back more, paying happily. And the uncomfortable truth is that you can ship a great deal and change nothing that matters. Lots of output with no outcome. Keeping those two ideas separate is what this lesson is all about. So let's look at output metrics first. These measure your activity, how much work the team produced. These are very useful, but they are slightly limited. Velocity is the classic. It's the number of story points that a team finishes per sprint, and it's a measure of throughput. Features shipped counts how many things you released and tickets closed, counts the sheer volume of work. It's what they all have in common. They tell you the team was busy and they tell you nothing about whether any of it actually helped. So output answers, did we build things? No did they matter. So now we come to outcome metrics, which is the other half, and this is where the real value lives. These are harder to measure, but they're worth far more. So for our children's language learning app, outcome metrics might be less in completion. Do learners actually finish the lessons that they start or weekly active learners or people coming back week after or are they drifting away? Or parent satisfaction. Do the people who pay for it feel like it's worth it? Now, these are harder to move and harder to fake because they measure whether the product is doing its job or not. So outcome answers the question that ultimately counts. Did it help? Now, this is the trap because it's an easy one to fall into. When output is all you measure, you start optimizing it, and you can get very busy going nowhere. So picture the quarterly review. For example, we shipped ten new features this quarter. Everyone nods and the team looks productive, but not one of those features moved less than completion. So that's plenty of motion with no progress. The features were real, but the value was not. So two habits to keep you out of that trap, the fix, tie every output metric to an outcome it's meant to move so that shipping always has a purpose beyond the shipping and the test. For any number that you track, ask if this went up and nothing actually improved, why am I measuring it at all? So the answer isn't to throw output metrics away. Velocity and the rest are genuinely useful for running a team. The answer is to pair each one with the outcome that it's supposed to serve. Features shipped should serve lesson completion. Velocity should serve predictable delivery dates. Bugs fixed should serve your app store rating and the trust that comes with it. Content added should serve weekly active learners. So you track them side by side, and the moment output climbs while its outcome sits flat, you've caught yourself being busy instead of being useful, which is exactly the warning that you want. So output is what you do, and outcome is what it's for, and the healthiest teams keep both of these in view. Thank you for joining me in this lesson. In the next one, we'll look at how even good metrics can be reused and what you should be careful never to measure. I will see you in the next one. 26. Avoiding Metric Misuse - What Not to Measure: Welcome back. This is a short but important lesson because a metric can be a double edged sword. We're going to look at how good numbers turn bad and the specific things that you should be careful not to measure, and a healthier way to hold metrics so they help your team instead of harming it. So let's begin. So start with one law of metrics worth memorizing. It's called Goodhart's law, and it goes when a measure becomes a target, it stops being a good measure. So in plain terms, the moment that you turn a number into a goal that people are rewarded or punished for, they'll start gaming the number rather than doing the real work behind it. So the measure was useful precisely because nobody was trying to move it directly. If you make that metric a target, then you break the very thing that made it worth watching in the first place. So here are four common ways that metrics can go wrong, so you can spot them coming. First one is velocity as a target. If you set a story point goal, and estimates will quickly inflate, the points go up, but the actual work doesn't. Next is individual output, measuring people rather than teams, which reliably kills collaboration because helping a colleague now costs you on your own scoreboard. Vanity metrics. Are numbers that look wonderful and mean nothing like app downloads instead of whether anyone actually uses the thing. And finally, is weaponized metrics. So numbers used to blame people, which simply teach everyone to hide problems rather than surface and fix them. So the important thing is to measure the team, not the person. One of the fastest ways to measure a team is measuring an individual rather than the team. Agile metrics are designed to describe a team's system, not an individual's worth. Velocity, lead time, cumulative flow, these describe how the flow works, not how hard someone tried this week. Moment is a metric used to rank people against each other. It stops telling the truth because everyone starts optimizing for their own number instead of optimizing for the shared result. So you measure the system and support the individuals. So how do you use the very same numbers well? There are three shifts in spirit. Use them for learning, not judging. Ask what a number is teaching you, not who's to blame for it. We watch trends, not snapshots. A single data point is noise, and the direction over several weeks is the real signal, and treat a metric as a question, not a verdict. A surprising number should start a conversation not end one. Same data, completely different effect on your team. So handled with metrics can guide you, but when they're handled carelessly, they can mislead you and they can damage the team. So keep them pointed at the system and keep them curious rather than accusing. Thank you for joining me in this lesson. In the next one, it's your turn. We will build a simple make metrics dashboard for your project in Notion. I will see you there. 27. Practice: Build a Metrics Dashboard: Welcome back. In this practice lesson, you are going to build your own metrics database in Notion. So we'll put this together for your project. I will build one on screen, and then you can pause and build one yourself. So, as always, Notion is free, runs in your browser, and everything today works on the free plan with no added add ons required. So let's go. Here's the exercise in four steps. One, pick three or four metrics, a deliberate mix of output and outcome, and resist the urge to track everything. Two, for each one, say what it's for. The question it's there to answer. Three, build a page, which is just a simple table in notion, and four, the step that actually matters is update it weekly. A dashboard nobody updates is just decoration. So a little note on choosing your metrics. Let's choose a balance set up for our language learning app so you can see the mix. Velocity, which is an output metric, answers, are we delivering at a steady pace? Lesson completion, which is an outcome, answers are learners finishing what they start with weekly active learners, another outcome, answers are people coming back. And then the open bug count, which is an output answers is quality under control. So not, it's the balance two numbers about what we're doing and two about whether it's working. Four metrics is plenty. So a dashboard you'll actually keep beats a beautiful one that you abandon. So keep it simple. Okay, so building it in Notion. You can build it in your free account using the following steps. So you're going to add a table with the columns for metric this week, last week and the trend, and then you'll have one row in the table per metric. And then in the final one, we'll have the trend arrow, whether it's up, down or flat, and this is the fastest read on the page. Okay? So let's have a look at what that'll look like in Notion. I've added a new page to the bottom called Metrics dashboard, and then inside I've added a new table. In this one, we're not going to use a database. We're just going to use a normal table. And I've gotten the four column titles at the top, the metric this week, last week and trend. I have the velocity, which shows an increase from last week. I have an increase in lesson completion percentage. So again, using the up arrow. Weekly active learners was up this week from last week, so there's another up arrow. Finally, we have open bugs, seven this week, we had nine last week, so the trend is going down. This is quite a positive metrics dashboard, I have to say, everything is going very well in this project. Let's get back to the show. Now, you can pause the video and build your own. When it's done, check it against these four things. So we've got a few metrics that are well chosen, three or four you trust, beat 20 that you ignore. You have a mix of output and outcome, not just what you did, but whether it actually helped. Third is that every metric has a purpose. If you can't say what it's for, then delete. And the last one is that it actually kept up. So the numbers are current updated on a schedule that you'll realistically keep. If you hit all four of these things, you've got a dashboard that will quietly make you a wonderful decision maker. So well done. You can now track progress with burndown and burnup. You can read a Cam Band system with cumulative flow and lead time, and you can tell output from outcome, avoid the common traps, and you can put it all together in one simple dashboard. So great work. Thank you for joining me. In the next section, we'll wrap up the whole of the intermediate Agile course, and we'll pull these threads together. I will see you there. 28. Common Intermediate Pitfalls: M So this is a dangerous stage. You know just enough. So here's the thing about this stage. The basics of Agile are easy to learn and unfortunately, easy to fake. You can run every ceremony perfectly, hit every meeting, fill in every board, and still completely missed the point of all of them. So that's the intermediate trap. Going through the motions flawlessly while the value quietly leaks away. So as we go through these pitfalls, notice that almost none of them are about doing the wrong thing. They're about doing the right thing, but for the wrong reason or with the reason completely forgotten. So, start with the process itself. We have four ways that the ritual survives, but the purpose dies. The first are cargo cult ceremonies, running the meetings by rote, going through the choreography with no real idea what each one is for. Next is the zombie stand up, a daily status report delivered to the manager instead of the team actually syncing with each other. Sprints that are secretly mini waterfalls. So a design week, then a build week, then a test week, which is the old sequential process wearing an Agile costume. And finally, a definition of done that quietly flexes, so done comes to mean nearly the same whenever a deadline looms. In each case, the shape is right, but the substance has gone. Next, we have people pitfalls. These are the subtler and the more expensive failures. The order taker PO, Product Owner who simply relays whatever's asked instead of actually prioritizing so that the backlog becomes a cue of everyone's pet request. Next is the hero culture where one person saves every sprint at the last minute, which looks impressive but is actually desperately fragile because the day they are off, it's all over. The forgotten stakeholder is the quiet person who you never mapped, who surfaces at the worst possible moment to block you, and then feedback theater. So dutifully asking for feedback at every review and then ignoring all of it, which teaches people to stop bothering. Next, we have metric pitfalls, which we had a look at in the last section and which you'll now notice everywhere. So the first is velocity as a target. The moment that points become a goal, estimates inflate to hit it, and the number rises while the real work doesn't. Output over outcome, celebrating ten shipped features that move nothing anyone actually cared vanity metrics, so numbers that look great on a slide but really mean nothing underneath, like download with no usage. And then finally measuring people. So taking metrics designed to describe a team system and turning them into individual scorecards, which reliably poisons any team. So the cure is usually the same, so some good news there. And it's basically just a single question. So for any ritual, any metric, any habit, ask, is this actually helping us deliver value? If practice isn't serving that, you're allowed to change it. The framework serves you. You don't save the framework. So and underneath that, sit the two habits the Hall of Agile rests on, inspect. So look honestly at what's happening, not the tidy version that's in your head, and adapt. So change one thing, watch what happens, and then keep what works. If you do those two repeatedly and honestly, you climb out of almost every single pitfall on this list. The intermediate danger isn't ignorance. It's going through the motions. So keep asking yourself whether each practice earns its place. Thank you for joining me. In the next lesson, we will turn that lens on you with an honest self assessment. Are you ready to actually lead a team? I'll see you in the next one. 29. Self-Assessment: Are You Ready to Lead?: Welcome back. So this lesson is going to be an honest look in a mirror. We're going to run through a self assessment so you can see clearly what you can already do and what areas you need to practice. So this isn't a test with a pass mark. It's more of a way to turn a vague, am I ready feeling into a specific and useful answer. So grab a pen if you like, and let's go through the self assessment together. As I said before, this is a check in, not an exam. Rule number one, be honest and specific. For each item, answer with a concrete example, not hopeful maybe. So yes, I did this last sprint does count, but I think I could does not count. The value of this exercise is entirely in how honestly you answer it. So a generous score that you didn't earn just robs you of a clear improvement plan, if that's necessary. Oh, can you run the mechanics, the moving parts of a sprint? Can you run a full sprint end to end? Can you plan it, run it, review it, and hold a retrospective? Can you set up your board? Can you build a scrum or a Caban board that other people can actually use, not just you? Can you prioritize a backlog ordering the work by value and keeping it ordered as those things change? And can you estimate work sensibly with points or T shirt sizes without pretending to a false precision? If you have four yeses here, then you are very confident with the concept of agile sprint. Next is can you handle the people? This is more important than the last section. This is the area that actually decides whether projects succeed or not. So can you map your stakeholders and say who matters and how much attention each one needs? Can you run a sprint review that shows real work and pulls in feedback that you can actually use? Can you absorb change, taking a new requirement on board without derailing the team? And finally, can you write a clear update that tells a stakeholder what they need in under a minute? These are harder than the mechanics of a sprint, and they matter more. The next one is can you read the signals? So these are the numbers that keep you honest. Can you look at a burn down chart or a cumulative flow diagram and say in plain words, what's really going on? Can you tell output from an outcome? Can you tell difference between being busy and being genuinely valuable? And can you spot metrics misuse? So noticing when a number is being gained or quietly turned into a weapon, if you can read these signals, then you can steer by evidence instead of by a gut. So add up your honest yeses. If it's mostly yes, then you are ready to lead a team. You can run the processes, you can handle the people, and read the signals, which is exactly what the job requires. So go ahead and do it. If you've got some gaps, that's not failure. It's just a map. So each no points straight at a section of this course worth revisiting. So nobody starts with a full set of yeses. The whole point of this exercise is knowing which is which, so you know where precisely to put your effort next. An honest self assessment really beats false confidence every single time because it tells you where you need to improve. Thank you for joining me. In the next lesson, we'll put it into practice on your actual project, reviewing your release plan and your metrics so far. I'll see you in the next one. 30. Project Review: Release Plan and Metrics: Welcome back. This is a hands on lesson, so it's your turn to do some work on your project. We're going to run a review of your projects so far, your release plan and your metrics, and we're going to pull them all together in one place, and that one place will be in Notion. So here's the exercise in four steps. One, gather your artifacts, your board, your backlog, release plan, and your metrics, and have them all in one place. Two, review the release plan and ask whether it's still realistic or whether the scope has quietly moved. Three is review the metrics and read what the trends are actually telling you, both outcome and output. And four, note what you would change. So just one or two honest adjustments for next time. Now, let's have a little deeper look at the middle two. So first, reviewing your release plan. If you aren't familiar with the term release plan, it's just a rough map of what is going to ship and roughly not a rigid schedule, it's a shared expectation. So for our language learning app, it might look like this. Release one, the core lessons they're already shipped. Release two was Badgers plus parents summary email currently in progress, and release three is the parent dashboard planned but not started. The review question here is simple and important. Does this still match reality? So plans drift, so maybe release two grew or maybe release three turned out to be more important than you thought. Reviewing the plan is where you catch that drift on purpose rather than being surprised by it at a later date. So, next up we have reviewing your metrics using the dashboard that we built last lesson. So don't just glance at the numbers, read them as a story. So steady velocity tells you your delivery pace is predictable, which is good news for any promise that you make. Lesson completion up tells you the core product is genuinely landing with the learners. Weekly active users up tells you people are coming back, not drifting away, and open Bugs down tells you quality is under control. So read together like that, these four numbers give you a surprisingly honest picture of the health of the whole project. So here is a simple review format to follow. To capture all of this, you only really need four honest headings. What's going well? So name the wins plainly because they are genuinely easy to forget when you're under pressure. What's stuck? So the bottlenecks and the blockers you keep quietly working around. Next is what's changed. Is it the scope, the priorities or the people that have shifted since you started? And then finally, what's next? So one or two things that you'll deliberately do differently in the next sprint. That's your review structure. So putting it all into one page in Notion. In that single page, you should have a release plan. You should have your velocity log and then some review notes. I'll show you exactly what this would look like in Notion. So I've added project review. Now, you're probably not going to have a project review in week one, but as we've only done one week in this project, so far, I'm just going to put Week one. In this page, I have two links to release plan and Metrics dashboard. So in order to do that, you can copy the link, and then you can paste it. Show you what that looks like. So if you paste it it'll paste the link directly. And then if you just click mention, it will give you the direct link to that page. So in this page, I've also added the link to the metrics, dashboard, and then below, I've put what went well, what's stuck, what's changed, and what's next. So under those headings, that's heading two, by the way. You can put a bulleted list and you should answer those four questions. So that's what the skeleton of this page should look like in no now let's have a look at what good looks like. So pause the video, build your own review. When it's done, check it against these four things. One, that it's honest, that the stuck column isn't empty because a review with no friction isn't a real review. It uses evidence. Your claims are backed by the board and the metrics, not just by feeling. It's short. One page could be read before a meeting. And finally, it ends in action, at least one concrete thing that you'll change for next time. If you hit those four things, then you've done something that most teams don't quite manage, which is to stop and to genuinely learn from their own project and learning from the health of their own project. So a good review turns a busy few weeks into lessons that you can actually use, and that habit is what separates people who repeat their mistakes from people who compound their skills. So thank you for joining me. In the final lesson, we'll look at where you go from here and the road ahead in your Agile project management. So see you for the next one. 31. What's Next: The Road Ahead: Welcome to the final lesson of this course. In this final lesson, we're just going to zoom out. We're going to look at how far you've come, and we will name the shift that comes next and point you at the road ahead. So this is a short one, so let's make it count. So first of all, is just to look how far you've come. So give yourself some credit because you've covered a great deal in this course. And let me just summarize it very quickly for you. So you've now studied frameworks. You can choose and run Scrum or Cam Ban or a sensible hybrid of the two rather than following one by default. With stakeholders, you can map the people around your project. You can run reviews with them, and you can keep them updated without wasting anyone's time. And finally, the metrics, you can measure progress, flow, and real outcomes honestly, and you can also spot when a number is misleading you. So this is the toolkit of someone who can genuinely run an Agile project. Well done. So from doing to leading, this is the shift that comes next. So it's not just more of the same. So far, you've learned to run an Agile project well. The next step is different in kind. It's about leading the people and improving how an entire team works over time. So running a good sprint is a skill, but building a team that runs good sprints without you standing over them and that keeps getting better on its own is a different and a deeper skill. That move from doing Agile to leading it is the next stage of your growth as an Agile leader. Where your Agile journey goes from here, following on from intermediate, first of all, is scaling, so how to coordinate more than one team without drowning everyone in process. Next is quality and risk, how to build quality in from the start and handle risk sensibly without heavy paperwork. Next is continuous improvement. So Kai's end, keeping an eye on team health and staying sharp without burning people out. And finally, is coaching, growing a team that improves itself and leading without controlling. So, in other words, it's the leadership half of Agile to go with the delivery half that you've just mastered. So that's the end of this course. Congratulations. You started it, able to follow an Agile process, and you are finishing it, able to run one with good judgment with the people on side and with honest numbers to steer by. So that's a very real achievement, and you should be proud of it. So thank you very much for joining me and for all the work that you've put in and good luck out there on your Agile project management journey. 32. Class Project: Plan a Multi-Sprint Release & Create a Project Management Dashboard: Now it's time to expand your Agile project. For your class project, you build on the project you've been developing throughout the course by planning a complete multi sprint release and creating a simple project management dashboard. Start by defining a release goal and breaking your work into multiple sprints. Then estimate your backlog, prioritize your work, and forecast how your project might progress over time. Next choose the framework that best fits your project. You can continue using Scrum, convert your work to Caban, or create a hybrid approach based on your project needs. You'll also identify your key stakeholders and prepare a project update that communicates progress, priorities, and any important changes. Finally, create a simple metrics dashboard using Notion or any other tool of your choice. Include metrics that help you understand your project's progress and support better decision. You're finished, upload screenshots of your release plan, project board and metrics dashboard to the project gallery, and feel free to include a short explanation of why you chose your workflow and how you approached planning your project. The goal isn't to build a perfect project. It's just to demonstrate that you can think beyond a single sprint and manage a project from a broader, more strategic perspective. 33. Congratulations! What's Next? : Congratulations on completing the course. You've now moved beyond the fundamentals of Agile and developed a much broader understanding of how successful projects are planned, managed, and delivered over time. Throughout this class, you've learned how to build release plans, estimate work more effectively, choose between Scrum and MBA, communicate with stakeholders, and use meaningful metrics to guide your decisions. Remember, Agile isn't about following one framework perfectly, but about continuously learning, adapting, and choosing the practices that best support your team and your project. If you haven't already, make sure to upload your project to the gallery. I'd love to see how you've planned your release and structured your workflow, if you've enjoyed the class, please consider leaving us a review. It helps us improve future classes and helps other learners discover the course. Thank you for joining me and I hope to see you in the next class.