Agile Fundamentals for the Workplace: Agile Project Management and Agile Delivery Essentials | Mauricio Rubio | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Agile Fundamentals for the Workplace: Agile Project Management and Agile Delivery Essentials

teacher avatar Mauricio Rubio, Serial entrepreneur, techie, life hacker, PM & MBA

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

54 Lessons (9h 44m)
    • 1. Promo video Agile Crash Course

    • 2. Intro and The Definition of Agile

    • 3. How is Agile Different?

    • 4. Agile Principles and a Little Bit of History about Agile

    • 5. Agile FAQs

    • 6. Key Agile Concepts

    • 7. The Agile Team and Agile Tools

    • 8. Agile Rituals and Agile Myths

    • 9. The Best Free Tool to Manage your Agile Projects

    • 10. A Real Life Example of an Agile Kanban Board

    • 11. A Real World Example of a non IT Agile project - Part 1

    • 12. A Real World Example of a non IT Agile project - Part 2

    • 13. A Kanban Board Example in Microsoft Planner

    • 14. Jira | Introduction

    • 15. Jira | A bit of history

    • 16. Jira | Initial Tour

    • 17. Jira | Components

    • 18. Jira | Agile Scrum Board - A Real World Example

    • 19. Jira | Reports

    • 20. Jira | The Backlog

    • 21. Roadmapping in Jira

    • 22. What is Teamsv2

    • 23. Teams Demo from Microsoft

    • 24. Resources and the App

    • 25. Resources and the App Part 2

    • 26. Initial Teams Tourv2

    • 27. Chatting in Teamsv2

    • 28. Create and Manage Teams

    • 29. Create and Manage Channels

    • 30. Everything else you should know about Teamsv2

    • 31. Agile Interview with Felipe Gomez

    • 32. What is planner and what to use it forv2

    • 33. Why plannerv2

    • 34. Initial Tour of Microsoft Plannerv2

    • 35. Providing feedback on plannerv2

    • 36. The official planner websitev2

    • 37. Support documentation for plannerv2

    • 38. Introductionv2

    • 39. Plans and Pricingv2

    • 40. Initial Tour of OneDrivev2

    • 41. How to Create, view and open files in OneDrivev2

    • 42. Uploading, renaming, downloading, copying, moving and restoring files in OneDriv

    • 43. Sharing files and folders in OneDrivev2

    • 44. OneDrive mobile examplev2

    • 45. Introduction what is zoomv2

    • 46. Getting Started with Zoomv2

    • 47. Getting Started with Zoom Part 2 Account Setupv2

    • 48. Zoom Account Overviewv2

    • 49. Hosting a Zoom Meetingv2

    • 50. Scheduling Meetings in Zoomv2

    • 51. A Real World Zoom Conference Callv2

    • 52. Agile Roles

    • 53. Before you start with Agile & How to get started with Agile

    • 54. Final Agile Recap and Final Words About Agile

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

Think of this course as Agile for Dummies (or Agile for anyone and Agile for everyone). This agile course skillshare will allow you to Master the most important concepts and tools of Agile Development, Agile Project Delivery & Agile Project Management. 

This Agile Course has been designed to enable you to become Agile the Agile way! You will become Agile certified when you finish this course (you will get a certificate upon completion) and you will learn from an Agile sensei and expert Project Manager.

What will you learn?

  • The key concepts and tools of Agile Development, Agile Project Delivery and Agile Project Management.
  • The meaning of user stories, daily stand-ups, retrospectives and kanban boards.
  • How to apply Agile in your job and projects.
  • The difference between Agile and traditional project delivery.
  • The benefits and advantages of Agile.
  • Why Agile is the preferred development methodology in the modern world.
  • About the history of Agile.
  • Why Agile isn't only for Developers.
  • Why Agile isn't only for IT projects.
  • How to use Agile to deliver quickly and often.
  • How to use Agile to learn from your mistakes.

Why take this course?

  • You will become Agile certified (you will receive a certificate upon completion).
  • You will be prepared to apply Agile to your projects.
  • You will be able to speak about Agile with confidence.
  • You will understand the difference between Agile and other methodologies.
  • You will learn from an Agile sensei and Agile expert who applies Agile on a daily basis.
  • You will learn why Agile isn't only for IT or Tech projects but it's actually applied across many industries worldwide.
  • It's short, effective and practical. Think of this course as agile in a nutshell.
  • It's been developed from the ground up with a focus on quality.
  • You will get tools and tips that you will love.
  • You will get the inside scoop on all my future courses.

How will this help you?

  • You will be able to deliver projects, products and apps quickly and often, the Agile way!
  • You will go fully prepared to a job that requires knowledge in Agile.
  • You will feel more confident about Agile and how to apply it.
  • You will be able to add this to your CV (just put it under "Professional Development" Agile Crash Course, Udemy and Year of Completion). This will help you land more jobs!
  • What you will learn will make you effective and successful :)

Who is behind this course?

An Agile Expert and serial entrepreneur, techie, life hacker, expert Project Manager and MBA (x2). 

This course is specifically for:

  • People who want to learn about Agile.
  • Beginners, people without any Agile experience or knowledge.
  • People who have heard the words "user stories," "backlog," "retrospectives," "sprints," "scrum master," "product owner," "MVP," "swim lanes," "kanban board," etc. and wondered what it meant.
  • Developers, Project Managers, Business Analysts, Solution Architects, Enterprise Architects, Data Base Administrators and basically anyone interested in learning Agile.
  • People who want to learn about an exciting methodology,
  • People with an open mind and a willingness to learn.
  • People capable of taking notes and applying the concepts and tools provided in this course.
  • People that think that traditional project delivery takes too long and want to explore other options.
  • People who want to learn about the most important and popular Agile Methodology: SCRUM.

This course is not suitable for:

  • People that prefer quantity over quality. 
  • People that like lengthy and theoretical explanations. 
  • People who aren't prepared to go through the entire course and take notes.
  • People who expect things to work out without any effort or preparation.
  • People who already have a lot of experience with Agile and are more intermediate to advanced.
  • People who want to learn about less popular Agile methodologies such as Extreme Programming (XP).


The Facts

  1. You will learn Agile!
  2. Agile is currently the preferred delivery option in technology projects and environments across the world. Yet Agile is not only for IT!
  3. Agile will allow you to deliver projects, products and apps quickly and often.
  4. Agile is the buzz word and a global trend. More and more people want to learn Agile every day in the world.
  5. Agile is not perfect and it won't solve all your problems. But it will give you a different view and approach to managing them.
  6. Agile is not suitable for all projects but it is for many. 
  7. Knowing about Agile will allow you to land more jobs and this agile course skillshare will help you prepare.
  8. You will enjoy this agile skillshare course, here are some examples of what people say about it:

"This course has an engaging conversational style and includes useful examples, images and explanations. I have taken some other Agile courses, and so far I felt this one gave me the most value, really helping me see how I could apply the Agile approach in the real world (and not just to IT projects). I gladly recommend this course to others. -Paul Tousignant"

"Had a great interview right at the beginning. Also boils down explanations into clear precise language with good examples eg. love the skateboard to car example. -Elizabeth Van Rij"

"Love the practical examples which printed in my head and I want to talk to my colleagues about this...Love it! -Madhuchhanda Pradhan"


Step into my Dojo and start learning about Agile now. You will learn about powerful tools and concepts that will enable you to become more successful in your projects. We will go beyond the definition of Agile, from rituals and tools, to activities, concepts, examples and reflections. So take the course now to learn what all of this means in more detail and how you can apply it to become and Agilelist. 

Production Notes

  • This course was developed the Agile way, in under 50 hours!
  • The creation process involved a high level of attention to detail and a focus on quality.
  • The 1st iteration of this course was a living example of an Agile Concept: the MVP or Minimum Viable Product.

Pledge to All Students (both current & future students)

  1. Students First. I will never compromise your experience to make money. Never, ever. Yes, this is also a business but to me teaching goes way beyond making money. I already have a full time job and fortunately don't rely only on teaching to survive. You are always at the forefront of my courses and I want to ensure you have a unique, valuable and memorable experience. I promise. 
  2. 24x7x365 Support. You can contact me 24 hours a day, 7 days a week, year round, even on holidays, Christmas and New Years Eve; I will get back to you quickly (in a few hours tops) and deliver outstanding quality of service in my support. I promise. 
  3. Humbleness, kindness and social responsibility. I believe in giving back to you and the world. So think of me as your own real-life human "Siri." If you need advice or support just ask. And if I can do something to help you in your journey, I will. I promise.
  4. Australian Made. Recognized in the Industry as a symbol of quality and excellence. All my courses are Made in Australia with high tech and professionally edited. They also include my secret sauce: a lot of passion & love! I also apply in my courses everything I've learnt from years of experience working with technology, projects, entrepreneurs and people all over the world. I promise.  
  5. Quality over Quantity. I will strive to make courses concise, to the point and relevant. Time is one of our most valuable assets and we need to invest it carefully. So I won't make a course long for the purpose of displaying it has more hours; only when strictly necessary. To me it's about quality and if I can deliver that in 5 minutes and save you time, I will. I promise.

Meet Your Teacher

Teacher Profile Image

Mauricio Rubio

Serial entrepreneur, techie, life hacker, PM & MBA


In a nutshell, I'm a serial entrepreneur, techie, life hacker, expert PM and MBA (x2). But at heart, I'm also an Educator. 

Mauricio in Numbers

Founded or co-founded 7 business startups.

Invested in 6 personal startups.

Studied 2 MBAs and 1 Bachelor of Engineering.

Teaching thousands of students in more than 170 countries worldwide (that's nearly every country on the planet!).

Traveled to 10 Countries and lived in 4.

Lives in the most beautiful city in the world, frequently ranked in the Top 10 places to live & visit.

Works for a prestigious University, ranked 1st in Australia and 8th in the world among young Univ... See full profile

Class Ratings

Expectations Met?
  • 0%
  • Yes
  • 0%
  • Somewhat
  • 0%
  • Not really
  • 0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Promo video Agile Crash Course: Hey, guys, in these agile crash course, I'm gonna teach you everything you need to know about agile project management, agile delivery and agile in general. So think of this course as agile for dummies or agile for anyone and agile for everyone. I'm a discourse, a crash course. So I kept it purposely on deliberately short, simple and very valuable. So all the information that you're gonna learning the scores will help you in your agile projects and anywhere where you need to work with the agile methodology. You learn everything you need to know about it from the basic concepts, terms, tools, tips. And I'll even provide you with templates and links so you can continue to practice your agile skills on further develop your agile knowledge. But beyond that, I'll even share with you pre adult courses so that you can continue to enhance your knowledge about agile product management and agile delivery. Man is more issue, and I'm a senior project manager and also a serial entrepreneur. I'm also the founder off the agile Knowledge Base or agile kb dot com, and they created the scores after traveling the world and doing agile training in different countries. And with that in mind, I said myself to create a course that would actually help people in the world not only understand what agile is and help our abilities and how they can use it in the projects, in any industry, across any region and in any country, but also that it would actually get a certificate for completion of the course. I would become agile, certified so that they could actually put it on their CV and start applying for roles in which agile was a requirement or right. Guys, I hope you enjoy it. And I'm sure you're gonna learn a lot of indie scores. See you on the next one by 2. Intro and The Definition of Agile: welcome to the actual crash course he scores will cover the most important concepts and tools off agile development and agile project management. But I should note that Agile is not on Lee for the I T industry, nor just for developers or project managers. Actually, anyone can apply agile across different industries in almost any project. But I'll go over which projects are better suited for agile later in the course. For now, let's just go over the basics. So let's start by answering what is probably the most important question in this course. What is agile? You probably heard the term a couple of times, and we're wondering what it meant, how it was different to what you were already doing on whether it was actually good or not . Well, I have good news for you. If you are able to understand the pictures you are seeing on your screen right now, then you're already going through the learning process of understanding what audio means, because it's pretty much what you're seeing there seriously. It's just that simple. The summarizes what agile is, and what it means is a methodology for delivering projects, and I wanted to give you an analogy because I know it will help you understand it better. So let's start with the left side. At the top, you have the process or traditional project delivery. As you can see, we start to build the whole car. Right. The Ferrari, the best product that has everything, all the requirements and all the bells and whistles. And we don't consider a project done on to reach that stage, so the actual delivery can take many months on, sometimes even years on. The customer might not be happy along the way, since he's just waiting and waiting to get something. But agile is quite different. Look at the pig below that. Do you see it? Agile is an interrogative process in which you deliver value through a basic solution and then enhance it. Over time, you deliver quickly, and you deliver often on throughout the whole process. You have constant communication and interaction with a customer to ensure he's happy with every product you give him. He can actually start using even your first iteration, the skateboard, to go from point A to B. Sure, it would be nice to have a car, but isn't escape or better than nothing. Isn't it better to have a skateboard while you built the car? That is precisely what agile does. So let's put this into a real Web development example. Say you were building a website to sell products from different categories, flavors and colors. In agile, you wouldn't spend months building that website. Instead, you would create a basic first generation may be just the home base, should get started and to get the concept out there, and then you would enhance it over time and start adding to it. Maura and more pages to the website Mawr on more product features over time. In Agile, we call the Pier of Time sprints and springs less generally two weeks. Now let's shift our attention to the right. Do you see the sofa? The analogy also explains a key concept in Nigel. Keep it simple. Build the minimum. You really need to deliver what the customer expects. And that relates to another key concept in Agile, which we call the M V P or a minimum viable product. So what's the minimum you can deliver? Which satisfies the basic requirement. So, like the tire with rope? So let's recap about the concept of agile, agile is a methodology to deliver incrementally. It's interrogative on time boxed, and that period of time, which is generally two weeks, is what we call sprints. And what you work on during those two weeks, which are basically features that value to the customer, are what we call user stories. But don't worry about the terms. You're learning them over time, and I'll go over these in more detail later in the course. For now, I just want you to start getting familiar with the concepts and terminology we're using agile, such a sprints and user stories. And if you ever hear the war iteration and get confused, don't be iteration is just another word for Sprint, which, as you just learned, is disappear of time to do something generally two weeks. But some things, even three or four. That is something for the project team to decide 3. How is Agile Different?: So how is agile, different to other methodologies or ways of doing things well, it's different in many ways. For example, in traditional project delivery, you would start off with an analysis space, which would take a couple of weeks or a couple of months. Then you would move to a design and spend again a couple of weeks or months, and then you would actually develop or code. After the process, you would pass it on to the Q. A team for testing on you would move to production at the end after testing so traditionally in a lot of product management and project livery methodologies, you wouldn't move on from one place to the other until that faces being completed until milestones and deliverables. Having met and signed off, you would also ensure that scope doesn't change and keep. That has constrained. It's possible, since various cope would actually translate in the product they can even longer than originally planned. And finally, in traditional development, you would work in the final solution from the very beginning de Ferrari, the long term vision, the product with all the bells and whistles. But you wouldn't do any of these in agile in agile you would actually test from the very beginning, not just at the end. You would also plan and analyze every two weeks or every time you finish your sprint, and you would deliver it charitably often and quickly. You would also embrace changes in scope when reasonable and required. Since you're working interrogative lee and building products along the way, you are able to provide more flexibility to your end, user and customer and involve them in the development process. From the beginning. This is one of the most important advantages of agile and a reason why so many business owner stakeholders and customers love it. They have direct input in the development process, and they do it from the beginning, and they do it often, not just at the end. Another thing that makes agile different is that agile focuses more on the actual work than on documentation. Now, please don't misinterpret this and leave this course with the misconception that Agile doesn't involve documentation. Agile also requires documentation by documentation is not the main focus. It's got short and simple, says the team needs to focus more on the work than on paper. In agile rose blur on. By that, I mean that, for example, everyone in the team can be involved in testing not just the people that would normally do it, because that's their official role tester or test lead. So, since in agile your testing and planning every step of the way, well, mostly members getting both that doesn't mean that Aaron has to test or their agile dictate that it doesn't. Some adult projects still use the official roles for team assignments in tax, and that's fine. The point you need to understand is that agile can allow for Rose to blur and overlap or complement one another. And that's okay. People embrace these in agile and support each other to ensure the team's success. Now, in terms of planning, will planning is adaptive and agile. I'm priorities can change for its sprint, depending on where the team defines and finally in agile requirements can change, and the team is open to those changes. That doesn't mean that agile dictates that that you should change requirements is just means that the team considers something no longer a priority. Well, it could be the sculpt, for example, say you're working on that e commerce website and after spring to you show damage the product owner, which is your customer or a person who represent him or hair. And that person now says that they no longer want to have a product displayed vertically but now horizontally in traditional project delivery, you might say, Well, you signed off on vertical at the beginning, and now it's too late to make a change. But in Agile, you would say to your customer, Sure, by the end of the next point, we will have another demo on show you the changes. The improvement divan scope is varying. You might negotiate with a part owner about some of the user stories off the next print on , moved into the next one, or maybe remove them so that you can actually deliver and meet their expectations. See the difference. That's agile. And that is why people love it. It's powerful 4. Agile Principles and a Little Bit of History about Agile: What you see on your screen is what we refer to us. Agile principles. No, I'm not going to go over each and every one of them because I know you can read, and I'll also create an article about them. But let's go over some of the key ones. Let's reflect on number three. This relates to the concept of sprints on delivering quickly and often in agile you delivering weeks, not in months or years. If you're taking many months to live or something, you are not doing agile. If you're taking years to deliver something you are not doing agile. These audio principal has to do with the speed of delivery, which, in the agile terminology we called the team's velocity. I will explain that concept later, but keep it in mind. The speed of execution is called Velocity in Agile on. Let's now reflect on number 10. Do you remember the example of building a skateboard to get from Point A to B instead of building a Ferrari? Simplicity is one of the most important, agile principles on one of the reasons why an agile you can deliver so quickly you build basic and simple solutions which satisfy the main and most important requirements. You build a skateboard instead of a car you then iterating and iterating on. Over time you build the Ferrari over time, not a one goal or from the beginning. Over time you build up as you go, and you enhance improve on release in has improved and release. People prefer getting improvements quickly, even if they are minor but valuable than waiting a whole year to get something done. Think about the mobile app in your smart phone. Have you noticed the automatically update frequently and that sometimes the improvements are minor but cool. That is agile. See, you have been surrounded by agile for a long time. You just didn't know it. But now you do. At the end of this course, you will be familiar with agile concepts and tools. So a lot of people think agile is new and that it's mainly for writing projects. And for developers and project managers, well, that is a huge misconception about agile, and nothing could be further from the truth. In reality, agile dates back to the fifties, but the real game changer was the release of the agile manifesto in 2001. I won't go over the manifesto in detail, but I'll add a link to the resource is so you can read about it. The manifesto is basically the essence off, agile. Think about it as the Bible off, agile And yes, it came out of the I T industry on from a group of developers. But no agile is not on Lee for developers and project managers. And it's not only for I T projects, Joe is actually applied to all industries and too many types of projects. I have personally applied agile to commercial projects, operations, projects and even personal projects. And I can tell you that agile works and it works well. Try it yourself and learn from the process. Reflect for improvement, which in agile we would call a retrospective that is basically the process of reflecting on your mistakes and how you can improve and do things differently. I'll talk more about that later, but for now, retrospectives is just another agile term 5. Agile FAQs: So let's go over. Some of the typical on frequently asked questions about agile. I've been doing agile for many years now, and I've worked with agile across many industries, many projects and different organizations. I've also worked with different teams, different team sizes and different applications, right? So let's look about some of those common questions that I get all the time because people ask me these questions, and I know you might have some of those questions. I thought maybe we should just go over them, right? So one of those questions is is agile Onley for developers and Onley for project managers. And the answer to that question is, no ideal isn't on Lee for developers, nor just for project managers. There's people using agile across very different industries and across very different projects, people in very different roles, working with agile. So you have, you know, testers. You have business analysts. You have architects. You have, you know, people working in financing Hey char in sales and operations and procurement in marketing. So pretty much anyone comply, agile to their projects as long as they understand how it works and how to apply. Now I'm not gonna say agile. It's suited for every type of project, because that's a different question, but actually certainly suited for the vast majority of projects. So if you want to do something that you want to deliver quickly, deliver often on, you want to work collaboratively that you're probably suited for agile. If you're an organization that has flexibility and allows you to go empowered and do some work and do it quickly, your products probably student for agile. But if you're working in a place where there's a lot of bureaucracy, you know you need things very documented. Things have to take a long time. There's long lead times. There's a lot of approvals very, very robust structure processes. And you know, this type of organisation is probably a little bit harder to implement, agile on our locations. It might be if the project, you know, is very, very big. You're you're meant to deliver it over a couple of years, then it's probably not a natural project, and it's more off a waterfall project. But if you're working on something that you want to deliver quick, you want to deliver, often you wanna have close interaction with customers the business owners want tohave provide input, and they want to provide input constantly to the process. They want to see what you're doing. They want to get something delivered to them, and they want to see it orations of that project than your projects suited for a Joe. So, like I said, agile can be applied to very different industries. Very different type of projects. Ah, across many, many, many disciplines. I mean, I've working personally on agile on sales projects, procurement projects, operations, projects on technology projects and, of course, agile works great and technology because, well, it was born in technology. But please don't go with the misconception that, actually just for technology, it isn't right. You can apply agile to other type of projects and other type off industries. So another question that comes up when working without Italy's people when they haven't worked without they kind of have this thought in the back of their mind, like is agile hard, you know, is it's really, really difficult, you know? Do I need to be a rocket science to do scientists to do agile on? The answer to that question again is no agile is not really for rocket scientists. You know, it's not really just for developers, really techie people. Anyone can do actual, you know. And that's why I created this course so you can learn about agile and you can learn how to apply it to your projects and even to your personal projects. You know, there's people using agile to plan weddings, and there's nothing wrong with that. There's people using agile to shop their groceries every week or to organize their house and how they do things with their family. And that's fine. You know, there's so many tools out there that you can used to implement your idol projects and work with them collaboratively with different people s Another question that comes up very often when you're doing agile is agile, you know, like, is it gonna change everything? Is it going to solve everything? It's not gonna change everything. It's not gonna sold everything. Of course not. You know what I do is not perfect. It actually is a tool in a process which you can use to n has the way you deliver projects , products and services to our clients. But that doesn't mean that you know everything else is an important and you should get rid of everything else that you're doing. Of course, that you can incorporate that into agile on Dwork work together with those things to better deliver your projects. But agile, you know, the beauty of actually is that it focuses on simplicity. It focuses on doing things quickly on often on, and focuses on working collaboratively with your team and with your business owners and stakeholders so that they're constantly involved with the outcome with what you are delivering. So another was just what you think you're delivering, but what you will deliver on at the same time ideal provides. And he's open, you know, for a scope variation and allows you to incorporate new things that come up. So in traditional project management, you know something, you comes up and you would be like, Oh, no, no, no, it actually you know, we already talked about that. You signed off on that, and we really were, You know, we're really in an advanced stage of the project. We really can make a change, is gonna derail the project that's going completely out of scope of the project and so forth. Right you naturally would never say that you would actually welcome changes on include them in your project, and it has adapt and be flexible to what your customers are asking for. 6. Key Agile Concepts: Now let's go over some key concepts in terms that are used in agile. Let's start with user stories. User stories are basically product features, requirements or tasks that add value to the end customer on by adding value, I mean that whatever it is, it's something that the end customer would actually pay for or they would find really valuable and important. If something doesn't add value to the customer, then it can't be considered a user story and should remain a task sub task or requirement. User stories are reaching a specific format, which you can see on screen. For example, as a customer, I want to be able to use my Facebook loving credentials to log in to the e commerce website so that I don't have to create a new account. As you can see, this user story provides value to the customer, since it helps him avoid creating a new user and password, hands saving him time. So in agile, we create user stories for all project requirements and features that add value to the customer, and then we add them to what we call the product backlog. The product. Back Luck basically contains all these are stories that will be part of the project, but of course, in agile that can be a changing list said you might start with, say, 50 years of stories on overtime at 50 more. How many you add or remove will depend on what you and your team define throughout execution on you have the flexibility and a tonal me to define that. Now The Sprint backlog is just taking a couple of user stories from your product backlog and adding them to your sprint and committing to the deliver of those user stories in that sprint. So basically, it's the amount of work you will do in those two weeks. Remember that in agile springs generally last two weeks, but you can make them three or four weeks if you on your team define that is what is best for you from experience. I recommend two weeks by, Like I said, that is not mandatory. And finally, the story points. The story points. Simply note the level of complexity a user story has so us eyeing story points to each user story you create. Personally, I'm a big advocate of keeping things simple, so generally I would recommend using a basic scale off 13 and five one being low complexity . Three. Being medium complexity on five. Being high complexity Now don't worry too much about spending a lot of time estimating your story points. Keep it simple. Follow your instinct. Experience on gut feeling. How many story points is something you can add which used her story as a team? Or you can also ask the person working on the user story what level of complexity they consider it has. The scale I have just suggested is just an example. Of course, you can create your own scale or use existing scales such as Fibonacci. Discuss with your team what scale they want to use and use it. And if it doesn't work well after you finish this point, you'll have the opportunity to discuss that in your team's retrospective or lessons learnt session and you can then a justice required. If you want to keep it simple, then follow my recommendation off. 13 and five. Now let's go over the concept off velocity. Do you remember? I said that velocity relates to the speed of execution? Well, basically, the velocity of an agile project is a number of story points the team delivers over a sprint. I'll repeat that the velocity of an agile project is the number of story points, the team, the labors over a sprint. And, of course, you will see variations of that, especially at the beginning, when you are just learning how many users stories you are actually able to deliver as a team. So at the beginning, you're kind of guessing or estimating how many story points you can deliver in a sprint. But after a couple of springs, you will be able tow, average the number of story points and then conclude, for example, that on average your team is able to deliver to any story points for Sprint. And that is your velocity. You will always be able to calculate your velocity at the end of your sprint. Once you have reviewed what you delivered versus when you had planned, your velocity is not what you have planned or what you thought you would deliver. It's what you actually delivered in story points. Swim lanes are a visual representation off the status off stories on the agile can been ward, but that is better understood with an example an official than by me explaining it with words. So don't worry. Ln the link in your lecture resource is so you can check what seems swim lanes look like and how you can use them. Now let's switch to one of my favorite concept seen agile, the M V P. And no, this does not stand for Most Valuable Player in agile M. V P stands for minimum viable product, and basically it means the bare minimum you can deliver to meet your customers expectations . So if you think about the example we saw earlier on the course, the AM BP is the skateboard, not the Ferrari. And this is really powerful, because this will allow you to deliver quickly and often and it a rate and build up and enhance your solution over time. This is a key, agile principle. I release, as the name implies is when you move your user stories to a production environment. So when you make them life generally agile teams make releases to production once a month, so after two sprints, but you might find some agile team making releases to production every four springs and not too so every two months. At the end of the day, that is for the project into the side. But remember, actually, is about doing things quickly and efficiently, so the shorter the better. But don't push it too much. Be careful with exaggerating. Try to keep a good balance and releases that keep the team comfortable. And finally, the sprint. By now, you're already for me there with what a sprint means. But let's recap anyway. A sprint is a period of time over which a team will deliver a set off. User stories generally springs last two weeks, but some teams may have their sprint set up for three or four weeks, and that's okay. You need to define what works best for you on your team, giving your specific context and project dynamics. But if you're unsure, started with two weeks and then change that to three or four if required. Remember, in agile, you're allowed to experiment so that you can review adapt and adjust to whatever works best for you and your team. 7. The Agile Team and Agile Tools: in Agile, A team basically has three main roles. The product owner, the scrum master and his livery team on most people fall within the delivery team. The part owner is the end customer or a person who represents the end customer on their main role in the agile project is defined priorities and provide input to the project team or what the team shows them in demo sessions. The scrum master is the agile Sensi. Think about him as a team leader and that could be a project manager, elite developer, a person who actually and formerly has a role of scrum master or pretty much anyone who wants to play this role and has actual knowledge. Ultimately, the main thing is that the team agrees on who the scrum master is, and of course they can also rotate the role if they feel like doing it. As all of you know, I work with agile projects every day. In some I'm the scrum muster. But in the some, the scrum master is actually a developer in others a tester, another's even an architect. Like I said, anyone complain this role as long as they understand the responsibilities and have sufficient agile knowledge. If someone hasn't even gone through agile training or finish this course at a minimum, then I wouldn't recommend that person to play the role of scrum master scene. He or she probably wouldn't do it properly. And finally, the delivery team. Well, that's pretty much everyone else. So developers, testers, business analyst, etcetera. The main responsibility of the delivery team is quite simple to deliver. They are in charge of getting the work done on our key to the team's success. Now let's talk about the tools using agile and don't worry if you feel you need more information. I let several links to all of these tools so you can go over them and read about them in more detail. The first tool I want us to review is the burn down chart. As its name implies, a burned on chart is a chart that shows the burn down off work. So basically, you see the number of story points the team is delivering over time, so your teens velocity on the X axis. You have your sprints on your Y axis, your story points, as you can see in the graph on your screen. You can do this mentally in excel or use tools that automatically do this for you, such as Vera. The great things about the burn down chart is that in it you can see several things about your project and your delivery. For example, you can see the total amount of work, the amount of work remaining and even your team's velocity. The Can Van Agile Ward is probably one of the most exciting things about agile and, I say, Exciting. Because of its simplicity and value. An agile, canvassed board is a visual representation of the work the team is doing in a sprint. You basically have three or four columns and your user stories displayed in those columns to reflect the state of those user stories. Generally, you would have a column with heading to do another one with the heading in progress, another one with heading in Q A and a Final one with done. Most ideal teams use a physical, agile can board and sticky notes aspirin, a picture you see on your screen. But a lot of teams also used digital boards. There is no right or wrong answer on whether using paper or digital use whatever works best for you on your team. Personally, I prefer digital boards on generally used Tello orgy era. But if a team prefers paper, I'm happy to do it and have no issues with using a physical, agile Cambon board. Al. It links under the resources for this lecture to the tools I just mentioned on to the examples off this concept. 8. Agile Rituals and Agile Myths: Now let's go over the agile rituals. Why do you need to understand Here is that agile is more than just a methodology or a way of doing things. It's actually more like a culture. Unlike in any culture, there are rituals or things you should do. In agile, you have four main rituals. Sprint planning, Daily stand ups, spring reviewer, demo sessions on retrospectives All are important and all contribute to an agile environment and culture. Let's start with spring planning in the Sprint planning, meaning the team gets together and defines witches, their stories they will work on over the next two weeks. So in this session, you're reviewing as a team the scope of work priorities on what you believe is achievable during the next sprint. The scrum master facilitates this meeting, but everyone participates during spring planning. The team reviews the backlog and fix the user stories they will work on over the next Sprint, and typically teams will play the selected user stories in their Cambon board under to do as they are planning for the next screamed. I'm getting ready daily stand ups as their name indicates our cold standups because the concept is that everyone should be standing up during the meeting because of behind this is that by standing up, it helps ensure the meaning is short, focused and productive. Daily stand ups have a sense of informality, and they function like a round table. Everyone on the team says what they did the day before, what they will do today on if they have any impediments, issues or anything they need support with. Like before the scrum master facilitates meeting on listens with special attention for impediments, since it is his job to remove them. Spin reviews or demo sessions showcase our meetings where the team gets together to review what was delivered in the last print. So this is scheduled right off their sprint finishes. And during the meeting, the team goes over user storage, which were delivered on the ones which weren't if any, not to the point of going or who is guilty. We're not delivering or pointing fingers, but to learn and adapt and mawr for the team's reflection. Sprint reviews are generally internal with everyone on the team, but sometimes people include the product owner to review progress. In reality, this can be done separately so you can meet internally and afterwards, plan for another separate session with the product owner In Agile. We would call this a demo or showcase session. Like a lot of things in Agile, this is up to you on what works best for you and your team. Personally, I tend to separate internal meetings from those with the product owner and stakeholders. But on occasions I do combine both meetings, especially if everyone is really busy and there isn't too much availability from team members or if they're working on multiple projects and have limited availability. Retrospectives are one of my favorite agile rituals. They focus on lessons learned on what you can do to improve or what your team should adjust to improve delivery and execution. It's a moment for reflection. This is something you do in traditional project management at the end of the project, and traditionally people would call them post implementation reviews P I. Ours or lessons learned. So in traditional product management, it could be months before you actually sit down to discuss lessons learned. But in agile, you do this constantly, right after a sprint on before your spring planning session during a retrospective you on the team should answer three basic questions. What, when? Well, what didn't on What should you do differently in the next sprint? So as we've discussed before, actually see terra tive and adaptive on retrospectives reflect that to you. Deliver, reflect and adjust deliver. Reflect on a just so given agile. It's a mystery for a lot of people because they don't know what it is or don't understand it well, there are a lot of myths or misconceptions around agile, and I would like to clarify about all them so that you don't believe any of them. Let's start with a very common misconception about agile, agile is anti documentation on Agile says we shouldn't document anything. Documenting is worth less completely untrue, false and a huge misconception around agile, agile has never said we shouldn't document, on the contrary with agile you order commanding all the time. Think about user stories of retrospectives you're documenting. What I don't want you to understand, though, is that you shouldn't spend hours and hours documented. Keep it simple, keep it lean. I've also heard a lot of people, especially business analysts say, that agile ease, anti planning again. Nothing could be further from the truth. In agile you're planning all the time. I'm probably a lot more often than you would in any other project management methodology. Before you start any sprint, you will be doing a short focus planning session, which in agile, is cold spring planning on your screen. You can see a lot of other misconceptions around agile, and I'm not going to go over each and every one of them in detail because they're pretty straightforward, and I'm sure you get the picture. But let's go over the last two. Aw, Jo solves everything. No, it doesn't actually is a framework and methodology on it can help you with a low things, but it's not perfect, and it's not going to save the world or so all of your problems. You have to be creative and proactive. To solve your problems. You have to act on just to think you have to work with people and together find the best solution. You have to collaborate, research and barren chart to solve your problems. But like I said before, Agile will help you in your journey. And finally, my personal favorite and one of the biggest misconceptions are on Agile is that agile is on Lee for I t projects. No, it's not agile was born in the i t industry, but it is currently used across pretty much every industry in the world. People even use it for personal projects such as planning weddings and so on. If you want to see examples off agile in different industries, just google it Google agile in tourism or agilewing sales, you will be surprised to find how many people and companies are using agile in the world. Trust me. Ah lot. I'm not just people in i t. 9. The Best Free Tool to Manage your Agile Projects: all right, guys. One of the first things I want to talk about today. He's about trail. Oh, it's one of my favorite project management applications, and I show you in a second why I like it so much. So let's just go to a pillow dot com. It never seemed trailer before. It pretty much looks a little bit like this is just a board where you can put tasks. Project faces what people are working on. You can set due dates, create checklist assigned test to people. You could do a lot of things that trail, and it's very, very easy to use. Very intuitive. You don't need really much training to actually start using it. You just have to give it a go, and you'll see that is very much pretty self explanatory. But aside from that, one of the great things about trail Oh, he said, it's free, and there's no limiting the number of users that you can have working on a project there. There's no limit off the number of projects you can put their in your trail. Oh, so that's one of things I really like about it, that it's free. Easy to use unlimited users unlimited projects. There is a paid version which has more advanced functionality. But I found that the free version works pretty well, So give them free version ago. And if you feel you do need something else, we're more advanced. Functionality pay for the paid version. But like I said, I've never really had to use the paid version. You know, with the free version. It's always been more than enough, and I'll show you about it in just a second and I'll walk you through the whole process so you can see how you logging, how you register, how you set up your project, how you set up your task, everything. How you do it. All right. Before I do that, I just want toe look at a video of trail Oh, to give you just a quick introduction about it. So let's go to YouTube and that search here for trailer. You can see a lot of videos here about Trey Low, like I said before, so just give it a go and explore some of them. Ah, have looked at a couple of already, So I'm gonna go over this one. You should really like because it's very short, very simple and explain pretty much what you do with trailer. So let's go here with this one trailer Quick over you. - Music and good music. I hope you do too. It's never been to a party. Wait right there. How awesome. Hilarious. It's just really awesome. He has a moral obligation, by the way, which is also free to use. - All right, so now that I got you really excited about trail oh, let me show you how it actually works in the real world. So let's go here, and I'm gonna do it from scratch just to show you how it works. So I'm gonna sign up free, and I'm gonna put in my name here CEO Rubio and online Demo D Come and I set up my password . And yes, I'm gonna set the terms of service and privacy, and I'm gonna create my free trial account. So will create now, Bam! That it really fast? I mean, already, right. They sent me an email 20 bucks course just to double check that these actually at genuine email and and so they verifying my account. We can just in a second as Well, let's go to Gmail Online Demo D. That's right. So, going to our account right there. Trillo account information and click on that. I say yes. Verify my email address. So it's it. I'm not very fine. I'm gonna close this other one, which is the one we're seeing before I was verified and then close YouTube as well. Gonna leave the female open right there. Let's go here to welcome board. All right. So, like I said before, hello is very, very easy to use. And you can do a lot of things with it. So let's just go here to create a board on. I'm gonna call these project example. One. All right, So it's a first product sample, right? So, I mean, this is a project, right? So what can I do now? Now that I'm here? Well, you can use trail. Oh, in a lot of different ways, and I'm gonna walk you through some different examples to give you a sense for it. Let's say you want to keep it really simple and go with an agile approach to the project so you can just create probably three main lis to do doing done that, too. It's actually at tomb. Or let's say, Q A quality assurance, and I'm gonna put that before we actually market done. And another one I'm gonna create here is something I like to call the parking lot, so out of scope for ideas. And this one is really used for stakeholder management because a lot of times when you're working with stakeholders or different people in a project, they might start, you know, throwing at you a lot of ideas and you don't have the money for it. You don't have the time for it, and you don't have the resources for it. But if you don't listen to them well, people will feel that you're not really paying attention. They'll disengage very quickly, and it's just not a good practice, so you actually have to listen to them. But it doesn't mean you have to do everything they tell you to do or everything they want you to do, because even though you might want to help them like I said before, there might not be enough money in the budget or it's just something that is completely out of scope. So if something, you know someone comes up with this crazy idea. You know, I want to go to the moon and we can't really accomplish standing project. I'll just put it here as a task that will review later. I want to go to the moon. All right, so you can say to whoever came up with that idea, we'll look at how we could get to the moon later. It's not right now in the projects cope. But I'm gonna take note of that and you will have visibility right here in your trail. Oh, and this is just an example. Like, I was saying off how you can manage a project in trail. Oh, and I'll walk you through some other ones. Let's just continue with this one. So because it to do doing q a done. And this is what we're calling agile can bend board so you can put here your use their stories In agile we would say a user stories kind of like a task. But you say ass Ah, roll. I need to do black So that black right? So, for example, as a project manager, I need to create the project schedule so that we can confirm all the tests that need to be done in the project. That's Ah, mouthful, right? It's really long. So in general, you're gonna notice that people that work in agile don't really follow full template or for use their story, and they just write it down. It's a task I want a normally recommend people working on projects. Is that it? Keep it really short because, you know, people want to read these long things and that they just put it in inverted 10. So you should start because you're it's actually an action, right? We want control, what people are doing or what we are doing ourselves. So it should start with a burb because a verb denotes action, Right? So let's say here I we're talking about a schedule. So create project schedule, right? I also need to create the project budget, right? I don't know. Let's say this is an application and we're working on some mock ups, right? So every year develop, Can you show this sign for the app, right? And I don't know, create Paul far image. Let's edit that cause I forgot the all right. It's really easy. As you can see it really, really quick. And if you go to each of these, for example, create project schedule, I'm gonna assign that to myself. So I'm going to say Maurice is gonna be working on that task. I'll put him on that and I'm also going to say and it's to finish this by next week on Tuesday. Andi save. So here's the due date. All right there. And I can create a label. And I can say, you know, this is part of the planning phase of the project. So I'm gonna say this planning and done and I'm gonna mark that planning phase with Blue. These are actually split with yellow with yellow create. Done. So now I know this part of the planning phase of the project. I know Maurice is working on it. I know when he needs to complete it on. I cannot Some notes for myself or I can. Other people can have notes here, right? It's kind of like social media feed. You know, where you different people can join the conversation so I can put here, for example. I know for myself include two weeks for details, planning project right and done, and I can leave the common there. I can even edit it. I can delete it. It's really awesome. I love the stool. Like I said, it's really easy to use is really intuitive. I don't have any other people in the project yet, but if I had other people invited to the project could just select them from here. And how do you invite other people? Well, if you recall, there was this menu that I hid, so if I can hide it, I can sit here at members and then I can just under email address and send them in and bite on. Because Tarallo is free, they don't need to pay anything that can start using it. And there's a lot of other things here. You can see you know, the latest activity off everyone that's working on the project. So, like I said, the trailer is is really awesome. I really recommended I've Houston on multiple projects. I'm not going to say you need to use this for every every project, but it's a really good tool. It's a free tool. And for being a free tool, it's just really powerful. And let's say this is doing It's something. I'm working right now, you know? And so I just put it here. If it's under Qiwei, I sent it to my manager for him to review, so I can put it then. Q A. You know, a few days later, I'll just go here, and this is now on their I cannot note for myself or for anyone in the team to look at the review with management. You know, they're looking at the project schedule and they tell us in a few days if it's approved and when they approve it, I could just say, done. You know, we finished the party schedule and let's say the budget, you know, the social part of planning. But you could create more labels as well. Like I was saying that say, when I created another label, Great new label. I'm gonna say thesis board of implementation. And we're gonna mark that with this. Ah, red color here. Right time, time actually created products. This one is not part off implementations. I'm gonna take it out. Take it out. This not part of implementation. Creative ready budget. That's the planning phase by let's say this create Alfa made image. It's part of implementation so I can add the label here, and that's pretty much it. But check out this really cool feature about this as well. You can go here and you can filter what people are working on. And I want to feel to buy the planning face so I can see which that passed their proper planning. Or I could feel to buy, you know, the term of this one. And let's filter by. Mauricio What's he doing? So is working on one task. That's a very, very basic example. Like I say that you can you can I have a lot of fire things and remove the filter shield task, and I'm gonna put here a lot of Father are tasks, but you get the idea, you get the picture. So I'm gonna go here to my main board cello, and I'm gonna create another project, not a team, but another project. You can separate also your different projects by teams using dysfunctionality. Let's say I'm gonna create another project project example to right. So here's a thought about another way you can use Trillo. Let's say you want to put here your project faces. Let's talk about. So we talked about Discovery, planning, implementation on closure, and you can start arriving here all the tasks that are part of each of the faces on these in a way you could use trail. Oh, like I said, it's just open for your creativity and innovation in the way How you want to use it on Let's go toe another example again. Create a No. One here project. Example. Three. I think it's pretty Example. Three. I'm gonna put here for the task for each person. So I'm gonna say here, Mauricio, we have here Michael what? He's working on Shell, Robbie and Charlie. And so everyone things another way. You can use trailer to manage her projects. You can put board for each one, a group of lists or task for each one so they can either test here or you can add it for them. And then when they're finished, you could just move into done. You know, you could just they'll tell your teammates Hey, Michel, you know when you finish those designs just more than two done and they can get themselves or you can do it for them and there's a beautiful this is travel. Like I said, it's it's really easy to use its amazing on. It definitely recommended us how one of the key project management tools which you can use . All right, guys, I'm gonna leave you with that one. But I'll talk about some other project management tools, which you can use in a moment. 10. A Real Life Example of an Agile Kanban Board: Hey, guys. Next I'm gonna show you a really life example, often agile Can Van board for one of my projects, and this is a really life project that I worked on a couple of months ago. In this example, you're going to see that we had each team member with their own set off user stories. So we had the work in progress where we called in the product in the work in progress, which is basically the same as doing when we doing agile board and we create a column called Doing in this case. We called it a work in progress, and then we had to done at the end of the campaign board, which is something that you also have so generally when you create a Cambon board, you have that to do doing. Sometimes you have Q A and then done where you have the cure or not. It's optional. It's up to us, a team. Sometimes some agile projects would just or some agile teams would just do as part of their user story performed the Q A with theme to use their story, and then when they complete the user story, they would move into the done. So in this case because we're working on a project that was a huge massive project and because it was so big and it had so many different streams of work, you have to set up the agile can be on board a little bit different than what you normally would. But the beauty of this is I can show you how you can adapt agile Cameron board to your real life scenarios. So, like I've said many times before, Agile is very flexible. You don't have to play everything by the book. You have to learn and take what is the best that you can find and adopted and adjust it to your real life project or scenario in our particular case, like you're going to see in a moment because our back look was so big and we had so many things in it to do. We actually separated that in our trail. Oh, in a separate board toe are work in progress and our completion. And even when we were completing the work, we would move the sprints toe a separate list just because we had so many springs we were working on right. So we were working on monthly sprints in this case, and we did that just to make it easier for us as a team to control the timing and the work that we were doing. So basically, we set up each sprint exactly asper the calendar month off each month. So basically, we're talking about four weeks prints, right? And in our case in this particular project, that made a lot more sense for us because we're working on huge initiatives and we needed a little bit more time to complete her are sprints. As you already know you don't have to do for weeks. Prints generally springs are two weeks, but some agile teams 23 or four. It's entirely after the agile team onto their particular scenario to decide which Sprint duration works best for them. Like I said in our example, we chose four weeks because we're working a massive, massive project over multiple sprints, multiple streams of work, multiple stakeholders and different areas of the business. So these particular adaptation of the camera on board to our particular business need made a lot of sense for us, and it worked quite well. As you'll see in the example, we had all the user stories each team member was working on. We had our Donna completed spring least of user stories, and we had a separate backlog and a separate list off everything that we had completed for all for previous sprints. So it worked really well for us because we could rest reference of work back really easily . We could also assign story points. We could also look at our velocity and how we're progressing on this also helped us when we're doing our retrospectives and looking at what we have accomplished and how we have done in that particular spring. So without further ado, let me take you right now to the example we just discussed and you'll be able to identify and see their riel life examples off what we've learned so far in the course. I hope you enjoy it, and I hope you make the best of it. Cheers, way 11. A Real World Example of a non IT Agile project - Part 1: Hey, guys. So in these next part of the course, I want to show you are really life example off one of my agile projects where I created a podcast in less than five minutes. That's right. In less than five minutes, I was able to create a podcast using agile principles. And what I did was basically what we would call in agile. If you remember, we talked about the concept of M. V P. Minimum viable product. And I'm gonna show you how I created a podcast in this next part of the course on You're going to see it really life, because this is a really world real life example. And it even has a timer. So you can see that I did this in less than five minutes. And this is the beauty of a John. This is the beauty of the concept off M v. P, in which you can create something of first iteration in your sprints and Daniel in iterated and enhancing over time like we do in agile. Right? So we thought further ado. Let me just show you real quickly. And I have this already opened on another tab. This is the learn about podcast and these learn about podcast is the podcast that I created in less than five minutes, and I wanted to show this is, ah, riel life example of an agile project because I often get get asked about examples off non I t projects, and this is a perfect example of it. This is a non ICTY project. It is basically a creative project in which I created a podcast in less than five minutes, and that's beautiful. I love it because it's such a great example off how, in the first spring I took the focus off doing an EVP, just getting everything ready to launch the Parkers without even adding any outer to it. So I just launch if you can believe that apartment without any audio on it. That's how it launched it initially. That was the concept of the M V P minimum viable product. So the first print I was just solely focused on launching and getting it out there. You know, putting a title, putting an image, describing where the part cause was gonna be about making really simple super in Torrey, super intuitive, super user friendly and right after I launched it on by then added audio on the second and third Springs. That's what I was focused on, right guys see in the next one. 12. A Real World Example of a non IT Agile project - Part 2: and 13. A Kanban Board Example in Microsoft Planner: Hey, guys, in this part of the course, we're going to see a real world example often agile. Cambon board for one of my agile projects, using Microsoft Planner and Microsoft planner is a really good tool to use for your actual camp on board, because it pretty much allows you to do everything you were doing. Another to elect Trillo. But right there directly in the office 365 suite of Microsoft, which us you already know, integrates seamlessly with all of the Microsoft brought such as Word, Excel, PowerPoint, one drive, etcetera. So it's a really good tool if you're working in a corporate environment or in a company who used his office. 365 If you're in a company who's using office 365 Probably the best tool you can use for agile Cambon board this Microsoft planner. So Microsoft Planet, of course, has its own terminology that Microsoft uses such as, for example, buckets for the columns that you see here. But don't pay too much attention to that because mainly, basically, what you can do in Microsoft planner is personalize it to whatever you like, and in this case, what I have done is I've personalized each of the buckets or what Microsoft in Microsoft Planet calls buckets or for US columns. Here, I personalize it to the columns we would normally have in a natural Cambon board. So I have here that to do, doing Q A or quality assurance done and then parking lot off or ideas, which is basically everything that is out of scope from the project. All right, now, generally, when we're having our adult can one board we want to adhere our user stories right? And if you remember, the user stories are basically product features that are coming from their projects, requirements around things that need to be done right. That's generally when you're thinking about the theory off, agile right. But in practice, we know that this generally tends to be created as tasks. So what people are working on in the project, which we commonly refer to US product tasks or tasks, end up being pretty much your user stories. And that's where you're seeing here on screen. Now I know that in theory, that is not exactly, ah, 100% accurate in the sense that tasks are not necessarily user stories because a new user story ultimately needs to be driving, generating and creating value for the end user. So you might have a task that you might need to do its part of the project. That doesn't necessarily provide any value to the end customer, but you still need to do it right. So the best way and the way I recommend to all people working on agile and these from years of practice and years off knowledge on agile is that you manager product task in your agile Cambon board as you would your user stories. So basically what I'm trying to say here is your user stories are pretty much equivalent to your project tasks, right? Or your project tasks are pretty much equivalent to your user stories in agile All right, So I've talked about before, and you might have heard me in other parts of the c