Project Management for Beginners Masterclass: Run Your First Agile Project

1. Welcome To The Agile Project Management Beginner Masterclass!: Mm hmm. Welcome to the Agile Project Management for beginners course. Have you ever wondered how successful teams organize projects, manage changing priorities, and consistently deliver results? If so, you're in the right place. My name is Luke Phillips, and I'm a project manager with seven years of experience working with Agile methodologies across different types of project and teams. In this course, I'll help you understand Agile Project Management in a practical, beginner friendly way. One of the biggest challenges when learning project management is that many of these courses focus on theory without showing how projects actually work in practice. That's why this class is designed around building a real project step by step. Together, we'll explore the Agile mindset. We'll learn the principles behind Scrum, understand how product backlogs and user stories work, and we will use popular tools like Trello and Notion to organize our project. You'll learn how to plan sprints, prioritize work, estimate tasks, run meetings, manage changes, and review progress, just like Agile teams do in real organizations. Throughout the class, you'll apply everything to a project brief of your choice, helping you gain practical experience instead of simply memorizing concepts. So by the end of this course, you will understand the complete Agile project lifestyle and you'll have your own project workspace, backlog, and sprint plan ready to showcase. Let's get started. 2. The Agile Mindset: Introduction To Agile Project Management: Hi, and welcome. In the next 5 minutes, I'm going to introduce you to one of the most talked about ideas in modern project management. Agile. By the end of this video, you'll know exactly what Agile is, where it came from and why so many teams far beyond the world of software have adopted it. I'm Luke, and I've spent the last seven years or so working as a project manager in Edtech. That's educational technology, leading digital learning projects with cross functional and international teams, and Agile has been a part of my daily working life for all of that time, and I want to demystify it for you. So what is Agile? Let's start simple. Agile is a way of managing projects that breaks the work into small manageable chunks and delivers value step by step, rather than all at the end. To understand why this matters, picture the traditional alternative, which is called waterfall. In waterfall projects, you plan everything upfront, and then you execute each phase in order, requirements, design, build, test, launch. This works beautifully, but only as long as nothing changes. And in the real world, things change constantly. So customers might change their minds, markets may shift, new information may appear halfway through, and Agile was designed for exactly that reality. So instead of one big plan and one big launch, you work in short cycles, usually one to four weeks. And at the end of each cycle, you have something real to show, get feedback on, and improve. So where did Agile come from? In February 2001, 17 software developers met at a ski lodge in Utah, and they were frustrated that traditional document heavy project management wasn't working for software. So over that weekend, they wrote the Agile Manifesto. It's four short values and 12 supporting principles. And the four short values are worth memorizing. So Agile values individuals and interactions over processes and tools. It values working products over comprehensive documentation. It values customer collaboration over contract negotiation, and it values responding to change over following a plan. Now notice the word over. The items on the second line still matter. You need processes, documentation and plans, but when you have to choose, you should prioritize the things on the top. Now, although Agile started in software, those values apply almost anywhere you're creating something new under certainty, whether it's marketing, product design, education or even healthcare. So what does Agile actually look like day to day? At its heart, it's a loop. You plan a small piece of work, you build it, you review it with stakeholders, you learn from the feedback, and then you do it all again. Agile, this short cycle is often called a sprint, and they're typically two weeks long. At the start, you pick a small set of items from a prioritized to do is called a backlog. Then the team builds those items, shows the results, and then they reflect on what went well and what to improve. And then the cycle repeats. Agile is a mindset, but to apply it, most teams you will use a specific framework. The two most common ones you'll hear about are Scrum and Cam Ban. Scrum uses those fixed two week sprints with defined product roles like product owner and Scrum Master. You have regular ceremonies, such as planning, daily stand ups and reviews and retrospectives. Cam Ban, on the other hand, is more continuous, work flows across a visual board, and the focus is on limiting how much is in progress at once. Many teams will use a real blend of both. Why it matters. Why has Agile become so dominant? There are three reasons. One, it reduces risk because problems surface early, not at the end. Two, it keeps teams aligned with customers because you're constantly checking in with them instead of guessing. And three, it respects people by trusting small teams to organize their own work. Perfect for remote work. To recap, Agile is a mindset for delivering work in short feedback driven cycles. It comes from the 2001 Agile Manifesto, prioritizes people, working output, collaboration, and adaptability, and in practice, usually takes the form of Scrum, Cam Ban, or a hybrid of the two. So what I'll leave you with Agile isn't really about sprints or stand-ups or sticky notes on a wall. They are just the tools. At its heart, Agile is a way of admitting something honest. We don't always know the answer upfront, and the smartest thing we can do is build a little, learn a little, and keep getting better. So whether you go on to manage software teams, run marketing campaigns, or coordinate learning programs, that Agile mindset will serve you well. Thank you for watching and good luck on your project management journey. 3. Who This Course Is For And What You’ll Build: Hi, and welcome back. In the last video, we looked at the big picture of what Agile is, and we compared it to the traditional waterfall project management style. In this video, I want to do two things. First, I want to help you check that this is the right course for you. And second, I want to show you what you're going to walk away with by the end. This isn't one of these courses where you just watch a load of theory and then wonder what to do with it. By the end of this course, you will have built something real. So this course for you? There are four kinds of people that this course was built for. First of all, it was built for complete beginners. If you've heard the word Agile thrown around at work or in job ads and you're not quite sure what it means, you are in exactly the right place. You don't need any prior knowledge to take this course. Second, this course was built for people who are moving into project management or into a product role. So maybe you've been promoted or you're trying to break into the field. Agile is the language most modern teams speak, so you'll need it, and vocabulary actually goes a long way in project management. It shows you are at the very least aware of the concept. The third type of person is people who are already managing projects in a traditional way who suspect that there is a better way. There is, and you're going to learn about it here. And the fourth type of person is people who don't work in software at all. So in marketing, in events, education, health care, small business owners, Agile applies to almost anything where you're creating something new and you don't have all the answers upfront. So if that's you, this is the right course. One quick note on who this course isn't for. If you are already a certified Scrum Master with years of experience, this course will feel quite basic. That's okay. The intermediate and advanced courses in this series go much deeper. So just make sure you start where you actually are. So let's look at what you build. You've got three real portfolio worthy artifacts, not just notes from a course. So what are you actually going to build? This course is project based from start to finish. You'll pick a project brief in the next video. You will have three to choose from. And then everything you learn, you will apply to that project. By the end of the course, you will have three things that are genuinely portfolio worthy. First thing you'll have is a fully populated product backlog. That's the prioritized list of work that any real Agile team needs to start from. Two, you'll have a sprint board showing one full sprint cycle that you've actually run, and three, you will have a written sprint retrospective document where you'll reflect on what went well and what you would change next time. These are the same artifacts any working product team produces every two weeks. And you can put these things into a portfolio. You could show them in a job interview, and you can use them as templates for your next real project. They're yours. So let's have a look at what you'll need. These are all free tools. There's no paid plans required. There's no trials. There's no sign up hassling. The two free tools we will use are Trello and NS both have free tiers. We'll never ask you to pay for anything or to sign up to any trial. And then the third thing you'll need is a pen and paper. So sometimes the lowest tech option is the best thing for thinking. So next up, pick your project. You will have a choice of three briefs. You will have one choice, and then we will build. So pick the one that you think fits you best. Don't overthink the choice. In the next video, I'll help you decide on your brief. So I will see you there. 4. Choose Your Project Brief: Edtech, E-Commerce, or Events: Welcome back. Now for the fun part. In this video, you're going to pick the project you'll work on for the rest of this course. I have prepared three different briefs for you. They cover very different industries on purpose, mainly to show that Agile isn't only for software projects. You'll see what I mean in a minute. So don't stress about this choice. Pick the one that excites you the most or the one that's closest to your real job. There's no right or wrong answer here. Any of these briefs will serve you well for this course. So brief A is Edtech educational technology to build a feature for a children's language learning app. So imagine you are the product manager or the project manager at a small Edtech startup. Your team is building a children's language learning app, and the first version is live, but engagement drops off after week two. Your job is to plan and run a sprint that ships a new feature designed to bring kids back. Maybe this is a streak system or a new game mode or some rewards. This one's up to you. So pick this one if you like consumer products or apps. You in or near education, and you want to think about user motivation and engagement. Brief B is E-Commerce to launch a new product line for a sustainable retailer. So for this one, you are working with a small online retailer who sells sustainable home goods. They want to launch a new product line, for example, eco friendly kitchen all in time for the holiday shopping season. Now with this one, you've got lots of moving parts. We have photography, we have product descriptions, we have pricing, supplier negotiations, marketing, even the website. So your job is to plan and run a sprint that gets the launch ready. I would pick this one if you like business non operations or if you're interested in marketing or entrepreneurship in general, or you want a brief with lots of cross functional and moving pieces. If C is an industry event. So organize a two day hybrid conference. Hybrid conference means you have people attending in person and online. So with this project, there is a venue to book. There are speakers to invite. There are sponsors to chase. We have a website to build. You have Tech to set up and a marketing campaign to run. The event is in three months, and your job is to plan and run a sprint that moves the project forward. I would pick this one specifically if you don't work in tech. Events is the brief that proves Agile works outside of software. If you're in marketing operations, HR or any non IT field, this one is probably your best fit. So how to choose. These are the three questions if you are stuck. One, which industry is closest to your actual job? If your day job is in retail, pick E-Commerce. If it's not in tech, pick events. The closer the brief is to your reality or what you want to be doing, the more you'll get out of this course. Two, which one excites you the most genuinely? You're gonna spend at least 3 hours on this, so pick the one you'll enjoy. And number three, if you're still stuck, pick events. It's the most accessible to beginners, and it's probably the best one that shows off all of the advantages of Agile Project Management. So, pause the video, pick one brief, write it down. In the next video, we'll get into the Agile Manifesto itself, the four values and 12 principles that underpin everything else. I will see you there. 5. The Agile Manifesto: Four Values, Twelve Principles: Welcome back. In the introduction video, I mentioned the Agile Manifesto, which was the document that 17 developers wrote on the ski lodge in Utah, if you remember this. In this video, we're going to dig into what it actually says. We're going to look at the four values and the 12 supporting principles. Now, this is an important video. This is the philosophical core of everything else in the course and vocabulary matters. So you might want to take out your pen and paper for this video. So first of all, why manifesto? Well, there was a problem that needed solving. And here is your context. So in the late 90s, software projects were failing, big ones and expensive ones, mainly because teams would spend months and months writing detailed specifications, and then more months actually building what those specifications said only to deliver something that the customer no longer wanted. They didn't want it because markets had moved, requirements had changed. So the plan was perfect, but it was the result that was useless. This was the main problem. Now, in February 2001, 17 developers met at a ski resort in Utah. Now, they didn't agree on the methods, but they all agreed that there had to be a better way. So over the weekend, they wrote a very short document, which surprisingly is only 68 words long. So let's have a look at it. Now, that document mainly consists of the four values, and we value the items on the left more than we value the items on the right. The manifesto reads, we are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value, and then we have the four statements. So value one, individuals and interactions over processes and tools. This means a great team with mediocre tools will outperform a mediocre team with great tools. So talking to each other is very important. Don't hide behind the software. Value two, working software over comprehensive documentation. So what this actually means is 100 pages of beautiful specs that nobody reads are worth way less than a small working prototype that people can actually use and try. So build something real as soon as you can. Third value, customer collaboration over contract negotiation. What this means is don't waste your energy arguing over exactly what was agreed in the original brief. Work with your customer, collaborate with them, discover what's actually needed. And the fourth value is responding to change over following a plan. Now, what this means is a plan isn't like a hypothesis. It's not a contract. When reality contradicts the plan, change the plan. And here's the bit that people miss. Manifesto ends with, that is, while there is value in the items on the right, we value the items on the left more. So these traditional things like processes and documentation, contracts, and plans, they all still matter. They're not a bad thing, but they are not the priority when push comes to shove. So let's look at the 12 principles. Now, grouping the principles makes them a little bit more memorable. So I'm not going to read all 12 principles one after another. That would be quite tedious. Plus, you can just read them yourself in a couple of minutes. Remember, it's only 68 words long. So, instead of going through one to 12, I'm going to group them into four different themes. Now, the first theme, deliver value early and often. The first principle says, satisfy the customer through early and continuous delivery. And the third value says, deliver working software frequently, weeks rather than months. Translation, what this actually means, get something real in front of users as fast as you can and then keep doing. The second theme, welcome change. The second principle of the 12 literally says, welcome, changing requirements, even late in development. Now, that sounds crazy if you come from the traditional waterfall project management. But the Agile bet is that change is going to happen anyway, so you might as well build for it. The third theme is people first. Several principles can be grouped in this theme. You build projects around motivated individuals and trust them to get the job done. Face to face conversation is the most efficient way to share information, and the best architects and designers emerge from self organizing teams. If you notice a pattern, Agile trusts the people working in the projects. The fourth theme is sustainability and reflection, two principles that I love. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely. In other words, no death marches. And the last principle at regular intervals, the team reflects on how to become more effective. You have built in continuous improvement. So let's have a look at what this means in practice and what the manifesto means for your project. So what does it mean when you're doing your project brief? It means prioritize shipping something small over planning something perfect. This means when your stakeholder changes their mind, treat that as useful information, not as a problem that you should stress over. Means trust your team, reflect often on what you've done, improve constantly. Now, none of this is rocket science. It's mainly common sense that's been forgotten by these big organizations who are very stuck in their ways. The manifesto's job is to remind us. So in the next video, we will tackle the misconceptions of Agile Project Management because, you know, as it's so widely used, these misconceptions arise. It's surprising how much at 68 word document can get misunderstood. So in the next video, we'll look at Agile myths, debunked. See you there. 6. Agile Myths and Misconceptions: Welcome back. If you only remember one thing from this video, make it this. Most of what people call Agile isn't. Now, there is a huge gap between what the manifesto says and what teams actually do. So let's look at the misconceptions and debunk the myths. Myth number one, Agile means no planning. This one drives me nuts, which is why it is number one. The manifesto says responding to change over following a plan, not never follow a plan. Agile teams plan constantly. They just plan in smaller chunks more often, and they're willing to change those plans as they learn. If anyone tells you we don't do planning, we're agile, they're not agile. They are just disorganized. So beware. Myth number two, Agile means no documentation. Again, it drives me nuts, as well. The manifesto says working software over comprehensive documentation, that does not mean zero documentation. It means don't write 200 pages that nobody reads. Write documentation actually helps a clear user story, a simple decision log, a one page architecture diagram all of those are welcome. Myth number three, Agile is just Scrum. No. Scrum is one Agile framework. There are other frameworks including Caban, extreme programming, lean, and Scrumban, which is the hybrid. Agile is the mindset, the values and the principles that we just covered, and Scrum is one specific way to apply those principles. So when someone says, Are you doing Agile, most honest answer is usually we're doing Scrum, which is a flavor of Agile. We'll go deeper into this in the second course. M number four, Agile is only for software. The manifesto was written by developers, but the principles and the values are universal. Marketing teams use Agile, hospitals use Agile, schools use Agile. Even construction companies use it. So if you're creating something new and uncertainty exists and you have lots of stakeholders, then Agile applies, and it's very effective. So that's why one of your project briefs on this course is an event project, not a software one. My number five, Agile means faster. This is possibly the most damaging myth because it's how executives are sold on Agile projects. It'll make us ship faster. I mean, sometimes it does, but the real benefit of Agile isn't the speed. It's the adaptability. You focus on things that matter the most because you've learned what those things are throughout the project. You might actually do less work overall because of this. So speed is a side effect. Not the goal. Now, in the next video, we're going to spot the Agile behavior. You'll get a chance to test this yourself. We'll have a quick, practical exercise. I'll show you some scenarios, and you decide which ones are actually Agile and which ones are just dressed up to look agile from a superficial perspective. So I'll see you then. 7. Practice Exercise: Spot the Agile vs. Non-Agile Behaviour: Welcome back. Now we come to our first practice exercise, Agile or not. I want you to spot the Agile behavior. I'm going to give you five short scenarios. For each one, pause the video and decide, is this Agile behavior or not? And then I will give you the answer. So first, scenario one, a team writes a detailed 80 page specification document before a single line of code is written. Now pause if you want. Is this Agile or not Agile? This is not Agile. So this is classic waterfall thinking, big planning upfront, and then you build, which goes against the Agile methodology. So scenario two, a team ships a small feature every two weeks, gets feedback from real users, and uses that to decide what to build next. Pause here if you want. Is this Agile or not Agile? This is Agile. We have short cycles. We have real user feedback and decisions based on what's been learned during that pilot, you might call it. Okay, scenario three. The customer asks for a change halfway through the project. The team replies, Sorry, that's not in the original brief. Pause here, if you want. Is this Agile or not Agile? This is not Agile. So remember, we have the third value customer collaboration over contract negotiation. Welcome the change. Do not fight it. Now, scenario four, the team has a 15 minute meeting every morning where each person shares progress, plans, and any blockers. They also talk about what they did yesterday, what they're doing today, things like this. Is this Agile or not? This is Agile. This is the classic daily stand up, which is supporting Principle six. Face to face conversation is the most efficient way to share information. And scenario five, a team holds a meeting every Friday to discuss what went well, what didn't, and what to try next. Pause here. Is this Agile or not Agile? This is Agile. This is known as a retrospective. This is Principal 12, which is at regular interviews, the team reflects on how to become more effective. So they look at the things that went well, things that failed. So score yourself. How many did you get? Don't worry if you missed a couple. These concepts and these values will sink in over time. But that's the end of Section one. 8. The Building Blocks: Sprints, Increments, And The Empirical Loop: In this section, we'll get into the engine room of Agile. In the last section, we talked about the mindset, and in this one, we're going to talk about the mechanics. By the end of this video, you'll know what a sprint is, what an increment is, and you'll also know the simple three step loop that Agile teams use to deliver value. So let's get into it. What is a sprint? A sprint is a fixed length container for work. It's a fixed period of time during which a team works to complete a small agreed upon amount of work. Length is consistent. It's usually one, two, three, or four weeks. Two weeks is by far the most common. And the keyword there is fixed. A sprint always starts on the same day and ends on the same day. You don't extend it because the work isn't done and you don't shorten it because someone's on holiday. The time box is sacred. Why is that important? Because predictability is one of the things that Aja gives you. After a few sprints, you start to learn what your team can realistically get done in two weeks, and that information is gold for planning. So you don't extend it, you don't shorten it. That time box is fixed. Next, what is an increment? This is what you produce at the end of every sprint. It's a small but complete piece of value that could be released or used, something real. The crucial point here is the word working. It's not a half finished feature. It's not a wireframe. It's not a pile of notes or documentation. It's a small but complete piece of work that in value, could be released or used. For your Edtech project, an increment might be a working streak counter in the for E-Commerce, it could be a finished product page. For events, a confirmed venue booking and a published date, things like this. So real, finished, and usable. Next, we have the empirical loop. We have three words. This is the whole engine of Agile. This is probably the most important concept in this video. It sounds fancy, but it's just three plain steps that repeat again and again and again. Transparency, inspection and adaptation. Transparency means everyone can see what's going on. The work is visible on a board, in a backlog, somewhere everyone can look at it. We have no hidden progress and no surprises. Inspection means we regularly look at what we've produced and how we're working. We don't just plow ahead, we stop and check. Is this what the customer wanted? Are we on track? Is something blocked? And adaptation means we change based on what we see. So if something isn't working, we change it. If a stakeholder gives us new information, we update the plan. We don't carry on doing the wrong thing just because it was in the original plan. We have to adapt. Transparency, inspection, adaptation. This is the entire engine of Agile. So let's look at how it fits together. You have your sprint increment, and repeat. This is basically what Agile is. You run a sprint. Let's say it's two weeks long. During the sprint, you make the work transparent on a board. At the end of the sprint, you've produced a working increment. Then you inspect. You show it to people. You ask what they think, you reflect on how the team work together, and then you adapt for the next sprint and you do it all again. This is the fundamental rhythm of Agile work. Sprint, increment loop, sprint, increment, loop. Oh. Next up, we have the three roles that make it work, the product owner, the Scrum Master, and the development team. I'll see you for the next one. 9. Roles: Product Owner, Scrum Master, Development Team: Welcome back. In this lesson, we will look at the three roles that make Agile teams work. By the end of this video, you'll know who does what and why each role exists. We're focusing on the Scrum framework here because it's the most common and the role definitions are the clearest. So let's begin. First, we have the product owner, also known as the PO. This is the voice of the customer on the team. Their job is to decide what the team builds and in what order. They own the product backlog, which is that prioritized list of work, and they are the person who says, This is what matters most. Do this next. Crucially, the PO is not the team's boss. They don't tell the team how to do the work. They tell the team what to do and why it matters. The how is up to the team. A good product owner spends time with customers. They understand the business, and they make hard decisions about priorities. They say no a lot because there's always more demand than they have capacity for. Your project brief, you might be playing this role yourself, which is completely fine. Just remember the product owner mindset, be clear about priorities, talk to your users, and make trade offs. The next role is the Scrum Master, also known as the SM. This role helps the team work well. Now, this is one of the most misunderstood roles in Agile. Scrum Master is not the project manager. They don't assign tasks. They don't track who did what. They don't chase people for updates or for deliverables, and they're not the boss. What they actually do is help the team work well. They facilitate the meetings. They remove obstacles, things blocking the team from progressing, and they coach the team on Agile practices. They also shield the team from any outside interference. One of the best analogies here is that the Scrum Master is like a football coach. They don't play the game. They don't tell the players how to kick the ball, but they create the conditions where the team can perform at its best. Small teams, the Scrum Master often doubles up with another role, maybe the senior developer. All the responsibility is shared, which is completely fine. As long as the work gets done, it doesn't really matter. The next role is the development team. These are the people who actually build the product. Now, despite the name, this isn't just software developers or programmers. The development team is everyone who actually builds the product. Software, that would be developers, but also designers and testers. For a marketing project, it would be copywriters, designers, marketers. For an event, it's the operations people, the speaker coordinators, the venue manager, two key things about the development team. One is that they self organize. Nobody tells them how to split up the work. They figure it out themselves. And two, they are cross functional. The team has all the skills it needs to deliver an increment without depending on outsiders. The typical size is three to nine people, big enough that you have all the skills that you need and small enough that everyone knows what's going on and who's doing what. So let's have a look at how these three roles work together. We have three responsibilities and very little overlap. The product owner decides what to build. The development team decides how to build it, and the Scrum Master makes sure that the process runs smoothly. These three roles and responsibilities have very little overlap. And this clarity is one of the reasons why Scrum works. Everyone knows whose decision is whose. If a stakeholder wants a new feature, they talk to the product owner. If a developer is blocked, the Scrum Master helps unblock them. The team needs to decide a technical approach, they decide it themselves. Now, in real life, especially on small teams, one person might do two roles. You might be the product owner and a Scrum Master. Or, as I said before, the senior developer might also be the Scrum Master, which is completely normal. The roles are about responsibilities and not specifically about job titles. So thank you for joining me in this lesson. Next up, we will look at the product backlog. We'll look at what goes in it, how it's structured, and how to build a good one. I'll see you in the next one. 10. The Product Backlog Explained: Welcome back. In this lesson, we're going to dig into the product backlog. This is probably the single most important artifact in Agile work. And once you understand it, a lot of other things will start to click into place. So by the end of this video, you'll know what a backlog is, what goes in it, and what makes a good one. So what is a product backlog? Let's look at a simple definition with three keywords. Product backlog is a single prioritized ordered list of all the work that might be done on a project or a product. Now, there are three keywords here in this definition. The first is single. There is only one backlog. There's not one per team member. There's not one per stakeholder. We have one backlog. The next keyword is prioritized. The items at the top of the list are the most important ones. And the third is ordered. There is no tie. If two items are equally important, the product owner picks one to have a higher priority than the other. Think of it like a wish list with an order. Everything that anyone wants the team to do eventually lives in this list, and the order tells the team what to work on next. So what goes into a backlog? Generally, we have three types of items in a backlog. They all go in the same list. The first are features. So these are new things that you want to build. So, for example, add a streak counter, build a checkout page or book the venue. Second item would be fixes. So these are things that are broken or need improving. For example, the login button doesn't work on Android devices. The product photos are too dark. The third are chores. So these are technical items. These are things that the team needs to do that don't directly produce a feature but are necessary. So, for example, set up the analytics tool, renew the domain name, all three live in the same backlog, prioritize together, which is important. So you're forced to weigh a new feature against a critical fix against a piece of technical debt. There are no separate lists hiding the trade offs. You prioritize them all in the same list. So what makes a good product backlog, remember the acronym deep. Now, not every item in a backlog is equally well defined. So here we have a useful acronym for what a good backlog should be. So, DEEP or deep. D is for detailed appropriately. Items near the top of the backlog that will be worked on soon should have lots of detail. Items near the bottom can be vague. So don't waste your time perfecting something that might never get done. E is for estimated. Each item should have some kind of size estimate. Doesn't have to be hours or days. We'll talk about story points later, but the team should have a rough sense of how big each item is. The next E is for emergent. The backlog is never finished. New items are added all the time. Old items get changed or deleted. Now, this is healthy. It's not a sign of failure. And finally, P is prioritized. There's a clear order. Top items are the highest priority. The product owner is responsible for keeping this current flow. To build your backlog. We have three steps. This takes, yeah, an hour or two of work, depending on the size of the project. So the first of the three steps is brainstorm. Get everything out of your head and into a list. Don't worry about an order just yet. Don't worry about the size. Just dump it all out onto your page. Every feature, every fix, every chore. Aim for at least 20 items. Second step, cluster and clean up. Look at your list. Some items may be duplicates. So items will be too big to do in one sprint and need some breaking down. Some will be too small and can be combined with other tasks. The third step is prioritize. Put the most important item at the top. Most important means which one delivers the most value to the user and the soonest and for the least amount of effort, and then do the same for the next item and the next. And by the end, you would have an ordered backlog. This whole exercise should take you an hour, maybe two. We'll do it for real in the next section. So next up, we have user stories, which is the format for every item in your backlog. Thank you for joining me in this lesson. I'll see you in the next one. 11. User Stories: Writing in the “As A..., I Want..., So That...” Format: Welcome back. In this lesson, we'll learn the most useful template in Agile, the user story. So by the end of this video, you'll be able to write a user story for any item in your backlog, and you'll know what makes a good user story and what makes a bad one. So absolutely key aspect of Agile projects. The classic template, let's start with what a user story is not. A user story is not a detailed specification. It's not a contract or a list of requirements. A user story is a short statement that capture what a user wants and why. The classic template, which you will see everywhere looks like this. As a type of user, I want some goal. So that some reason. There are three parts, who, what, and why. So as an example, as a returning learner, I want to see how many days in a row I've practiced so that I feel motivated to keep going. Notice all three pieces, the user, the goal, and the reason. So why does this format work? There are three reasons it's worth the rigid structure. One, it forces you to identify the user. So many features get built nowadays without anyone thinking about who they are for. Build a dashboard, but for who for what, the user story format makes that question unavoidable. Two, it focuses on the goal, not on the solution. So notice the story doesn't say, add a streak counter widget on the homepage. It says, See how many days in a row I've practiced. Now, this leaves the team free to find the best solution to achieve that goal. Maybe it's a counter, maybe it's a calendar view, maybe it's a notification. The story doesn't dictate. And the third, it captures the why that so that part is often the most skipped part, but it's the most important. Without it, you can't tell if the story is even worth doing. If you can't write a convincing so that, maybe the story shouldn't be in the backlog at all. So let's look at some examples for each project brief. So in Edtech, as a parent, I want to see weekly progress reports about my child so that I know whether the app is actually working. In E-Commerce, a user story might be as a first time visitor, I want to see clear shipping costs before I add to my basket, so that I'm not surprised at checkout. And in events, a user story might look like as a sponsor, I want a clear breakdown of what each sponsorship tier includes so that I can decide which one to commit to. Now notice in each case, there's a real user, a clear goal, and a sensible reason for that goal. None of them are technical. None of them prescribe a solution, and this is the sweet spot. Now, what makes a bad story? Let's look at four common failure modes. First, failure it's too vague. For example, as a user, I want a better experience so that I'm happy. Now, this isn't a story. This is like a wish. What does better even mean? This is completely unworkable. A second failure would be hiding a solution. As a user, I want a red button in the top right corner so that I can click it. Now, this isn't a story. That's just a design specification dressed up as one. We have no goal and no reason with no prescribed solution. Third failure too big. As a user, I want a full account management system so that I can manage my account. That's not a story. This is like an entire project. A good story should be small enough to complete in a single sprint, and if it isn't should break it down. The fourth failure is missing the so that, missing the reason. So as a user, I want to log in. Why? Without the so that, you can't judge whether it's worth doing in the first place. So there's a useful acronym that we can use here for what a good story should be invest INVEST. Independent, negotiable, valuable, estimable. Small and testable. Independent means it doesn't depend on another story being done first, if at all possible. Negotiable means the details can change as we learn more. Valuable means it delivers something the user cares about. Estimable means the team can roughly size it. Small means that it fits in one sprint, and testable means you can tell when it's done. Now, don't memorize this now. Maybe write it down, but just remember the acronym. And if you're stuck on a user story, you can run through this acronym to try and improve it. Oh, thank you for joining me in this lesson. In the next lesson, we will add the final pieces to a good user story, which is the acceptance criteria and the Definition of Done. These are the bits that tell you that the sprint is actually finished. So I will see you in the next one. 12. Acceptance Criteria and The Definition of Done: Welcome back. In this lesson, we will tackle one of the trickiest questions in Agile. How do we know when something is finished? There are two key tools that we will use to understand this the acceptance criteria and the Definition of Done. So let's begin. Now, what does Done even mean? If you don't agree on this, the team will argue in every sprint. So here's a question. When is a feature done? Is it when the code is written? Is it when it's been tested? Is it done when it's been deployed? Is it done when the user can use it? Is it done when the documentation is updated? If you don't agree on these things, you'll end up with arguments at every step of the way. Someone might say, Yes, that's done, and someone else says, no, it isn't done. The tests haven't been run. So this ambiguity can kill momentum. So this is why Agile teams use two complimentary tools, acceptance criteria. Which are specific to a single story and the Definition of Done, which applies to everything. So let's look at the acceptance criteria first. These are short and specific statements that can describe what a story has to do to be accepted by the product owner. They go alongside the user story. So let's take the streak counter story that we wrote earlier. So as a returning learner, I want to see how many days in a row I've practiced so that I feel motivated to keep going. Acceptance criteria for this might be the streak shows on the home screen. The streak resets to zero if a day is missed. The streak shows the current number, not historical bests. The streak displays correctly on phone and tablet. Now notice that these are specific, they are testable, and they are tied to this single user story. They don't prescribe the design, but they tell you exactly what the finished thing has to do. So a good rule of thumb here is three to five acceptance criteria per story. If you have more than that, your story is probably too big. Now let's look at the definition of Done. This is a checklist that applies to every single piece of work that the team produces. It's not just one story. It's for all of them. A typical definition of Done might include the work has been peer reviewed, the work has been tested. The work has been documented where appropriate. The work has been deployed to a place where users can see it. Any acceptance criteria for the specific story have been met, and the team writes this list on and applies it consistently. This is the safety net that catches things that criteria acceptance criteria might miss. Acceptance criteria will say, this specific story does what it should. A Definition of Done says this work meets our quality bar. For a non software brief, the definition of done would look different. For an event, it might be the task is documented in the project log. Any contracts are signed and filed. An costs are recorded in the budget tracker. Stakeholders affected have been notified. So this is the definition of done for an event, for example. So how do they fit together? A story is truly done when both its acceptance criteria are met and the definition of done is satisfied. Both, not one or the other, both. This is the standard. Once you've got those two tools in place, those, is it done or not arguments should go away at the end of a sprint. So that's it for the acceptance criteria and Definition of Done. Next up, we have a little practice exercise, which will be to write three user stories for your chosen project brief, complete with an acceptance criteria. So I'll see you in the next one. 13. Practice Exercise: Write Three User Stories for Your Brief: Hello, and welcome back. This is the final video of the section. We're going to do practice exercise. In the last video, we looked at user stories and acceptance criteria. In this video, we're going to do a little exercise where you write your own user stories. So at the end of this, you'll have your first proper backlog items ready to use. So what you'll need, all you need is somewhere to write, so use your pen and paper. Or if you've already set up Trello, you could use Trello and use a Trello card, or you can use a Notion page if you prefer typing, but the tool here really isn't important. It's more of the content that we need to focus on. So first one, step one. Before you write any stories, identify three different types of user for your project. Different users have different needs, and a good backlog should reflect this. So for Edtech, you might have a child learner, a parent, and a teacher. E, these are three very different people, by the way, so they'll have three different goals. For E-Commerce, your three people could be a first time visitor, a returning customer, and a customer returning a product. And for events, you could have an attendee, a speaker, and a sponsor. And again, each of these cares about different things. So pick three people, write them down, and pause the video now. You need some time to think. Let's move on to step two. So now it's time to write the stories. You have one story per user. So use this template as a user. I want goal, so that reason. One story per user, stick to this format strictly. It feels rigid at first, but this force is clear thinking. And yeah, it doesn't have to be the cleverest stories. Just think of obvious ones. What's the most basic thing that each user wants and start there. So you can pause the video now and write down your three stories if you need some minutes to do that. Step three, for each story, write three to five acceptance criteria. So remember, specific testable and tied to that one story. For example, if your story is, as an attendee, I want a clear conference schedule so that I can plan my day. Your acceptance criteria here might be the schedule shows all the sessions with times. The schedule is available online before the event, and each section shows the speaker name. The schedule can be filtered by track or topic. So pause the video now. You can add add criteria, sorry to your three stories now. So there we go. You should now have your three user stories and your acceptance criteria. Now keep these safe. We're going to use them again in the third section. We'll use them to fill out your backlog. So, well done, you've reached the end of the second section. In the next section, we will look at setting up your project workspace properly. So well done for getting this far, I'll see you in section three. Welcome back. This lesson, we will look at the three roles that make Agile teams work. By the end of this video, you'll know who does what and why each role exists. We're focusing on the Scrum framework here because it's the most common and the role definitions are the clearest. So let's begin. First, we have the product owner, also known as the PO. This is the voice of the customer on the team. Their job is to decide what the team builds and in what order. They own the product backlog, which is that prioritized list of work, and they are the person who says, This is what matters most, do this next. Crucially, the PO is not the team's boss. They don't tell the team how to do the work. They tell the team what to do and why it matters. The how is up to the team. A good product owner spends time with customers. They understand the business, and they make hard decisions about priorities. They say no a lot because there's always more demand than they have capacity for. For your project brief, you might be playing this role yourself, which is completely fine. Remember the product owner mindset, be clear about priorities, talk to your users, and make trade offs. The next role is the Scrum Master, also known as the SM. This role helps the team work well. Now, this is one of the most misunderstood roles in Agile. The Scrum Master is not the project manager. They don't assign tasks. They don't track who did what. They don't chase people for updates or for deliverables, and they're not the boss. What they actually do is help the team work well. They facilitate the meetings. They remove obstacles, things blocking the team from progressing. Coach the team on Agile practices. They also shield the team from any outside interference. One of the best analogies here is that the Scrum Master is like a football coach. They don't play the game. They don't tell the players how to kick the ball, but they create the conditions where the team can perform at its best. In small teams, the Scrum Master often doubles up with another role, maybe the senior developer. All the responsibility is shared, which is completely fine. As long as the work gets done, it doesn't really matter. The next role is the development team. These are the people who actually build the product. Now, despite the name, this isn't just software developers or programmers. The development team is everyone who actually builds the product. For software, that would be developers, but also designers and testers. For a marketing project, it would be copywriters, designers, marketers. For an event, it's the operations people, the speaker coordinators, the venue manager. Two key things about the development team. One is that they self organize. Nobody tells them how to split up the work. They figure it out themselves. And two, they are cross functional. Team has all the skills it needs to deliver an increment without depending on outsiders. The typical size is three to nine people, big enough that you have all the skills that you need and small enough that everyone knows what's going on and who's doing what. So let's have a look at how these three roles work together. We have three responsibilities and very little overlap. Product owner decides what to build. The development team decides how to build it, and the Scrum Master makes sure that the process runs smoothly. These three roles and responsibilities have very little overlap. And this clarity is one of the reasons why Scrum works. Everyone knows whose decision is whose. If a stakeholder wants a new feature, they talk to the product owner. If a developer is blocked, the Scrum Master helps unblock them. And if the team needs to decide a technical approach, they decide it themselves. Now, in real life, especially on small teams, one person might do two roles. You might be the product owner and a Scrum Master. Or, as I said before, the senior developer might also be the Scrum Master, which is completely normal. The roles are about responsibilities and not specifically about job titles. So thank you for joining me in this lesson. Next up, we will look at the product backlog. We'll look at what goes in it, how it's structured, and how to build a good one. I'll see you in the next one. 14. Setting Up Your Project: Tour of Trello: Boards, Lists, Cards, Labels: Hello, and welcome to Section three of our project management course. In this section, we're going to look at some of the free tools that you can use to manage your project. The first one we're going to look at is called Trello. It is a free and quite simple tool that we can use to manage our product backlogs, and we can also manage our sprints. So quite a few of the previous concepts that we looked at we'll be using in this section. So let's get into it. First of all, I'll go through the four main components of Trello, and then I'll open Trello and show you an example of how to use it and yeah, show you just how simple. First of all, Trello mainly consists of a board, of a Cam band board. We have one board per project. All of your project would be displayed here. So all of the user stories would be displayed here. The board consists of lists. In our example, we're going to use four columns or four lists that represent the stages of work. So we have the backlog, which would be all of the tasks and all of the user stories. We have to do, which would be items committed to the sprint. So how many we're going to do in this, two week period. Doing is what someone is actively working on and then done are all the tasks that are finished and ready to be celebrated. So yeah, work flows from left to right. Quite simple. Now, in each list, we will have individual cards. So these are individual work items or tasks. We have one user story per card. So in a card, we put the title would be the user story. In this case, we're just going to put the as a person, I want to, and then we'll put this section as the title. The description will include the entire user story, and we will also paste a link to Notion because Notion is another free tool that we're going to look at in this section, and it's possible to link Notion with Trello. So that's very useful. We have the checklist, which we're going to call acceptance criteria. These are the things that need to be completed for the card to be deemed done. And then we have labels with priority type and then the user category. So I'll show you the different labels. These are the colored tags that make the board readable at a glance. We have the priority labels, which we will use red, yellow, and green for. We have the type labels, and we're not going to use the type labels just yet, and then we have the user labels. It's a good idea to choose, you know, distinguishable colors in these senses. And again, I'll show you this when we look at the tour. So again, keeping it simple is a good idea. It's good practice. Five to eight labels, Max. Any more than that becomes quite complex, and you'd probably need a key to understand what all the colors are. So let's go to Trello. In Trello, you can sign up for free, and then once you've signed up and your In Trello, you go here to the section boards, and you'll see all of your boards. There will be a default one here, as defaults like a template. But we want to create a new board. So if you click Create New board, the board title here, so we're just going to put. The example I'm going to use is Edtech. So we'll put here. We'll just call it example. And then click Create. And it's as simple as this. Now, here, we then have to populate the board with our lists. So we have the backlog. If you click Add list, we have to do, we have doing, and we have done. That's it. So we have the four, the four lists. Now I'm going to show you the board that I prepared earlier. So it's exactly the same, but I've populated the backlog with some user stories. So yeah, in order to do this, let's add a new card. So I'm going to come up with a new user story. As a learner, I want to earn accessories for my avatar. Okay? So add that card. Now, if you click the card to open it, you now have these different options. Let's put in the description, first of all, let's put in the entire user story. Okay. As a learner, I want to earn accessories from my avatar so that I can customize, I feel like it's mine, and we'll save that. And then for the labels, so I've populated the labels here. You can click, create a new label to sorry, to edit the label. You just click it. You can then choose the title, and then you can choose any color. I've gone with some quite easily distinguishable colors. Let's just change this one too. There you go. So for this one, let's say it's medium priority, and it's the learner. Okay? So we've got those two labels, and we can see them here. And then we're going to add the checklist. So this checklist would be called acceptance criteria. And then we click Add, and here we will add the items that need to be completed in order for the acceptance criteria to be deemed done. So for this, we will need a library of accessories. Signed. We will need animations for new accessories, and we will also need sound library for accessories. So sound effect library. Okay? So we have these three things, and that's it. So we've added all of the user story, we've added the acceptance criteria, and here it is. Now, if it's as part of the upcoming sprint, you would put it here into do. Um Again, you just click it and drag it, and it's as simple as that. Or you can move it to doing. Now, if it's doing, you might start checking off some of these checkboxes to show that it's done. And then once all three are done, we can see it goes up to 100%. If we close it. Got three out of three are completed here, the checklist items, so you can see here the checklist items. If you click it, it'll expand. You can show more if you want. Yeah, very simple. Very intuitive. And then, yeah, once it's complete, we move it to Done. That's it. So this would be how you manage your product backlog, and, you know, you'll move user stories into to do. Now, if you are the product owner, you may be assigning these tasks to the development team. In this case, you would click here members, and then you can search the members that would be part of your team and you can add them and assign them to the task. So that's it for Trello. In the next section, we will have a quick overview of Notion. 15. Tour of Notion: Pages, Databases, Templates: Hello, and welcome back. In this video, we're going to look at Notion, which is another free tool which we can use. For this case, we're going to use this to manage our sprints. Again, like we did in the previous video, I'll give you a quick overview of Notion and the concepts of it, and then I will take you into Notion and show you exactly what to do to build these pages. So, Notion is very simple. It's basically a document that can contain other documents. So the recommended structure would be something like this. We have the heading with My Agile Project, and then beneath that, we have different sub pages for each kind of document. I'll show you exactly how to do that when you look at the tour. Another thing that you can add are tables or databases. So it's like a spreadsheet, but every row is a page. So you can open, for example, where it says in the column sprint, you got sprint one. Sprint one when you click that, we'll open to the page of sprint one, and it'll have more details. And I'll show you how to do that shortly. So you click any road to open it as a full page. This is the same data. There's two ways of looking at it. It's a scannable table and a collection of detailed pages. Databases are extremely useful in Notion, and it's going to be one of the main things that you use when you use it. And then we're also going to have a look at templates. So, for example, with user stories, this would probably have the same structure every time. So we can prefill the structure of every new entry. For a sprint planning template, for example, we would have the sprint goal, the backlog items selected, and the capacity check. And this would be the same structure every time it would be repeated for every sprint. So we can create this template and use it again and again. So we'll have a look at a sprint planning template, and we'll also look at a retrospective template, which are the meetings that you do after every sprint where you discuss what went well, what to improve, and the action items for the next sprint. And then you can connect it all using the at sign. So you can type we decided this in at decision streak awards, and that would link you to specific page, and all you have to do is click Okay, so let's now have a look at Notion. Now, this isn't going to be an in depth how to use Notion video because that would be far beyond the scope of this course. Notion has many, many features, many of which, you know, you're probably never going to use, but the most basic ones are the ones that you probably use. So you can find videos online to learn how to use this. Even the Notion website itself has some quite basic tutorials, and that's all you really need to know how to do, to use Notion well. So here I have an example of the Edtech project sprint that I've created in Notion. It consists of four pages. We have sprint planning. We have retrospectives, we have decisions, and we have stakeholder updates. So in sprint planning, I've created a new database, and I've added some different columns. So I have the name. I have the sprint number. I have the date range. I have the sprint goal, and I have the status. Now, when I open this page, I can also see some different details about this stage of the sprint. I can see the capacity, and I can see selected stories. Here it has a link to Trello which I'll show you in a later video. I have a column here for risks and dependencies. So any problems that you foresee that might block you in the sprint, you should put them down here, and then also a section here for commitments for so yeah, the team commits to this plan, and then the start date. So you would fill this out with different sprints if you go have retrospectives. So this is, again, another database that can use meetings. Now, I recommend learning how to use templates because in retrospectives, it's going to be the same structure of meeting again and again and again. So you can create a sprint retrospective template. And in this, you can put what went well. You can put what to improve, and you can put some action items. So I've just put some examples here. Sprint goal was clear from day one, stars feature shipped on time. Stand-ups stayed under 10 minutes, what to improve, we underestimated the animation complexity, need clear Definition of Done for visual polish, and action items add animation reviewed by designer to Definition of Done and spike on animation libraries before estimating. So here you can have a database of all of your sprint retrospectives, which in Agile Project Management is very, very important. It's very important that you are using these retrospectives to inform your product decisions. The next page here is called decisions. So here we've got the decisions that we've acted on after the previous sprint. So here I've created a new database. I've added two new decisions. I've added some different columns. I've got the decision. I've got the date. I have the why, and I have the who. So if we open this, we can see yet, the date was 12 May. Who decided it was the team? The team decided use the platform lottie for the animations because those animations are lighter and they're easier to update. So we've got the team consensus here. So it's good to keep a track of all of your decisions because you can hold people accountable for their decisions. Just another example here, deferred parent dashboard to sprint three, something that's going to take longer than we expected. We have the date, we have who decided PO, product owner, why capacity limited, learner features are a higher priority. So the decisions, why the decisions were made, and who decided, all saved here. Then the last page you should probably make is stakeholder updates. So here, I've added, again, another database with sprint number one, the date that it was sent and who it was sent to. So here I've created a new page, sprint one update to leadership. It's sent to the leadership team. So was the sprint goal achieved? Yes, it was shipped the items that were shipped to the star reward system and the avatar selection. These are the working products that are shipped. Shipped the parent email digest, which we've moved to sprint Oh, sprint three, not sprint two. And the next sprint focus streaks and daily reminders, okay? So stakeholder updates, who have you updated the progress of the project with. You can save all of that here. So, yeah, that's the end of our tour of Notion. Up next, building your first backlog. So we'll build a new backlog from scratch in Trello. This is very hands on, so I'll see you for the next video. 16. Building Your First Product Backlog in Trello: Hi, and welcome back. In this section, you're going to build your first product backlog in Trell. You'll do this from scratch. Now, you can use the previous video as reference, but I will give you the step by step guide on how to build your first product backlog in Trell. So the first step is to set up your board, create the board, name it after the brief that you chose at the start of this course. The second step is to add four lists, your backlog to doing and done. And then if you want, you can pick a background color. You can customize it. That's up to you. Step two is to brainstorm. Now, you want to do a brain dump of everything that your project might need. Now, you don't need to filter it or refine it yet. So aim for around 15 to 20 raw items. I mean, if you can only get ten, that's fine. Or less, it's fine. Just make sure you have several. Type each as a quick trellcard in the backlog list. And then don't worry yet about the story format, get it all. Then the next step would be to write the user stories. So turn those raw items into proper stories with the criteria. In that case, maybe two raw items would combine together to be one user story. So to do that, open each card, rewrite the title in the as a user. I want this so that I can format. In the description, add the full story details. As you saw in the previous video, I just used the ASA and I Want section as the title, and then I use the entire thing in the description. Below that, you will add your acceptance criteria with the two or three testable items. It could be more. In the video previous video, we had four items. These would be the things that need to be done for this user story to be deemed complete. And then the last thing you can do is to refine the top five to seven items first. The others can wait, do as many as you want, but don't do too many. Again, this is we're just learning how to use Trello Step four would be to label and prioritize each card. So create your priority labels, high, red, medium, yellow or orange, and low priority is usually green. Add type or user labels if useful. For my EdTech project, the users three different people involved here was the teacher, the student, and the parent. You may only have one user or two users here. Or more. Then you should drag your highest priority cards to the top of the backlog list. This is, you know, the typical role of a product owner. You prioritize the tasks accordingly. And then remember the value versus F matrix when you're prioritizing, the quickest tasks usually win out and then finally, step five is a refine and a sanity check. So first of all, do my top five items pass the invest acronym? If I only built the top five, would users be better off, yes or no, and is anything obviously missing. So make sure you check all those three things before you deem your log finished. There are some common pitfalls that you should avoid. The first is being too big. Again, it's not necessary to create an absolutely huge backlog here. So yeah, don't create an 80 item backlog you'll never look at again. Just aiming for, you know, 15 to 25 might be a little bit too much. Ten is a fine number. Don't make it too vague, be very specific on the who, what, and why. And then finally, yeah, having it set in stone. This is a common pitfall. You will add remove and reorder weekly. The product backlog is a forever moving thing. It's never set in stone. Things are always going to change. You're always going to change even the column names you might change at some point. Next up, we will look at how you link Notion to Trello. So this is linking the two tools into one connected system. I'll see you for the next one. 17. Linking Notion to Trello For Documentation: Hi, welcome back. In this short video, we're going to look at how you link Notion to Trello. So by now, you should have your product backlog sample built in Trello, and you should also have your documentation skeleton built in Notion. I'm going to quickly show you how and also why we link the two tools together. First of all, why link them? Trello and Notion while they're both very useful for project management, they both kind of link and align with different modes of thinking. So Trello is more for what's the work? Where is it, who's doing it, so the actual day to day progress of projects. Whereas Notion is more like information as to the decisions that were made. Why did we decide this? What did we learn and what's the plan? Notion, with it being a tool for documentation is usually better for long term thinking and long term planning, whereas Trello is for short term planning and short term management of projects and sprints. So there are two methods to link Notion and Trello. First is the Trello links in Notion, which are a little more sophisticated than the Notion links in Trello. And I'll show you what I mean in a minute. But first of all, you click a card in Trello, you copied the URL from the browser. Paste it into your Notion page, and then Notion will show you a live preview of that card. So it's a little bit more sophisticated where when you paste a preview of the card loads where you pasted that URL. Method two, Notion links in Trello are not as sophisticated, and it's only the Link. So to do this, you open the Notion page that you want to link. You click Share and copy the Link to that page, and then you can paste it into the card description in Trello, which is very useful. However, it doesn't it doesn't have any preview of any card or anything, but anyone who has access to the card can click straight through the link and access that page. So if you haven't already built your notion structure, do that now. So you should have four sub pages, one for sprint planning, one for retrospectives, one for decisions, and one for stakeholder updates. As in reality, as your projects progress, these sub pages will just get bigger and bigger and bigger, more and more details will be added to them. So it's very important that you have, you know, the skeleton of this structure to begin with. So yeah, in the next exercise, we'll look at putting all this together, but before we move I'll quickly show you exactly how to add what we need to add to link the two tools. So we have our Trello board. We have our Notion document. And what I'm going to do is link Trello to Notion. So I'm going to copy a link from Trello and put it into Notion. So let's have a look at the sprint planning. We've got this star reward system sprint. I'm going to open this page. And you might remember this from the previous video when I opened this page, there was a preview of a card here. This is the Trello link. I'm going to show you how to do this now. So I need to find this story in my Trello board, and I've got it here. As a learner, I want to earn stars for completing lessons. To link this, all we do is right click on this card, and we click this button here, Copy Link. Once it's copied, we can go back to Notion and then paste into here. And as you can see, now we've got the option. We can paste it as the preview. You can paste it as a mention or we can just paste the URL. We're going to paste a preview. And that's it. So when you click this, it will open the card directly in Trello. So this is very, very useful. Now let's look at how we add how we add the link from Notion to Trello. So if we open this card, as you can see, I've already got the link here. I've just copied and pasted it into the description. So it's quite simple with Notion for copying paste. Click this. So whatever page you want to link In Trello, you open it, click the three dots, and click Copy Link. It's as easy as that. And then in the description, you paste it there. And as you can see, it's exactly the same link. So yeah, I'll delete that. And that's it. It's as simple as that. You're just copying links and pasting them in the right places. Next up, setting up your workspace, putting it all together. I'll see you then. 18. Practice Exercise: Set Up Your Project Workspace: Welcome back. So it's time for the practical exercise that closes out this entire section. If you haven't done it already, you're going to set up the full workspace you'll use for the rest of the course, your Trello board, your notion structure. So by the end of this video and section, you'll be ready for the sprint planning in Section four. So if you haven't done it already yet, here is your eight item checklist. This is what you need to have done by the end of the exercise, eight items. I'll walk through each one quickly, and then you can pause and work through them at your own pace. The first one, the Trello board created and named after your brief. Second is at least 15 items in backlog as user stories, priority labels created and applied. So lists with backlog to do doing and done, top five stories that have acceptance criteria checklists. A notion main page titled My Agile Project or something like this. And at least one notion page has a Trello link, and at least one Trello card has a notion link. So that should be your eight item checklist. For the Trello setup, just a quick reminder, if you did the last lesson exercise, then it should all be done anyway. But, number one, make sure that your board exists. It's named. You have the four lists in place. You have your backlog populated, and you have your top five user stories refined with acceptance criteria, and labels. In fact, I would recommend putting labels on all of them because you'll have to do this. Notion setup. So make sure you've got some templates done and you have your structure in place, you should have your main page with the title, and this is the home for everything. Then you should have your four sub pages with sprint planning, retrospectives, decisions, and stakeholder updates. Again, if you want to structure this in a different way, that's fine. The structure I used is just a simple way to do it. If you want to make it more fancy or more sophisticated. Go ahead. It's your prerogative. And finally, try to create at least two templates. So one for sprint planning and one for retroactive, so they're ready to use because these are going to be two templates that you use again and again and again. You have to plan the sprints, and you have to do your retrospective about those sprints. So very important for sprint planning is to have those two templates already set up and ready to go. So three questions before you finish. Open both tools side by side, and can you move between them in one click. The second thing to check is, could someone new to the project understand your project in 5 minutes just from looking at the board and just from looking at notion. And then you could also ask yourself, is there anything obviously missing that you think you'll need next week? Probably the templates. The templates maybe something that you might forget. Make sure you've got at least two templates ready to go for our sprint planning section. That's it for the end of Section three. We've wrapped up Trello. We've wrapped up Notion. We have, you know, a bit of bare bones to work with in our next section, which we'll be planning your first sprint. So this is our dive into the real project planning work. I will see you in Section four. 19. Planning Your First Sprint: Prioritising the Backlog: Moscow and Value vs. Effort: Hello, and welcome to Section four of our project management course. In Section three, we looked at setting up your workspaces in Trello and Notion. And now we get to the heart of Agile, which is deciding what to actually do and in what order. In this lesson, we'll cover the two simple, powerful prioritization techniques you can use straightaway, Moscow and the value versus effort matrix. So why prioritization is hard? Now, this prioritization is probably the hardest skill in project management in Agile Project Management. It's not because the techniques are complicated. It's because saying could be painful. So every item on your backlog matters to someone, and every single one was added for a reason. But the truth is, you can't do everything. If you try to do everything, you'll deliver nothing well. Prioritization is the discipline of accepting that and choosing where to spend your limited time. The techniques we'll cover are just tools to make those choices easier and more defensible. So the first technique is the Moscow method. The first technique it has the abbreviation MoSCoW. The capital letters stand for four categories. Must have should have, could have and won't have the must haves, without these, the sprint or the release fails. They are non negotiable. So for example, if you're launching a payment system, the ability to actually take money is a must have. If your event has speakers, then having a stage is a must. Should haves, they are important, but the sprint or the release can succeed without them. They might be uncomfortable to leave out, but it won't break things. So, for example, good error message on a login form, it's a should have. It's nice, but you can ship without the product or work without it. Could have these are nice to have. They're lower priority. If you have time, you can include them. So, for example, a fancier loading animation or a bonus integration, things that delight, so like a cherry on top, so they don't make it or break. And then finally, we won't have these are explicit decisions not to include something in a sprint or in a release. So won't haves are an active choice to deprioritize. Documenting them helps prevent scope creep later on. So the discipline is a healthy Moscow prioritized backlog has roughly 60% must, 20% should, 20% could. If you've got 80% must haves, you haven't prioritized. You've just relabeled everything as urgent. Now let's look at the value versus effort matrix. We touched on this a little bit in Section two. Now let's have a look at it in use properly. So for this, you can draw a quick two by two grid. The vertical axis is value. How will this item help your users or your business? Now the horizontal axis is effort. How much work will it take to deliver? And this gives you four quadrants. Top left is high value, low effort, quick wins, do those first. They build momentum. They unblock things, and they're quite cheap. There's no reason to delay them. Top right is high value, high effort, big bets, do them second. They matter a lot, but they take real work. Plan for them, break them down, and do them deliberately. Bottom left, we have low value but low effort. So these are fillers. They're not critical, but they're cheap in time and resources. Slot them between your bigger items where the team has spare capacity. And then the bottom right, we have low value and high effort. Just throw these out, just delete them. They don't earn the time that they cost. If they really matter, they'll come back and you can reconsider. But one of the traps that most teams fall into is spending a lot of time in the Big Bet quadrant. Big important features that take months to ship, force yourself to find the quick wins, make compromises. This will keep momentum going while the big bets. Using both of them together, now you should compliment them with each other. You shouldn't be using them in competition. They work very well together. So start with Moscow to categorize your entire backlog. This gives you a quick gut feel of the progress. And now take your must haves and your should haves and place them on the value versus effort matrix. And this will give you the order in which you tackle them. Now, why would you combine these? Because Moscow tells you what matters, value versus effort tells you what to do first. So combined, you get a backlog that's prioritized by importance and also sequenced by sensibility. Now, applying it to your brief. So open your Trello board. Take your top 15, your top ten or 15 items. Run them through Moscow first. Use the labels that you set up in Section three. So add four Moscow labels, red for must, orange for shod, yellow for cud, gray for wont, and then take your musts and shuds and rank them. The quick wins to the top of your backlog list, big bet to second, fillers in between. Anything that lands in throw. Archive it now. Don't be precious about these things. So two simple tools applied, honestly, this will transform how you plan and how you prioritize. So thank you for joining me in this lesson. In the next one, we will look at estimation without lying with some examples using T-shirt sizes and story points. I'll see you in the next one. 20. Estimation Basics: T-Shirt Sizes and Story Points: Hi, welcome back. Estimation is one of the parts of Agile Project Management that a lot of people get wrong. They treat it like a prediction, and it's not. So in this lesson, we'll look at two honest ways to estimate the size of work, T-shirt sizes, and story points. So you'll know how to size up your backlog without lying to yourself or to your stakeholders. So first, what estimation is and what it isn't let's get one thing straight from the get go. An estimate is a guess based on what you know now. This isn't a promise and it's not a commitment and it's not a deadline. This sounds quite obvious, but most teams forget it. Someone asks, how long will this take, and the team says three weeks. And three weeks becomes a date. It becomes a commitment. Now, the team is panicking, working late, cutting corners or because someone confused an estimate with a contract. A good estimation is honest about uncertainty. It says, This feels small or this feels big, and then it uses that to plan, not to promise. So T-shirt sizes vague on purpose. Humans are bad at absolute numbers. So the first and simplest estimation technique, T-shirt sizes, extra small, small, medium, large, extra large. That's it. No numbers, no hours, no days. But why so vague? That because that's the point. Humans are very bad at estimating in absolute units. Ask any developer how long something will take in days, and you'll probably get a wrong answer. But if you ask them is this small or medium, and you will get an accurate one. So here's how to use it. For each item on your backlog, the team agrees a T-shirt sizes. Extra small it's trivial, small, perhaps half a day's work, medium, a day or two, large is most of a sprint and extra large is too big, it needs to be broken down. Now, that last point is important. If something keeps getting labeled as l, it's a sign that it needs to be split into smaller pieces. And anything bigger than a single sprint isn't a story, it's an epic. This needs to be broken down. T-shirt sizes are perfect for beginners and for non software work. If you're doing the events brief, this is probably the technique that I would start with. Next is story points. This is a little bit more structured, and it's more common in software teams. Story points are numbers usually following the Fibonacci sequence. One, two, three, five, eight, 13, 21, I Fibonacci, it's because the gaps get bigger as the numbers get bigger, which mirrors how uncertainty works. The difference 1-2 is small. The difference 13-21 is huge because you don't really know how big either one is. Story points are not ours. Story points represent the relative size of a piece of work compared to others. A five isn't 5 hours or five days. It's five times the effort of a one point story on your team. To use story points, pick a small reference story your team agrees is worth, say, two points. Then estimate, everything else relative to that is the story twice as long. It's a five, half as big, it's a one. Roughly the same size, it's a two. The magic of story points is they let your team measure how much they typically deliver per sprint, and this is called velocity. We'll go deeper into the velocity in course two. So how to actually estimate together as a team. Whichever technique you pick, the way you actually do the estimating matters. The classic technique is called planning poker. The team gets together, read out a story. Everyone secretly picks a size or a number, and on the count of three, everyone reveals at once. If you're all roughly in agreement, then the estimate is whatever you all choose. Done. If there's disagreement, that's the interesting bit. Don't average it out. You ask the highest and the lowest estimators to explain their thinking. Often, one of them will know something that the others don't, for example, oh, you didn't realize the API doesn't have that field, we'll have to build it ourselves. So after the discussion, vote again, and then usually you converge. If you're working solo on your project for this course, you can still do this, estimate honestly. And whenever you finish a story that came out very different to your estimate, you can take note of that. That's how you get better. Oh, estimates are living things. One last principle is that estimates are not set in stone. As you learn more, you will change them. Again, fundamental concept of Agile Project Management, so this is very healthy. A story you sized as medium last week might look small now that you've done a similar one. A story you thought was extra small turned out to be huge once you started to scratch the surface of it. So you re estimate. It's not a failure. Learning and adapting. The teams that get the estimation right are the ones that treat their estimates as hypothesis, just like everything else in Agile. So sprint goals that matter. This will be in our next lesson, one sentence, but it's very outcome focused. So thank you for joining me for this lesson, and I'll see you in the next one. 21. Setting a Sprint Goal That Matters: Hello and welcome back. So far, we've talked about prioritizing and estimating, and now we get to a small but quite a powerful concept, which is the sprint goal. So by the end of this very short lesson, you'll know what a sprint goal is, why every sprint needs one, and how to actually write one that focuses your team. Very important stuff here. Okay, what is a sprint goal? This is a single but concise sentence about the outcome of a sprint. It's a sentence that describes what your team is trying to achieve in this specific sprint. Not what work you'll do. It's the outcome that you want. The sprint goal is the answer to the question. At the end of this sprint, what will be true that wasn't true at the start. So this isn't a list or a milestone. This is a real and meaningful change. Why they matter? So we have three main reasons that every sprint needs a sprint goals. So these goals matter a lot, even though plenty of teams skip them. One, they focus the team. Without a goal, every story on the sprint backlog looks equally important. When you have a goal, you can see which stories actually advance it and which are just like side quests. Number two, they help you make decisions mid sprint. Things always change. Without a goal, every change becomes like a debate with your team. With a goal, you ask, does this change help us hit the goal? If yes, you do it, if no, it to the next sprint or you don't do it at all. And the third reason they create a shared sense of purpose. People work harder and better when they understand the why. A sprint backlog with no goal is just to do list. A sprint goal with a backlog supporting it is like a main mission. So what makes a good sprint goal? We have four qualities, all of which matter. First is outcome focused. Describes what changes, not what you will build. So ship the login feature is a task. Returning users can access their order history is the outcome. To, specific it's specific enough to know that you've hit it. Vague goals like improve the app don't help anyone. Far too vague. However, something like increase day two retention by simplifying on boarding. You something to actually aim at. Third is achievable. It's achievable in the sprint. If your goal would take three months, then it's not a sprint goal. It's like the release goal. Scope it down, so it's achievable. And the fourth one is it's a single thing. One goal per sprint, no exceptions. If you have three goals, you've actually got no goal because none of them are the priority. So very important that you only have one goal per sprint. So let me show you what a good sprint goal looks like for each brief for Edtech. By the end of this sprint, 6-year-old learners can earn and see stars after completing lessons. This is specific, it's outcome focused, and it's achievable in two weeks. Notice it doesn't say anything about the features that you'll build. The stories on the sprint backlog answer that. For E-Commerce, by the end of the sprint, our top three new eco friendly products are live on the site with full descriptions, photography, and pricing. Again, it's a clear outcome, which is easily verifiable at the and for the events project, by the end of the sprint, all five keynote speakers are confirmed with travel and accommodation booked. You have one specific and measurable outcome. So if you notice the pattern here, each goal starts with by the end of this sprint and then describes a real and observable change in the world. Now, where do you put it? So the practical part, write your sprint goal at the top of your Trello description or pin it as a card at the top of your to do list. In notion, put it at the top of your sprint planning page, as I showed you before, the whole team should see it constantly. If it's hidden, it might as well not exist. Okay, so that's the end of this lesson. Sprint goals. One sentence properly thought through can transform a sprint. So very, very important that you write clear and concise sprints all the time. Up next, we have running the sprint planning meeting. So a two hour sprint with five steps, one template, and that's up next. So I'll see you then. 22. Running a Sprint Planning Meeting (With Template): Mm hmm. Welcome back. So by now, you've prioritized your backlog. You've estimated, you've thought about your sprint goal. So now it's time to bring all of those things together in a sprint planning meeting. By the end of this lesson, you'll know exactly how to run a meeting, and you'll have a template that you can use for every sprint again and again and again. So first of all, what is sprint planning? This is by far the most important meeting of the sprint. You have it at the start of every sprint, as this is where the team decides what they'll work on for the next two weeks. Everything that follows this meeting depends on the decisions that you make here. So extremely important. So the classic guidance here is to keep it time boxed. 2 hours for a two week sprint is the standard. If it's longer, you're probably over planning a little. There's one sprint goal agreed, and we have five steps in the agenda. So there are two questions that every sprint planning should answer in this order. Question one, what is the goal of this sprint? And this is where you agree the sprint goal that we covered in the previous lesson. Now, the product owner here would usually propose it, and then the whole team will discuss and then commit to the and then question two is what work will get us to that goal? So this is you pull items from your backlog and move them into to do list Trello. And you only advance the items that advance the goal. So be ruthless here. Anything that doesn't directly support the goal should stay in the backlog for the next sprint. And that's it. The meeting answers these two questions and ends. Anything else would be a distraction. So let's look at the five step agenda, which you should be using for every sprint. You can use this time and time again. It's five very simple steps. Step one is to review the sprint goal, take about five to 10 minutes to do this. The product owner proposes a goal, and then the team discusses it, and you all agree. Step two is to review the capacity of the team. So it takes about 5 minutes. Be honest about how much team the actually has. So if there are any holidays or sick days, any meetings, any other commitments, you should never plan as if everyone is working at 100% because that's never the case. Most teams usually plan around 70 to 80% capacity. Step three is select stories from the backlog. This should take between half an hour and an hour. You can walk through each of your prioritized backlog items. For each story, you ask, does this advance the sprint goal? If yes, can we fit it into our capacity? If you can, then pull it into to do, and you stop when you've reached your capacity. Step four is to check the plan, take about ten to 15 minutes. So step back. Does this work you've actually selected Does it actually achieve the goal? If not, you should swap some stories. Are there any obvious dependencies? Surface them now, not on day five. And then step five is confirm and commit. Everyone agrees, takes about 5 minutes. The whole team says yes. This is what we're doing. Everyone leaves the room, knowing the goal, knowing exactly what they have to work on, and knowing their role in that work. So let's look at some common traps. These are four traps that I see all the time that teams fall into when planning. Try to avoid these. So the first is overcommitting. The team feels pressure to do more, so they put too many stories in the to do section, and then they fail to deliver. Next, they overcome it again in the next sprint to make up for it, which is a vicious cycle. So it's better to commit less and then deliver consistently. The second trap is planning to perfection. Sprint planning is a working meeting, not an interrogation. If you find yourself spending 15 minutes debating the exact wording of one acceptance criterion, then you're in the wrong meeting. That would be refinement and not planning. So move on. Trap three is skipping the goal we'll just pick up the items and crack on. No, no, no, no. Without a goal, the sprint is just a to do list. So the goal is what makes a sprint a sprint. And the fourth trap is planning in isolation. The product owner shouldn't write the plan and present it to the team. The team needs to plan together. They commit together. That shared ownership is the whole point. And again, Agile management relies on people doing their own taking responsibility for their own work. Now the template. So open your sprint planning database and create a new entry, a new page. Fill in these sections for every sprint. So your Section one, which you can use, heading three or heading two, sprint number and date range just for tracking. Section two would be the sprint goal, which is just one sentence. Remember, focused on the outcome. Section three is capacity. So no any sick days, any holidays, or known time commitments, the total available hours or days for the team. Section four selected stories, pays the Trello card links for everything that you're committing to with the estimates if you have them. Section five are the risks and dependencies. So anything that might block the team any external weights, any unknowns, any dependencies on other teams or vendors? And then Section six would be the commitment. So just a line that says, Yes, we commit to this plan with the date. Sounds maybe unnecessary, but it does make a real difference. The act of writing it down creates accountability. So yeah, here's your template. Save this in Notion so that every time you create a new sprint planning entry, you can use it. 5 minutes of setup, which will save many, many, many minutes and probably hours down the line. Now, if you're working solo, the discipline still applies. If you don't have a team to plan with, that's fine. Run the meeting yourself, block 30 minutes, walk through the five steps, talk out loud, if it helps you. It might sound silly, but it does help. It does work. The goal of solo planning is the same. You agree what you're doing, why and how much. The discipline of writing it down still applies, and future you will thank present you. So that's sprint planning for two questions, five steps, one template. In the next section, we will look at the sprint backlog in Trello. We look at how to set up your sprint board for the work ahead, which is up next in the next video. I'll see you then. 23. Building Your Sprint Backlog in Trello: Welcome back. So by now you've planned your sprint. Let's actually set it up on your Trello. So in this lesson, I'll walk you through exactly what to do in what order. So by the end, you have a sprint backlog ready to go. Now, first of all, product backlog versus sprint backlog. It's important that we don't confuse these two. So it's important we have a quick distinction. There are actually two backlogs in Agile, even though we only just say the word backlog, the product backlog is everything that might ever get built. So it lives in your backlog list on Trello. We built this in Section three. This would be everything that you require to complete. Your project. The sprint backlog is a much smaller subset you've committed to in this sprint. It lives in your to do, doing and done lists. It's a snapshot of one sprint. So building your sprint backlog isn't creating new cards. It's moving the right cards from the product backlog into the to do list. So step one is to add the sprint goal, pinned at the visible always, create a new card, add your sprint goal to the top of your to do list, so drag it up to the top. In Trello, you can click Add a card, move it to the top of your to do list, make a card called sprint goal, paste your one sentence goal into the title, add a colored label, something that's distinctive, so it stands out from the regular story cards. Could use a bright orange one called goal, for example, or maybe a black one. Some people prefer to put the sprint goal in the board's description instead, which is fine. Either one of them works. The important thing is that it's visible. Step two is move the stories in to do. So highest priority at the top. Remember this, you drag them from your backlog. So all the stories that you committed to in your sprint planning, you're going to move these cards. So go to your backlog list, find each card you committed to, drag it from backlog into to do. The order in which you put them matters, put your highest priority at the top. So when someone finishes a card and needs to pick up the next one, the choice is obvious. Don't bring in everything only what you've committed to. The rest stays in the backlog for future sprint. Step three is to update the card details, and you could also maybe link with Notion and Trello, as well. So step three, open each card in your to do list, do the sanity check off all the details. Does it have a proper user story in the title? Does the description have any extra context that the team needs or the acceptance criteria in the checklist? If you've added estimates, are they recorded somewhere either as a label or as in the card description. So this is your last chance to do a sanity check and to refine before the work starts. So don't skip this part. Card with weak acceptance criteria becomes an argument later, and it's just an example of bad planning. Step four is to apply your labels if you've not done this already. So again, remember, the previous sections, we looked at Moscow the T-shirt sizes. Apply your labels for visibility, add Moscow labels if you're using them, must, should and could. If you've estimated, you might also add the T-shirt sizes labels, SML or l or story point labels two, three, five, and eight, if you're going with the Fibonacci sequence. These labels mean that even at a glance, you can see what the sprint looks like. If there are lots of must labels and big sizes, you've overcommitted, if you have lots of small cards, then you might have some extra capacity. Step five, take a screenshot of your sprint backlog right now before any work begins, save it somewhere. The best places in Notion. And why? Because at the end of the sprint, you want to compare what you committed to with what you actually delivered. The screenshot makes this comparison, very easily. It also makes a great portfolio artifact. This is what we planned, and here's what we shipped. Oh, very important. So that's it for this section. Practice exercise is coming up next. You're going to plan your first sprint now that you have your gold at the top and you have a committed set of stories with labels for visibility and also the screenshot. We're now ready to put it all together and wrap up Section four. So I will see you in the final video of Section four. 24. Practice Exercise: Plan Your First Sprint: Hi, and welcome back. Time to put everything together. In this exercise, you're going to plan your first sprint for your chosen brief, end to end. By the time you're done, you will have a sprint goal, an estimated and prioritized backlog, and a committed sprint backlog in trello as well as a sprint planning document in notion. And this would be a complete sprint plan, and you're ready to execute this in the next tection. So first of all, five steps. So the end to end should take about 45 minutes. It might take you less. Maybe you've already done some of these as well. So step one would be to prioritize your top ten backlog items using Moscow, add your labels. Step two is estimate with T shirt sizes or story points, whichever one you prefer. Step three would be to write your sprint goal with one concise and outcome focused sentence. Step four is to pull all the stories that advance the goal into your to do list on Trello and commit to a realistic amount. And the final step is to fill in your sprint planning template in motion. Do not skip this. This is the artifact that proves you've done the work and so let's just quickly go over what good looks like. Here is a worked example from an Ed Tech brief, so you know what you're aiming for. Sprint goal by the end of this sprint, 6-year-old learners can see stars after completing each lesson. To do list contains four stories. Story one, learners see animation after lesson completion. Story two, stars are saved to the learners profile. Story three, stars are displayed on the home screen, and story four, parents can see how many stars their child has earned this week. All four of these advance the goal. All four together are roughly two weeks of work, and the capacity is honest. The goal is very specific and the stories support it. So this is what good looks like. And there are also some sanity checks that you can do before you call it all done. So these three questions to ask, the first if I delivered every story in my to do list, would I have hit my sprint goal? If no, you've got the wrong stories or you've got the wrong goal. Number two is, have I been honest about my capacity or am I kidding myself? It's better to commit to less and overdeliver than overcommit and let people down. Remember this, this is key. And three, does someone external looking at my Trello board understand this sprint in 30 seconds? If the answer is no, your goal isn't visible enough or it's not clear enough. Mistakes to avoid at this stage. The first one is skipping the goal. Skipping the goal because stories speak for themselves. No, they don't, they do not. Without a goal, you can't tell when you're winning. So never skip the goal. Two, pulling in every must into the to do list without thinking about capacity is a no no. Just because something is a must doesn't mean it has to be done in this sprint. Sometimes a must has to wait for the future. And three, filling the sprint to 100% capacity always leave room for the unexpected. Real sprints hardly ever go to plan. So something else to remember there never filled to 100%. And that's we've reached the end of Section four, so excellent work for sticking with me so far. In Section five, we will look at the ins and outs of running the sprint. We will look at stand ups, reviews, retros, and the work itself. So well done for reaching the end of Section four, I will see you in Section five. 25. Running the Sprint: The Daily Stand-Up: Format, Timing, and Common Traps: Welcome to Section five of our project management course. So up to now, you've planned your sprint. Now the work begins. In this lesson, we'll cover the single most well known Agile ceremony, which is called the daily stand up. So by the end of this section, you'll know how to run one in 15 minutes, what to say, what to avoid, and why so many teams get it wrong. So what is a stand? This is a short daily team sink. It's not a status report. It's usually about 15 minutes. Usually, you have it the same time, the same place, every day of the sprint. And the name comes from the original idea that everyone literally stands up because standing keeps the meeting short. Sit down and you'll talk for an hour. So it's not a status report. It's not a meeting where the boss checks up on people. It's a quick sink where the team aligns on what's happening. Surfaces any problems and the justs course if necessary. So the top three questions, each person in turn will answer these questions with about 60 seconds each. This is the classic format. So each person talks in turn. Question one is, what did I do yesterday? A quick recap of your progress. Two, what will I do today, what you're picking up? Three is what's blocking me. So if there are any obstacles or any questions or dependencies, this is dealt with there. And each person should answer all three in about 60 seconds. With a team of five, that'll be 5 minutes. And the remaining 10 minutes are for the actual conversations, the things that come up because of what people just said, and that's where the real value lies in these meetings. So the newer guidance from the Scrum guide focuses less on the three questions and more on the goal. How can we as a team, make the most progress towards the sprint goal today? Both of these approaches work. The three questions are easier when you're starting out. You may develop your own approach as time goes next up we have timing and logistics. Here are some practical things that make stand-ups work. So first of all, time it 15 minutes max, set a timer when it goes off, you stop, even if it's mid sentence. The pressure of the timer forces your discipline. You should have it at the same time every day. Pick a time that works for everyone. Common is 930 or 10:00 A.M. Because it gives the early starters time to settle in, but doesn't lose the morning. And don't put it at 4:00 P.M. By then, most of the day is gone. It should be in the same place, whether it's physical or virtual, a predictable location is very important. Most remote teams usually use a daily video call. In person, all of you should gather around the Cambanbard. And or for remote, at least keep your cameras on. The energy is a little different this way, and people stay focused when they're standing up. So finally, is walk through the board, not the people. This is a subtle but an important shift. Instead of going around the team like Sarah goes next, then James, walk through the cards in the to do doing and done lists. And for each card, the person working on that specific card speaks. And this keeps the focus on the work, not on the individuals. Some common traps, some four ways that stand-ups go wrong, avoid these. Avoid turning it into a status report. People talk to the manager or the project lead listing what they've done in defensive detail. This is the wrong audience. The stand up is for the team, not the boss. Speak to your peers. The second trap, problem solving in the meeting. You don't solve blockers in this meeting. If someone mentions a blocker, we save that for a later time. The team starts brainstorming solutions, and 20 minutes later, you're still there. So don't do this. The stand up is to surface problems, not to solve them. Trap three, skipping the meeting when busy. If we're too busy to do the stand up today, this is exactly when you need it the most. So busy teams are usually busy because they're not coordinating well enough. Skipping the stand up just makes that even worse. It's like a vicious cycle. So do not skip this daily stand up. And finally, Trap four is canceling when people are in remote. Let's just post updates in Slack now. I mean, this is fine for a day, but you do it for every day of the week, then the team will lose its shared sense of the sprint, and the point of the meeting is the live coordination, not the written update. So if you're doing this solo, here is some adaptation that you can do for solo projects. Solo workers still benefit from a daily check in. Take 5 minutes each morning to open Trello, look at your board, ask yourself, what did I do yesterday? What will I do today? What's blocking me? Write it down somewhere, even just in a quick Notion entry, that's fine. It might sound ridiculous talking to yourself, but the act of articulating it surfaces problems you'd otherwise ignore. So try it for at least one week and you'll see how it is. So up next, we have visualizing work to do doing and done. The three column flow that we set up in Trello. We'll dive into this in more detail in the next video. 26. Visualising Work: To Do, Doing, Done: Hi, and welcome back. The simplest and most powerful Agile idea you'll ever counter is this. Make the work visible. In this short lesson, we'll cover the three column flow that drives every Agile board and how to use it well. So why visualize? Here are three reasons that make visualization very powerful. Number one, you can't manage what you can't see. If work lives in people's heads or in email threads, it's invisible. You don't know where things are stuck, what's overloaded, who's overloaded, or what's two, it creates shared awareness. The whole team can see the same picture. No more. I didn't know you were doing this. I didn't know you were working on that. Everyone knows what everyone's working on. Three, it services any flow problems. So when you can see all the work in one place, patterns jump out, cards piling up in doing, cards stuck in review, long delays between lists. Each pattern points to something to fix. So here we have the three lists to do, doing and done. On every Agile board, these three lists do the heavy lifting. To do is work committed for this sprint, but not yet started. Cards are just waiting there. The top of the list is what someone should pick up next. Doing is work actively being done right now. This is where the team's attention is. And critically, work only enters doing when someone is actually working on it at that moment. No I'll get to it later today. They're doing it right now. Done is work that's finished, so work that's properly finished, not 90% done, not pending review, it's done. It's boxed off. So these three lists side by side, give you a real time picture of how the sprint is progressing. So, work in progress limits. This is a powerful tip that most beginners may miss. Is to limit how many cards can sit in doing at once. Now, this is called a work in progress limit or a WIP limit. Why? Because nothing kills progress like having too many things that are half done. If five people have three cards in progress, you've got 15 things in flight at once, and almost certainly nothing is actually getting finished. So a good rule of thumb here is no more than one card in doing per team member. Some teams use N plus one, so a team of five has six WIP slots. The exact number matters less when the principal finished things before starting new ones. So if you're working solo on your project, your WIP limit is one. Pick one story, work on it, finish it, then pick the next one. Resist the urge to bounce. Finally, once you've got a board going, learn how to read it. So there's three main things to look for day to day. One is imbalance. A bulging to do list means there is too much work in progress. An empty done list at sprint midpoint means that nothing is getting finished. Two is cards that haven't moved in days. These are stuck cards. Figure out why they're stuck. Usually, it's a blocker that hasn't been raised in a daily stand up. Three are your surprise cards, things that appear in doing that weren't part of the original sprint plan. These are the silent killers of any sprint goal. So surface them, decide we have their real priorities or if they're actually distractions that should be left for later. Oh, three columns. One working progress limit, a habit of reading the board, and that's it. So thank you for joining me for this lesson. In the next one, we will look at handling change mid sprint, which happens all the time. It's something that any Agile project manager has to be skilled at doing. So we'll go over three questions that protect the goal, and this is up next. So I'll see you in the next video. 27. Handling Change Mid-Sprint: Hi, and welcome back. Now, to be honest, no sprint ever really goes to plan. Something always changes. So in this lesson, we're going to look at how you can cover mid sprint changes without panicking, without losing focus, and most importantly, without abandoning your original sprint goal. So this is something to get used to with Agile project management. Change is not failure. This is completely normal. Every sprint, something will come up that wasn't in the plan. Stakeholder might change their mind, a user might report a critical bug, maybe a dependency falls through, maybe a new opportunity arises. Now, the Agi Manifesto explicitly welcomes change. So if you remember value four of the manifesto, it's responding to change over following a plan. Now, that doesn't mean that change is always good or always acceptable mid sprint. It just means that you have a process for handling it instead of pretending it won't happen. This is key for project managers. So we're going to go through a little decision framework. Now, when a change request lands mid sprint, this is a simple framework you can use. We have three questions in order. Question one is, does this change help us hit the sprint goal? If yes, then it might be worth doing. Now, I no, then it goes to the product backlog for a future sprint. Question two, it does help, what would we have to drop in order to make room for it? Capacity is always finite and you can't just add work, so you have to make a compromise somewhere. And the question three is, does the team agree it's worth the swap? If the whole team decides, not just the product owner, at the end of the day, they're the ones doing the work. If the answer to all three of these questions is yes, then you can swap it in. You can add it to the to do list. If no, then you should push it to the backlog. Now, the discipline of using this framework every time is what is going to protect your sprint goal. Now, not all changes are born equal. There are three rough categories that we could use here emergencies. For example, the site is down, a critical bug is hitting users or a legal issue just arrived, and these genuinely can't wait. So drop something and swap it in. But be honest, real emergencies are quite rare. If everything is an emergency, then nothing is an emergency. Next, we have important but not urgent. So for example, a new feature idea or an interesting market shift or stakeholder request that matters but doesn't really break anything. These can go into the product backlog, add a card, and prioritize them for the next sprint. Don't disrupt and then shiny distractions when someone has a new idea, which sounds great, but it's not really linked to the sprint goal, politely put it in the backlog and move on. Most mid sprint requests will fall into this category. Now, how to say no, quite difficult as a project manager. People hate hearing no, and you will hate saying it. So here are three techniques that help you not burn a bridge. So one is yes in the backlog. So don't say no to the idea itself, but say yes to capturing it. That's a great point. Let me add it to the backlog so we can prioritize it properly. That will validate the idea without committing to it. Two, refer to the frame I want to make sure we hit our sprint goal, which is X. This new request doesn't directly support that. So can we look at it in the next Prints meeting? The goal becomes the reason, not your personal preference, and three is trade openly. So, well, we can do this now, but it means dropping Y. Are you okay with that? So suddenly the requester has to weigh the cost of their request, not just the benefit. And often they will decide that it can wait for later. Next is to document the decision. Whatever you decide, write it down, add it to your notion decisions database, put the date, what was requested, what we decided, and why. 2 minutes of writing this will save hours of why didn't we do that in later meetings. Remember, change will happen. The most important thing is to protect the sprint goal and have a framework in place and also document the decision. So up next, we will look at the sprint review, showing the real work. These reviews involve stakeholders. It involves feedback, and it involves some honesty. So we will look at that in the next video. 28. The Sprint Review: Showing Real Work To Stakeholders: Welcome back. So the sprint is over. Now it's time for the moment of truth, which is showing your work. In this lesson, we will cover the sprint review, which is also called the sprint demo, and by the end, you'll know how to run one of these meetings that actually informs your stakeholders rather than just performing for them. So what is a sprint review? Sprint review is a meeting that takes place at the end of every sprint. It is incredibly important as these are the meetings where the team shows the work that they've completed to the stakeholders. The stakeholders are the people who care about the project but on the team, so that could be the manager, it could be a client, it could be some internal sponsors, or it could be the actual users. It's usually 1 hour for a two week sprint, and there are two purposes for these meetings. One is to demonstrate what's been built to check that it meets expectations and that it works. Two, is to gather feedback that informs the next product backlog and the next sprint. Now, this is not a status report. It's a conversation about real working output that your team has produced. So there are three rules that you should follow about what you should show in these meetings. Number one, you show working output, not slides about working output. If you build a feature, demo the actual feature on a real device or a screen, show that it's working. Don't make a 30 slide deck describing it. The point here is that it actually works, so show it working. Two is to tie everything back to the original sprint goal, open with the goal, walk through how each piece of work contributes to that goal, and close by saying whether the goal was achieved or not. And three, only show what's done done by your definition of done. Not this is 80% fixed. Sorry, this is 80% completed, or we just need to fix a few things. It needs to be real finished work that's 100% done. If it isn't done, leave it out. You can mention it in the section on what didn't get finished, but do not demo things that are not complete. Now, you should have a 60 minute agenda, which you can reuse for every sprint. So minute zero to five is a welcome and recap the sprint goal, get everyone in the room oriented. Minute five to 35 would be your demo for each completed story, five to 7 minutes per story, show it working, explain the context, and then ask for questions. Minute 35 to 45 is what didn't get finished. Be honest about what's still in progress and why this builds trust and hiding thing destroys it. At 45 to 55 stakeholder feedback, open the floor for questions. What does the audience think? What would they like next, capture all the data that you can hear and don't make any promises. And then the final 5 minutes would be to wrap up, recap the key feedback, agree on actions, and end it on time. So handling feedback well, this is where most reviewers go wrong. Stakeholders give feedback. The team gets defensive, or the team accepts every request as a promise. Both of these are bad. A better approach is to listen first. Don't be defensive. Do not commit, hear it, write it down on a visible board in Notion, or in front of the stakeholders. Thanks, capturing that. That's what you can say. After the meeting with the team, decide what to do with each piece of feedback. Some items will become new backlog items. Some might be refining existing stories. So could be interesting but not actionable, which is fine. Just do not make promises in the room. We'll add that to the next sprint is a trap you should avoid. You don't know yet whether it should be a priority or not, so do not promise it. Capture the request and decide later when you are planning. So if you're working solo on this course, you still need a stakeholder. So find one or be one. Can be a friend, it could be a colleague, it could be a partner, anyone who's got patience and curiosity for you and your project. Schedule a 30 minute slot, walk through your sprint goal, demo your completed stories, and ask the three questions. Does this look right? What surprised you? And what would you want next? Even an unrelated person may surface useful feedback just from being a fresh pair of eyes. So take notes, this is proper Agile practice, but scaled down to a solo user. So they're sprint reviews, they show real work. They gather on his feedback. You should never promise on the spot. So next we're going to look at the retrospective, which is the team's chance to look inward and to improve. I will see you for the next video. 29. The Sprint Retrospective: “Start, Stop, Continue”: Welcome back. So the sprint review that we just looked at looks outward at what we built, while the sprint retrospective looks inward and looks at how we worked. So in this lesson, we'll go over the simplest and most popular retrospective format, which is start, stop, and continue. So by the end, you'll know how to run one of these meetings that actually changes how your team works. So what is a retrospective? This is a meeting at the end of every sprint just after the review, where the team reflects on how they work together during the sprint. They don't talk about what they built. They talked about how they worked. So this is usually 45 to 60 minutes if it's a two week sprint. Only the team with no stakeholders, so this is a safe space where the team can be honest about what's working and what isn't working. And the principle behind it is from the Agile Manifesto principal 12, which states at regular intervals, the team reflects on how to become more effective, then tunes its behavior accordingly. The retrospective is how that happens in practice. So the simplest retrospective format has three columns on a wall or on a board. Start, stop, and continue. So start. This is things that the team should start doing that they're not doing now. Maybe start writing acceptance criteria before estimating or start a five minute check in midway through the sprint. Stop. Are things that the team should stop doing, maybe stop accepting changes after planning or stop holding stand ups when the product owner can't attend, things like this, and then continue or things that the team is doing well and should keep doing. So maybe continue having lunch together on Wednesdays or continue updating the board daily, whatever the team thinks works that they're doing well. So each person can add sticky notes to each column, and then the team will discuss it. Groups can pick similar themes, picks the most important ones to act on in the next sprint. So how to run this type of meeting. Here's a five set agenda for a 45 minute retrospective. Step one is to set the scene to about 5 minutes. Remind the team what a retro is for, establish the space. The Vagas rule is that what's said in the retro stays in the retro. Step two, silent writing. So 10 minutes, everyone writes their start, stop, and continue items independently. No discussion. This quiet writing session surfaces honest opinions without group. Step three is share and group. So this should take about 10 minutes. Each person reads their items. We group similar items together. Don't debate them just yet. This is a categorization part of the meeting. Step four is to discuss the top items, take about 15 minutes for this. You can so each person gets three dots, stick them on the items that matter the most, like a voting process. And then when you're finished, discuss the top three. Five is to agree action. So for each of the top items, agree concrete actions, who will do what, by when. Otherwise, the retro becomes like therapy with lots of talk and no change. So agree on those actions, who, what, and by when. So a retrospective is only useful if people are honest and people are only honest if they feel safe. So three things help. One, no blame. The norm Kurth prime directive says, regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time. Read this aloud at the start of every retrospective because this will set the tone for the team. Two, there should be no managers in the team. If you have a line manager who isn't on the team itself, they do not attend because people can't be honest if that's the case. So yeah, you can't be honest about how people react with the manager when the managers in the room. So no managers. Finally, is to focus on the system, not the people. So why did this happen? Why did Sarah do this? This agile principle is that good people can be trapped in bad systems, so improve the system. You have some other formats to try. So if your stop start feels stale, you can mix it up. So we'll cover this properly in the third and the more advanced course. But here's a quick taster of three alternatives. We've got mad, sad, and glad. So people write what made them mad, sad or glad in this sprint surfaces in motion that the start, stop, continue format can often flatten. We've got the four s liked, learned, lacked, longed for, more reflective, especially for big sprints. Finally, sailboat. The team is a boat. What wind pushed us forward? What anchors held us back? What rocks should we avoid? This is quite playful and visual and good for distributed teams. But we will go more in depth into this in course three. So that's it. Retrospectives, short, safe space, action focused. The teams that improve the most are the teams that do retrospectives well. So in the next session, we will do a practice exercise where you'll run a five day mini sprint and you'll experience the rhythm of a sprint end to end. I'll see you for the final video of Section five. 30. Practice Exercise: Run a Five-Day Mini-Sprint: Welcome back. So we arrive now at the most ambitious practice exercise so far. You're gonna run an actual sprint. We'll compress it to five days, but it's real in every other way. So plan, execute, review, and retro. By the end, you'll have lived through a complete sprint cycle, and you'll have the artifacts to prove it. So let's get into it. First of all, why a mini sprint. Standard sprints are usually two weeks long. For this exercise, we'll compress it to five days, Monday to Friday. We'll do this because the point of the exercise is to feel the rhythm of a sprint planning, the daily progress, the mid sprint adjustments, the review, and the retro. Five days is enough to experience all of that without committing weeks of your life. So keep your scope small, aim for two to three stories total. The goal is the cycle, not the volume. So Monday Monday morning, block 30 minutes for sprint planning. Use the template from Section four, if you can, write your sprint goal, pick two to three stories from your backlog, and then advance it. Move them into your to do list, apply the labels, and take a starting snapshot. So then you should start the work. So by the end of Monday, you should have something in the doing column, ideally, something in done as well. Tuesday to Thursday, this will be the daily rhythm where you build the habit. We've got three working days. So yeah, Tuesday, Wednesday, Thursday. Each morning, 5 minutes solo stand up. What did I do yesterday? What will I do today? What's blocking me? You can write the answers in a quick notion note. Make sure you date every entry. Each day, update your Trello board. Cards move from to do to doing to done do not accumulate work in doing. Something tries to interrupt, use the change framework that we looked at in Lesson three, if it helps to sprint goal, if it doesn't backlog it. If it does, then what gets dropped to make room for it? Aim to finish at least one story by Wednesday. If by Wednesday you haven't finished anything, then that's a sign you've overcommitted. Reduced scope now. And then on Friday morning, this is when you'll have the review. So take about 20 minutes to run your sprint review. Get a stakeholder if you can, a friend, a partner, former colleague, chat GPT, walk them through what you've built, show it, but don't describe it. If no one is available, do it on your own. Record yourself doing the demo. On a phone video. Just describing the workout loud, sharpens your thinking, capture the feedback in Notion, record it all there. New ideas should go into your product backlog as cards in Trello. And then on Friday afternoon, after you've had the review, you will then have your retrospective, which again is about 30 minutes. Even if you're doing this on your own, it should work. Open Notion, create a new entry in your retrospectives database, use the template you created. The columns, start, stop, and continue. Spend 10 minutes writing items in each column and be honest. Stop checking the news mid task, for example, another one, start blocking 90 minute deep work sessions, continue closing tabs at the end of the day and then pick the top three things to act on for the next sprint and write them as concrete actions. Who, what, and when? Tag your retro entry with the sprint number. You want to look back at these in two or three sprints time to see if you actually made any changes. So some common mistakes to avoid, three things to avoid in your first ever sprint. Beginners make these quite a lot. The first one is overcommitting on day one, so it's better to commit less and then overdeliver than it is to overcommit and underdeliver. The second is to skip the stand-ups when you're solo. It's just me. I know what I'm doing, but maybe you don't discipline of articulating your day reveals things that you might have missed if you didn't articulate it. And then finally is canceling the retrospective. So the retrospective is the whole point of Agile methodology. If you don't use it, then you don't improve. So never cancel the retro. By Friday evening the end of the week, you should have all of this. You should have a Trello showing the journey with your sprint goal at the top, completed stories and done, anything that didn't finish sent to the backlog. Two, five daily stand up notes in Notion. Three, you should have a sprint planning document for this sprint all filled in. Number four, your review notes capturing what you showed and the feedback that came back. Five, a completed retrospective entry with three concrete actions for the next sprint and six, a screenshot of your finished Trello board alongside the starting screenshot. Together, these are a portfolio grade demonstration that you can run a sprint. So, that's it. We've reached the end of Section five. I will see you for Section six. 31. Wrapping Up: Common Beginner Pitfalls And How to Avoid Them: Hello, and welcome to Section six. It's the final section of course one. Before we wrap up, I want to spend some time on the pitfalls that I see beginners making time and time again when it comes to Agile Project Management and mainly running Agile sprints. So by the end of this, you'll know what to look out for, and you'll probably save yourselves months of trial and error if you follow these remember these common pitfalls. So Pitfall one, doing Agile without being Agile. Now, new teams adopt the ceremonies and they run stand-ups. They have a board. They call meeting sprint planning, but underneath all that, nothing has actually changed. The product owner still hands down requirements like project manager. The team still waits to be told what to do. Changes are still treated as failures. The form is Agile, but the substance is waterfall in disguise. Don't fall for this. The fix isn't in more ceremonies. It's in the mindset, the mindset of trusting your team, of welcoming change, of delivering value early. So if you're doing the rituals but not living the values, you're not really doing Agile. For number two is over planning the sprint. I mentioned this quite a lot in the previous videos. So sprint planning takes about 2 hours. Some teams turn it into a full day workshop, which it's not correct. They debate every story for like 20 minutes. They estimate the nearest half point. They write paragraphs of acceptance criteria for stories they haven't even started. So stop all this. Planning is supposed to be lightweight in Agile, because the whole point of Agile is that you learn as you go. So detailed plans for things that you haven't built yet or guesses, dressed up as certainty and belong in waterfall project management. So plan enough to start and then refine as you learn. Or number three is skipping the retrospective. This happens quite a lot. Don't do it. Teams under pressure. They might cut the retro first, like, Oh, we don't have time. We'll do one in the next sprint. Two sprints later or three, six months later, the team has stopped improving entirely. So the retro is the single most important meeting in Agile because it's how the team gets better over time. And without it, you don't learn. Without learning, you stagnate. So please make sure you always keep the retro, even if it's only 20 minutes, and even if it's just a notepad, make sure you never skip it. And Pitfm number four, letting the backlog grow forever. Every idea gets added, and this is a problem. Nothing gets removed. So after six months, you've got 400 items. Nobody can find anything. The top of the backlog is no longer just the most important work. It's whatever you happen to add most recently. So it's very important that you prune your backlog like a bush. Once a month, scan the bottom half. Anything that's been there for three months or more and isn't anyone's priority, delete it. If it really matters, it will come back. So a clean backlog is a healthy backlog. At 45, the hero problem. So this is the idea that one person on the team does most of the heavy lifting. They're brilliant. They pick up the hardest tickets. They work weekends. Everyone else relies on these people. Now, this looks great in the short term, but in the long term, this is a disaster. So the hero burns out when they leave the company or even if they go on holiday, the team collapses because knowledge is stuck in one person's head and worse, nobody else gets to grow. So spread the pair people on hard stories, let them collaborate, rotate the people who pick up the harder ones, make sure the team is resilient and not depending on one hero. The next pitfall is confusing, busy with productive. The board is full. Cards everywhere. People look stretched. Surely, this is what a good sprint looks. Not necessarily. A team with 15 cards in doing is rarely shipping anything. They're context switching, they're half finishing. Maybe they're getting blocked, and they're probably getting burned out. A team with two cards in doing might be quietly shipping more value. So remember that activity isn't always progress. Watch the done list, not the doing list. The question isn't people busy? The question should be, is value flow? It for number seven is ignoring blockers. This is very, very important. If someone mentions a blocker in a stand up and the team just nods, and then the meeting moves on. Three days later, the block is still there. The card hasn't moved, and the whole sprint is in trouble. So blockers are the most urgent item on any board. When one is raised, name it, write it down, assign someone to unblock it or deal with it yourself, make it very visible on the board as a label or as a separate card. A blocker that nobody owns is a blocker that never gets fixed. So remember this. So yeah, seven Pitfalls all avoidable. The teams that get good a Agile are the ones who avoid all of these mistakes, and they're the ones who notice them faster. So, so that's the end of this lesson. In the next lesson, we'll look at where you are at now and we'll do a quick self assessment to see how much you've actually absorbed in this course. So I'll see you in the next video. 32. Self-Assessment: Where Are You Now?: Welcome back. So by now, you've spent several hours learning the foundations of Agile project management. And in this short lesson, you'll take stock of how much you actually know now. So by the end, you'll have a clear picture of your strengths, your gaps, and where to focus next. Why even self assess in the first place? There are three main reasons that it matters. Number one, makes the learning real. Reading and watching is just passive, but reflecting forces you to actually engage with what you know. Number two, it shows you what to focus on next. So without honest self assessment, you might rewatch the easy Bit. And skip the hard bits. Now, this is a bad habit. And number three, it prepares you for interviews. PM and Agile interviews routinely ask, tell me about your experience with Scrum. So knowing where you stand makes those conversations easier. So we have a ten question check, pause the video, and you can answer honestly, and then come back. So there's no grading necessary here. Just notice where you feel confident and where you don't. So one, can I explain Agile in two sentences without using jargon? Number two, can I name the four values of the Agile manifesto? Three, can I write a user story in proper format with acceptance criteria for a project I don't currently work on? Number four, do I understand the difference between product and sprint backlogs? Five, can I describe what each of the three scrum rolls does and what they don't do? Six, could I run a 15 minute stand up meeting tomorrow with no prep? Number seven, can I explain the Moscow and the value versus effort matrix to a colleague who's never heard of them before? Number eight, could I write a one sentence sprint goal for a fictional project in one sentence that is outcome focused? Number nine, do I know the difference between a sprint review and a retrospective and what each one is for? And number ten is, could I set up a Trello board and a notion workspace from scratch, ready to run my own sprint? So those are the ten questions. Answer them honestly and come back. Next, what to do with your results. So three categories, be honest about which one you're in. This is very important. So mostly confident you'll have eight or more yeses, which means you've absorbed material very well, move on to course two when you're ready and start practicing on real projects. Mostly mixed would be 5-7 yeses. So you've got the basics, but some pieces are still fuzzy. Rewatch the lessons, covering the questions you struggled with, and then do the practice exercise again with a fresh project. Mostly shaky, less than five yeses. That's fine. It just means that the course needs another pass or you just need to review the vocabulary. Don't beat yourself up. Agile. It's a lot to absorb, so you can go back to Section one and work through it a little more slowly, making notes and keeping a glossary is extremely useful with Agile project management as a lot of the terms, yeah, a lot of the concept of agile project management are found in the vocabulary. So, finally, one more honest question. Did you actually do the practice exercises or did you skip them? So here's the truth. You can't really learn to run sprints just by watching videos. You learn how to run a sprint by running a sprint. So if you skip the exercises, your real next step isn't more content, it's going back and actually doing those exercises. So even one full mini sprint will teach you more than 20 hours of theory videos. Well, that's your self assessment done. Be kind to yourself, but make sure you're honest. In the next lesson, we'll do a quick project review to quick look at what your finished sprint should look like, so I'll see you in the next video. 33. Project Review: What Your Finished Sprint Looks Like: Hi, welcome to the penultimate video of this course. So by now, if you've followed along through the course, you've planned and you've run a sprint, in this lesson, we'll do a review of what that finished sprint should look like, what good looks like, what to be proud of, and how to talk about it in a portfolio or in an interview. So the artifact that you should have, your six artifacts, you should have these on paper or in your tools. First one, you should have a Trello board with a populated product backlog. Your sprint goal at the top, a completed sprint with stories in Done and screenshots of the board before and after. Two, you should have a Notion workspace with four sub pages, sprint planning, retrospective, decisions and stakeholder updates. Three, you should have at least one filled in sprint planning document. Four, you should have a completed retrospective with three concrete actions. And five, you should have your notes from your sprint review, and then finally, six, you should have links between Trello and Notion in both directions. If you have all six, you've built something real. Congratulations. That's a working Agile system. It's not just an exercise. Now, what does good look like? Here are the main five qualities of a good first sprint. So beyond just having the artifacts, how do we make this first sprint look good? Five qualities to look for number one, is that the sprint goal is clear and outcome focused, and you can tell at a glance whether you're able to hit it or not. Two, the user stories follow the correct format and have testable acceptance criteria. They are specific. They're not vague. Three, the work in your done list connects directly to the sprint goal. You don't have anything extra, and you don't have anything missing. Four, your retro identifies real things to change, not just generic platitudes, like, communicate more is bad. Move, stand up to 930 because 10:00 A.M. Clashes with X is better. Five, the documentation is light but useful, just enough to be helpful, but not so much that nobody reads it. So these are the five things. If you check all of these, and the answer is yes to all of these, then you know that your sprint can look good. Now, even if your first sprint was rough, there are some real winds worth recognizing. Now, you've learned a new mindset, not just a new methodology Agile is a way of thinking about work. The fact you can now spot waterfall thinking in your own habits is in itself a big shift. You've built something tangible. Most people who say they understand Agile have never actually run a sprint, but you have. You've created a portfolio piece. So whatever job you go for next, you can point to a finished sprint with goals, stories, retros, and reflection. You also prove to yourself that you can finish something these courses are easy to start, but they are hard to finish. You've done the work, so congratulations. Now, let's look at how we can talk about this in interviews. If you're job hunting, the sprint is interview gold if you frame it right. Don't just say I took an Agile course. That doesn't really tell the interview or anything, but you could say I run a hands on Agile project where I built a backlog, planned and executed a sprint, ran a retrospective, and ship X number of stories tied to a specific sprint goal. This is far more impressive and it's actually true. Bring the artifacts, show the Trello, walk through the Notion workspace. Most interviewers have never seen a candidate actually demonstrate their process. The ones who do will stand out more than anything. So also be honest about what you've learned. You could say, my first sprint, I overcommitted. I had to drop two stories. In the retro, I figured out that I had estimated based on best case scenarios. Now I always pad my estimates. So self awareness always reads as senior and highly professional. Now, if you want to use this as a portfolio piece, here's what you should include a short written summary, just one short paragraph of what you built and why? Screenshots of your Trello board before and after, with the sprint goal visible, extremely important. Your sprint planning document exported from Notion. Even the rough version would prove that you thought about capacity, risk, and commitment. Your retro with the actions that you identified. Now this one is gold because it shows you can self improve, you can improve a team. And optionally, you could have five minute loom video walk through of the project. It's only 5 minutes, and people remember the candidates who showed them rather than told them. If you have your own website, host it there or upload it to a public GitHub repo or share it using Notion public sharing feature. So make it linkable and make it tidy. Oh, congratulations. You've reached the end of course one. You've built something real. You should never undersell this. You've achieved something real that you can add to a portfolio and using interviews. It could get you a step closer to landing your dream job. So in the final video of this course, we will look at what's next, and we will look at the bridge to course two, which will be the intermediate course in project management. So I will see you for the final lesson. 34. What’s Next?: Welcome back for the final time in course one. Well done. You've made it to the end. In this final video, we're just going to look at where you go from here. We'll look at course two and what's in it and beyond. So yeah, you'll know exactly what your next steps are. So first of all, let's just do a quick recap of what you've learned. You've learned the foundation, which is more than most people who claim Agile expertise can say. We've covered the AgI manifesto and the Agi mindset. We've covered sprints, increments, the empirical loop. We've covered scrum rolls. We've covered backlogs, user stories, acceptance criteria, the definition of done. We've looked at how to set up a workplace in Trello and in Notion. Looked at how to prioritize, estimate and run a sprint. We've looked at how to run a sprint with stand ups, with mid sprint adjustments, with reviews and retrospectives. We've also looked at the pitfalls to watch for. So all of this is the foundation. So you know more than most people who claim agile expertise. So you could be proud of that. Course two is called sprinting at scale. So this is where course two picks up where course one left off, and it goes deeper into the intermediate skills. So you'll learn how to handle multiple sprint in a sequence. You'll learn how to maintain momentum. You'll learn how to deal with sprint over sprint changes and also managing velocity. You'll dive into the advanced scrum ceremonies into backlog refinement sessions, and you'll look at more sophisticated planning with deeper retrospectives. You'll also cover Kanban properly, how it differs from scrum and when to use it, and also how to combine the two in a hybrid approach. You'll also learn how to handle stakeholders at scale, managing executives, managing customers, and also managing competing priorities. You will also explore the tools beyond Trello. We will look at Jira, linear and Github projects, and we'll also look at when they're worth it and when they are overkill. So course one was just about running one spre whereas course two is about running a stream of them, which is closer to the reality of Agile project management. Now, course three is the advanced one. It's called leading and improving teams. This course is for people who want to run beyond simply running sprints to actually leading agile transformations within companies. This covers all of the soft skills such as coaching team members, handling team conflict, building psychological safety. It also covers the metrics and how to measure team health without becoming the metrics police. It also looks at the harder organizational stuff, such as getting buy in from leadership, dealing with resistance, and scaling Agile beyond one single team. This is the level where Agile stops becoming a methodology and becomes a leadership skill for your more senior roles. Some other places to learn beyond these three courses, if you want to keep going, we have some book recommendations. First is Scrum by Jeff Sutherland. It's short, it's accessible, and Jeff is one of the inventors. The Phoenix project is a novel about DevOps and Agile, which is weirdly readable, and finally, inspired by Marty Kagan is the Bible for Product Manager. Certifications you might want to take a look at the CSM certified scrum master and PSPO professional scrum product owner are the most respected in the industry. These are useful for jobs, even if the actual exam doesn't teach you much beyond what you've already learned. Great to have on your CV. Communities, the Agile and Scrum sub edits are great the agile alliance events and local scrum meetups are great. One of the best ways to learn is to come from talking to other practitioners. And finally, your own work. So applying what you've learned to a real project, even if it's just a side project is great. The next sprint you run, which will be in the real world. Teach you more than another course will. So one last thing before we close, Agile is by no means a perfect methodology. It does have problems, and it does get abused, and it can become bureaucracy in disguise. The best practitioners are the ones who use it pragmatically. They take what works, they leave what doesn't work, and they never stop adapting. So your job from here is to do exactly that. Run sprints, notice what works, notice what doesn't work, adjust it. This is the whole agile mindset applied to learning Agile itself. So Thank you very much for joining me for course one, which is the beginner and introductory course to Agile project management. Well done for making it to the end. Most people don't. I really hope this gives you a real working foundation that you could even use in job interviews and job applications. So again, thank you very much. Good luck with whatever you build next, and I will see you in course two. Goodbye. 35. Class Project: Create Your Own Agile Project: Now it's time to put everything you've learned into practice. For your class project, you'll create and manage your own agile project using either Trello, notion or both. Start by simply choosing one of the project briefs from the course or create your own project idea if you prefer. Then you'll build your project step by step. You'll create a product backlog, write user stories, add acceptance criteria, prioritize your work, estimate tasks, and plan your first sprint. Next, organize everything inside your project management tool and create a sprint board, showing how work will move from to do to doing to done. The goal isn't to create a perfect project. The goal is to demonstrate that you understand the agile workflow and can apply it in a practical way. Once your project is complete, upload screenshots of your Trello board, your notion, workspace, sprint backlog or any other project artifact you'd like to share. And you can also include a short explanation of your project and your sprint goal. This project will give you hands on experience with the same concepts and tools used by Agile teams every day. 36. Congratulations! What's Next? : H. Congratulations on finishing the course. You've now learned the foundations of Agile Project Management from understanding the Agile mindset and Scrum framework to creating backlogs, planning sprints, and managing work using professional project management tools. Most importantly, you've applied these concepts by building your own project, which is exactly how project management skills are developed in the real world. Remember, great project managers aren't created by memorizing frameworks. They become successful by continuously practicing planning, communication, prioritization, and adaptation. As you continue learning, try applying these techniques to personal projects, team initiatives, or even workplace tasks. The more experience you gain, the more natural Agile Project Management will become. If you haven't already, make sure to upload your projects to the gallery. I'd love to see how you've applied the concepts from the course. And if you enjoyed the class, please consider leaving us a review. It helps us improve the course and helps other students discover it, as well. Thank you for joining me on this learning journey, and I hope to see you in the next course.