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

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

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

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

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

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
54 Lessons (9h 44m)
    • 1. Promo video Agile Crash Course

      2:05
    • 2. Intro and The Definition of Agile

      4:20
    • 3. How is Agile Different?

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

      3:26
    • 5. Agile FAQs

      5:09
    • 6. Key Agile Concepts

      6:49
    • 7. The Agile Team and Agile Tools

      3:43
    • 8. Agile Rituals and Agile Myths

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

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

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

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

      4:32
    • 13. A Kanban Board Example in Microsoft Planner

      28:10
    • 14. Jira | Introduction

      11:44
    • 15. Jira | A bit of history

      10:54
    • 16. Jira | Initial Tour

      26:02
    • 17. Jira | Components

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

      43:35
    • 19. Jira | Reports

      9:57
    • 20. Jira | The Backlog

      15:44
    • 21. Roadmapping in Jira

      12:05
    • 22. What is Teamsv2

      6:16
    • 23. Teams Demo from Microsoft

      15:56
    • 24. Resources and the App

      4:25
    • 25. Resources and the App Part 2

      3:14
    • 26. Initial Teams Tourv2

      11:36
    • 27. Chatting in Teamsv2

      7:47
    • 28. Create and Manage Teams

      20:21
    • 29. Create and Manage Channels

      12:23
    • 30. Everything else you should know about Teamsv2

      10:09
    • 31. Agile Interview with Felipe Gomez

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

      5:15
    • 33. Why plannerv2

      7:49
    • 34. Initial Tour of Microsoft Plannerv2

      24:22
    • 35. Providing feedback on plannerv2

      3:21
    • 36. The official planner websitev2

      5:33
    • 37. Support documentation for plannerv2

      6:45
    • 38. Introductionv2

      7:11
    • 39. Plans and Pricingv2

      7:29
    • 40. Initial Tour of OneDrivev2

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

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

      13:46
    • 43. Sharing files and folders in OneDrivev2

      25:29
    • 44. OneDrive mobile examplev2

      7:09
    • 45. Introduction what is zoomv2

      6:00
    • 46. Getting Started with Zoomv2

      10:21
    • 47. Getting Started with Zoom Part 2 Account Setupv2

      9:44
    • 48. Zoom Account Overviewv2

      7:09
    • 49. Hosting a Zoom Meetingv2

      5:43
    • 50. Scheduling Meetings in Zoomv2

      12:36
    • 51. A Real World Zoom Conference Callv2

      23:11
    • 52. Agile Roles

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

      2:07
    • 54. Final Agile Recap and Final Words About Agile

      2:29
32 students are watching this class
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

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.

3,232

Students

--

Project

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

Teacher

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?
  • Exceeded!
    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.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

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.

phone

Transcripts

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 course took about user stories that they have a certain way of being written right? So they have ah, format, right Normally that format, or the way in which you write user stories goes something like this, as uh and then the role I need to and then the what So that, and then the Why the valley? The reason you're doing that right? So, for example, as a developer, I need to create a Facebook logging so that it's easier for users to log into the site. Now that's a mouthful, right? That's a mouthful. It's a really long format, and that's what agile in theory requests and asked that you do on. I think it's OK if you want to do that when you're starting or when you're initially getting family are with agile or if you wanna, you know, follow the rules by the book. But in practice, what happens is it becomes a bit repetitive when you see as I I need to solve that block right as I need to so that blood it becomes a bit repetitive and redundant. And then it just is something extra that you have to write because we know human nature is about abbreviation keeping it simple, which in a way is what agile also is all about. That's why you see here that in our user stories for these project, we haven't used a four month off as I need to solve that block. What I recommend people that are working with me on Nigel projects is that they start the user story with a verb, right with verb because of birth implies action. It's something that you need to do. And that is basically what a user story, in essence, is something that you need to do that delivers value for the end user or the project right ? Something that needs to get done in essence, what we would normally call in projects a project task. Right. So this is a magical fragile in an agile Cambon ward. You can manage your user stories and you can manage your springs, and you can see where the project and the people are part of the product are in terms of their performance in terms of their execution, right, because you can easily see, as you can see here at a glance like you can see in Planner, Microsoft Planner allows you to assign the role that the user story to someone that is to a specific person or to more than one person, that there are two people working on that user story, right? And that's why you see, for example, here in this part below, this is me and Maurizio and this is Suzanne was someone that's working with me on this project. These user stories being assigned to Mirage is working on this other one. Here's Kevin working on another one hears me again as well, right? So basically, in this project, what we're doing is working through weekly sprints. So we have a weekly spring cycle. We do our spring planning session. Well, Thursday's and then every Thursday, we assess how we went on the previous sprint. We're doing also our daily stand ups that normally when we're doing our daily stand ups, it's a little bit more informal. So we don't have these. You could, but we don't in our daily standards. In this particular case, we don't actually have these digital board with us. When we're talking about our stand ups a little bit more informal. It's a very short meaning, but we're doing our weekly spring planning. We actually through go in detail through the actual Cambon board, and as we're going through the agile Campbell on board, it's a bit like a roundtable on. We can feel ter the user stories by the person whose executing them so here as you can see at the top, and I'm gonna talk a little bit about Planner. So, for example, here in the top, many of planner you have you have members or people that are part of this project. You have filters and have group by bucket, which is basically another field to the way you see the information. So right now I'm filtering by Bucket, but I could also do assign to it would basically show me all the user stories assigned to a particular person. I could see my progress by Judeh by labels my priority so I can filter the information by different things. And in this Sunday's gonna quickly show you that I can feel trade by assigned to. So it's basically showing all the user stories. Who's assigned. Ho has each users to reassign. So, for example, like you can see here that I'm working on to at the moment and they've been completed 29. And if I scroll to the right, I'm going to see that for the rest off the project team. You know what? I can see what they're working on each individually with their user stories on how much they've actually completed so for example, here for Kevin because he's working on three of them and that it's already finished two or right up to use their stories. And like I said before, we're doing these by spring. Now, this is why me using the filter assigned to I'm just gonna go back to buckets and we keep agile. Come on, board configuration that I manually set up for these can been bore here in Planner. And as you can see, I have a to do doing Q A, which is crawling quality assurance or done now, as you're moving user stories between the different columns, it doesn't necessarily mean that, for example, the this isn't necessarily mean that all use your stories have to go through Q. A. Right que. A quality assurance is basically when you want someone to real someone else to review something that you've done to perform quality assurance on what you did So some things. For example, I might be working someone Developer might be working on user story, and you might want a tester to look at it or him. Or he might want me as a project manager to review what he did on just to check it so we would put that user story here in Cuba. Honest and I we would actually re assign it to someone else. And then after we reassign it. So, for example, here, let's say it's my job to review this. I would change this from here. I would remove Suzanne because she's not working on these anymore. And I would assigned myself here. If I click on a sign I search for my name. Mauricio, This is me and I signed that to myself. And that basically means on I'm gonna have here. This is ah, medium complexity task, which has three story points you can see here, all right. And I'm basically now that's saying this example that I'm giving you right now live I'm basically reassigned these user story to myself so that I would actually Qiwei it. I actually review what Suzanne was doing before because she finished the user story and then she wanted me to check and see that I am happy. Once I'm happy with that. I would just move it to the done column in the actual camp on board, and then it will automatically be marked complete. My planner or alternatively, I can just take here, and it will mark the test complete. All right, but because we're still working on this one, I'm gonna put it back here, and I'm gonna reassign it to Suzanne, who is a person actually working on this. So I'm gonna sign this to Suzanne, and I'm gonna reboot myself from it because I'm actually another working on this ist. It's test. It's a user story that she's working on, and that's why I left it here to just to show you quickly. All right, So Microsoft Planner, you have here basically are kind of like cards similar to what you would see in trail. Oh, and you can move them across the different columns in your agile Cameron board, which basically allows you to see what is the status off the task or the user story in this project in this sprint, Right? Like I said before, we're doing weekly sprints on this project. And one thing that is important, which you might be wondering, is, how do I reflect on how do I put the story points for each user story in these agile can been bored. So the best thing I'd recommend for you is that you use labels. So if you go here, I'm gonna click on this. Particular creates like that for fear. Pilot results these user story and you see here than Microsoft Planner has labels by default. These appear empty and you can actually type text into them. All right, so we basically in the project team, we assign this three colors a green one, the orange Juan and the red one. Low complexity meat complex and high complexity. Local black city tasks have one story point, as you can see here when I'm holding over this one story point, Orange has three story points, and you said, You see there that it says for this task Nice Microsoft's planner terminology because that is common terminology used in any project. Like people talk about tasks. That's how traditionally people have managed projects and that's hope. People understand projects, But like I said, in agile, we generally don't talk about task. But instead off we were talking about task We talk about user stories. Doesn't matter. Like I said before, this is just for, you know, Microsoft Planner uses the terminology task, but you can refer to it in your team and in your agile projects. Ask user stories. Like I said before we go to the theory of valuable user stories are not necessarily is exactly equivalent to tasks buying practice. When you're implementing and working through your agile products, you will see that pretty much tasks become user stories. And that's why I say to you, Don't worry too much about it and just think of your user stories as basically tasks within your agile projects. All right. And then you see here that I have a medium complexity task. We chest three story points and then a red one, which is high complexity Stass core user story, which has five story points. So basically 13 and five right, and that is the story point scale we're using in this particular project. In this particular example, that doesn't mean that that's the exact, you know scale that you have to use in your agile projects. Just that's just what we use in this one. And that's basically what I would recommend. As you know, you can use custom made scale. You can create your own scale. You can use Fibonacci sequins as your scale you can use. You know what pretty much whatever type of scale you want to use. But because agile is also about seem place city flexibility and agility itself and doing things faster and keeping it simple. What I normally recommend my students is that they use ah, very simple scale. A scale of 1351 local black city three medium complexity five high complexity user stories and then same in terms of the numbers. One story point for local plexi. Three for medium complexity on five for high complexity. And that's exactly what you're seeing here in these example of financial Cambon board in Microsoft Planner, Do you see here the colors low wants to re point the green one. The orange one. Mid complexity. Three story points on the high complexity one five story points, which is the red. All right Now, I could use that also in the filters hearing Microsoft Planner I can say here feel ter by and I could go here, and instead of filtering by people, I could actually feel to buy label right so I could actually feel to hear and say Show me all the one story points user stories. If I click here, you see that nine seeing on Lee the ones with the green label which, like I said before, are the low complexity story user stories which have one story point. So basically, if I was looking at this print, for example, I would add up. The story points from all of these user stories to get how many total story points we having that sprint, right? That's basically how you do it. But you wouldn't do it, of course, just with their low complexity story point. But all the story points that are part of that sprint. But like I said before, don't worry too much about that right now. I just wanted to show you real quickly an example of financial Cambon board like a real one in practice and how we use it. All right, so we can also feel turn like we did before. I'm gonna just scroll on the top by the labels and again labels. He's a terminology from Microsoft Planner. We've used it here to convey and showcase the number of story points. It doesn't mean you have to necessarily use it this way is just an example on how I would recommend that you use it in your agile projects. Eve, you're creating an adult Cambon board in Microsoft Planner. All right, so we could also feel to buy that mission. See, also that made complexity use their stories. So and I'm seeing the mid complexity and the low complexity. But I could remove the local black city right, which is the green one. Let's remove their green ones from here. So if I click on this again now it's showing me on Lee the medium complexity user stories on. Then I could do the same for the high complexity here on just like the red on de Select their Orange. And then I would only would see that I don't have a lot off five story points user stories in this particular sprint basically one in progress and what one that's been completed, All right, so I'm gonna clear this a week. See again the whole Kammen board, right? But this is basically how you can use Microsoft Planner to create an actual camp on board. You can rename what Microsoft Planet calls the buckets or the columns to to do doing Q A done on parking lot ideas. And then as you're creating your user stories, and if you're wondering how you do it is very simply, Microsoft Planner. You just click here on the plus button on that's how you and your easier stories. So, for example, if I click here and I do example, use her story All right, this is just an example, and I'm gonna click enter, and then I'm just double clicking on this so I can expand If I double click or I just click on it and I can expand these your story. I'm gonna say this has five story points. So it's a high complexity user story, and I'm going to say, Let's assign it to Mauricio, All right? And this is just planner functionality, so I could give it a priority if I wanted to. I could write a description. I could create a checklist. I could add an attachment. I could add comments. So this is one of the really cool things from Microsoft Planner. It has a lot of really reach super easy to use super simple functionality. Now, if I wanted to add a due date as well, I could, and then it would just, for example, let me just go back to the U cities, This calendar here and that it's in red. It basically means this isn't over to you Use your story Something that should have been finished already and hasn't been finished. Right? So that is one of the beauties off Microsoft Planner. You know, you can use all of these and you can see here this little icon number one. It means thes user story has one attachment. And if you're wondering, why would someone want to ask trying and you date or an attachment to a user story? Well, because it used her story could have a particular day willingness to be finished, and it could. And the attachment could just be supporting material or supporting documentation. All right, so I'm gonna delete these example. Use their story that I just created for you right now, But like I said, here, you can assign it to someone else. You can copy it, or you can delete it. I'm gonna delete it because this was just a quick example just to show you how how to create a user story here in Microsoft Planner. And if you're feeling that I'm going too fast over it. Don't worry. You can rewind. Of course, because this is a video. You can pause it. You can replay the video. I like you. So before, I'm just going to let this one just delete it. But like you, So before you just click here on the plus button and then you create your user story on Like I said before, I recommend that you start with a verb, right? So, for example, create Beeld. Develop right. The sign. Right? Check. Basically a verb, right. Something that implies action. That's something that I recommend to people when they're riding the reser stories. Now, because we're not following that foreman also, as I need to So that block, which is a very long four months for writing and user story What I also recommend to people when they're writing the reserve stories in practice, in real life, like you're seeing here, is a Like I said before, don't use the official traditional agile template because he used as I need to solve that block, it becomes quite long and it also becomes repetitive and redundant. So start with a verb on the other thing. I always say to people is right your user stories in a short, concise, relevant Wait, you know, don't right them. Don't tell a novel in the user story. Just keep it to a one liner that anybody that recent use their story can understand what he's about. Like update Exceptional Forum Update. These and I like this unless this percent this enabled enabled these analysis. So anyone that rich this at last can quickly tell what it's about Now, if you wanted to have more information on that, you can. You can just click here and you can add a description. Here are very long text if you wanted to, or a long text here in the comment comments section. But, like I said before to keep your adult Kevin Ward beautiful, like you're seeing these on screen, which is super, you know, it just looks really good. It's easy to understand. It is easy to work with. It works at a glance. That's the whole purpose of an agile Cambon board. That's how it's meant to be. It should be short. It should be relevant. It should become size. It should be easy to understand, right, because basically what an actual camp in board allows us to do is to check what is the status of the project at any point in time during any particular spring, Right on bases, how we're managing in our case on these examples, as you're that you're seeing here right now. Now there's something I really like. Also about Microsoft plan is that you can see here that is showing that we've completed 100 23 use or stories, right, and you can scroll and you can see all of them that have been completed. And it just keeps all the traceability off everything that you've done right. Microsoft Microsoft Planner also has other functionality such as charts. If I go here to charts, he's gonna show me what's not started. What in progress would slate what's completed? And I can see here some graphs as well, and I can see here the number off this is showing me basically that I have two tests that I haven't started to use her stories and it shows that by, um, team member, right, So you can see here different colors in progress late. So I thes guy has won one task over Do you use your story over due to two in progress and so forth. These are just some of those graphs that automatically come from Microsoft Planner, and it has a lot of other options here that you can see. And I'm not gonna go into them in detail because this was basically Maura about the agile can been bored. Now the charts here, as you saw before these are like Michael's of planner standard charts. So they're not a burned down chart or a velocity chart or any other type of chart he could use in agile, such as a burn up chart as well. But I have included some of those templates for you in the course, which you can easily download, And they're just excel, you know, templates that you type in, and they automatically calculate, or, if you want it to have, like an automatic diagram, you know, now automatic burned down charge, velocity, etcetera. Probably the most robust tool for that will be jezeera from inflation. That's probably the one that has all of those graphs automatically incorporated into them. For things like planner or travel, you kind of have to manually do them or you you have to have Adam's or pay extra functionality to get that added onto them. So it doesn't come by that by the fault, like it does injera. So that's an advantage of Ghira. But gee, Rolls was a tool is a little bit more complex to manage is a little bit more complicated and more complex to understand as well. So if you want to go really simple, really minimalistic, I definitely recommend that you used either trail Oh, or Microsoft planner, if you're use it. If you're working at a company that has access to office 365 right on Microsoft Planner is one of those APS that it's part of office 365 So, alright, guys, as you can see here, this is a really simple example. Off an agile can been bored here in Microsoft Planner on. We talked about user stories, story points that columns that are part of the campaign board, how you contract completion, how you can create a new user Stories here and Microsoft planner. How can you assign or reassigned? Use their stories if you need to how you can move them across as you're more as there. You're making progress, the different faces of the project, and that's basically eat right. And as you already know, they don't have to be for everyone exactly what I'm showing here, in the sense that you don't all have to be using wiki sprints like I've worked in parts where we have fortnightly springs. I have worked in other places where we had springs the last three weeks, and I worked in practical that last up to four weeks, which is probably the longest you wanna have in terms of your sprint duration. In this case, we're doing weekly sprints, which is not something you can perceived here so much in the camp on board, but doesn't really matter because the people working on the product team we know which are the user stories we're working on each week because that's what's reflected here in the agile Cambon board. What you see here is what we're planning or with planned for a particular spring. After we complete everything, we move them to the done, and if we haven't completed everything, then it moves across the following sprint, which is something that I get asked about all the time. Do we move user stories across to the next print. Four. Do we put them back in the product backlog, or what do we do with them? And we didn't complete them. So basically, yeah, you could put here another column. We don't have it here on these this camera board example that I have your seen on screen, but you could put another column for your product back Look, And then if you didn't complete something, you could move it back to the product backlog, and then you can reassign it for the next print. Or you can think and just simply move everything across. It's really up to each agile team, and each agile team is different, and the context off each agile team is a bit different as well. So some teams just move everything across ours, reassess If you ask me what you should do. I basically think you should look at it on a case by case basis. So after you finish each sprint as you're doing your spring planning for the next spring, you want to look at what story user sores you didn't complete in your previous sprint on if they're still relevant, and if you're stealing to complete them in the short term will move into the next spring. If you don't if they're no longer rebel relevantly, something's changed. Put him in the product back. Look, As you already know, agile is not rigidities flexible on. We're open to change all the time and things change rapidly. An agile. Which is why following our Rachel, such as the daily stand ups and retrospectives, the you know, spring planning sessions, the demo sessions and so forth is so important because a bit like culture. Alright, guys. So anyway, I just wanted to show you this example off our agile Cambon board here in Microsoft Planner because it's something that I know people are really interested in seeing all the time you know, real world examples and how using a wish tools I'm using. And as you've heard me talk about before, I'm not particularly married to any one single tool. I'm constantly playing around with different tools, and I think that beyond which tool you use, it's more around the process, that culture that everyone feels comfortable with what they're using in our case in this particular business and in this particular project, everyone on the product team has access to Microsoft Planner. They all know how it works is super easy to use, so we all use it in this area. So what we have, And like I said before hearing the done, you can hide it if you want to hide it or you can expand it. Microsoft Planner is pretty intuitive. You'll get the hang of it really quickly and really easily on, Um, anyway, I hope you found these part of the course and this lecture on a riel world example of idle Cambon board using Microsoft Planner really valuable and really helpful. And I know there's something that people want me to do all the time. They want me to walk them through reward world examples using a particular tool and how I use it, and I'm sure you'll get a lower value from it. And if you have any questions, we'll reach out. No worries. Happy to answer and happy to help where I can write guys. Cheers. See in the next one might 14. Jira | Introduction: Hey, guys. So in these Jiro cores, we're gonna cover everything you need to know about JI era and how you can use these great tool for managing your projects, especially your agile projects. All right, so without further ado, let's just go to google dot com. And then let's just search for Ghira. That's J I R A. All right, Jezeera. Here you go. So Ajira issue and predict tracking software from inflation, right or flash? So let's click here. Multiple take us directly to Ajira on Dhere. It is. Here is a main website, the main page for Jiro. And as you can see here, they claim that they are the number one. So for development tool used by agile teams. And I think that is pretty much true if you looked at all the different tools that are out there for managing annual projects. Gee, Iraqis, by far the most popular and widely used agile project management tool out there, all right. And in this website, you can see here a little bit of information about Vera. You know, see how we're remaining Jerusalem for plowed reimagining, juris awkward, plowed on. And the best software teams ship early and often, and you can see here a little bit about, you know, dearest, agile camera on board. They just call it board here gives you a little bit of a snapshot of the product. You can plant track release report as well, so we scroll down. You can see a bit more information about Jiro on, and he'll know this natural. Here seem variation releases when we're talking about software project management. Obviously, you don't have to use gear, adjust for suffer or for I t project management. You could use it for any other industry, but it is very commonly used in I T. Which is why you'll see a lot of the terminology and a little things in Jiro referencing I t on technology jargon, I guess. And then, if you go here workflow. So there's one of the cool things of our gear eyes that they have, like the full work flows. And then you can also customize those work flows will get into that a little bit later in the course and knowledge management, you know you can integrate Jiro with different things. Confluences also opened a probe product from inflation. Um, Big Bucket there's a little are things that they have on you can integrate here with. Many of them, like Electra Low, are like planner or like a lot of other things that are out there. And here's a bit more examples of things that you can integrate with. You know, sales horrors are things you know you can see here. There's a bunch of our things. And just so you know, year olds who has kind of its own marketplace a little bit like the app store in Apple or, you know, the Google Play Story and Android, where you have a bunch of ads in advance, you can add onto your smartphone. Jiro has the same thing. They have a bunch of are things you can add on so you can have extra functionality or extra things. Add it on to gear up. Some of them are free, but most of them are paid, of course, because that's how that's how developers and companies make money out of gyros. Well, and they're not, by the way, created by a flash in a lot of them are, you know, from different companies. Their party companies were even developers. And yeah, you know, trusted by over 65,000 customers worldwide, we all recognize, of course, all of these companies are using Jeras Square Base fortified Cisco Airbnb, and they have simple plans hosted in the cloud on and a lot of people don't know. But they actually do have a free version, which is for up to 10 users. Free forever, an obligation. And then they have, you know, another other versions, which, of course, have a bit more events functionality. And we'll see that in a in a moment, go agile with ease. Flexible planning, accurate estimations valued even per organization. Transferring execution, actionable results, scalable solution. So Ajira, like I said, is definitely a great tool. I definitely recommend anyone that he's running idle projects to use Jiro, one of my favorite ones. Estrella, you've heard me talk about trailer before as well, which is in our in our tool to manage agile projects. But about Ghira, it's also great. It is widely used. It is by far the most popular application used for managing your idea projects. And in these scores, I'm gonna show you re a world examples about how using your it to run. So my agile projects, and that will give you a taste for what you can do with Gironde what it actually looks like . But I'm also gonna show you from scratch what you can do with Ghira like like, if you were just starting how to do it. Let's just start by going to the features as well off the era. So features for suffered development scrum boards or Cambon Boerse's will, or what we call agile Campbell boards. So to dio doing were in progress and done as you can see these example of one of them right there injera, rope mapping as well, which is in our really cool things Or Jiro does allow for you to have road maps and agile reporting, connect issues to code slurs, a bunch of different functionalities and features that Jiro has. And there's a lot are things you can do with it, which will cover in the course. But mainly G Race used to manage Idol projects or mainly used by project management teams. But it's also used by product management teams as well, and they have your brought guy enterprise pricing. Just quickly look at the pro guy, So how do you steer a software to help into little guides a brief or view of direct weeks. Our guy, that's practices. So I definitely recommend that if you're just that brand new user, first time newbie using gerund you've never used to before, have a look at this guided tours and guided articles and to your on inflation provide. There's one of the really cool things about a clash in or inflation. Sorry. If you hear me interchange with the name of the company doesn't really matter. Some people pronounce it that let a flesh in others like, you know, like myself. Something's pronounced inflation. But anyway, beyond that, the point here is Jezeera, which is a practice one of their many products Flash and does have a little our products. But Jerry is the most popular for other products, and it's pretty much a product that they're known for. And you can see here a bunch of fake use, you know, they have ah document. You know, the commendation. Like a knowledge base. They have Ajira community, and they have, you know, a place where they post everything that's coming up. New enterprise. Of course, if you're in a big corporation, you want to use jeer? Uh, you can also do that. And then they give you You know how you scale, how you do things. You know, the big corporate level as well, which is why they have desire, you know, information for you available here on pricing. It's pretty stable, by the way. The pricing that can say I've seen it changed much over the years. It is pretty table generally on, you know, hear it. They give you a bit off comparison between the different versions off era. I think you know, if you have less than 10 people on your projects, starting with the free version is good, because it will just give you more than what you need. And then, of course, if you need to upgrade, you can always have greater at any point in time to one of the other plans. It's not super expensive. You know what, seven bucks per user per month or 14 bucks per user per month on the premium version, but also, of course, this depends. If you have a very big team, then, of course, that can become quite expensive. When you get this. You know this prising but generally most companies provided to their employees. So you're working for a company that is just using Jiro you most of time. You won't have to pay for it yourself, but they do have a free option. Like they said, it's living it to up to 10 users. So if you're in a small team, used a free option. If your company's paying for Jiro, well, you don't even have to think about. Pricing is probably busy. Little Bee is probably not very relevant for you, but I just wanted to show you in, in any case, even if your company's paying for it. Just so you know how much your company Spain for Ajira on. Obviously, this will depend also on boarding. When are things, But that's that's pretty much. And they have here off course, a bunch off pricing if it use for you. And yet they also have off Self Man National they over a cloud based version. But there's those, of course, a self managed version, which means you would actually hosted yourself on day have here. You know, of course, different different payment options, depending on the volume as well. But let's go back to the cloud version. If you ask me in terms of what I would prefer or what I would recommend it in cloud and self managed, I would always go. Cloud Cloud is the future that is, with where almost everything is. You don't have to worry about hosting things yourself. You don't have to worry about pushing upgrades yourself to the suffer, either. When you're using the cloud version, it automatically pushes everything for you. So if you know, if you were asking me between whether to choose a cloud or self hosted, I would definitely go plowed. The only in scenario I will recommend self manages when you you know there's some companies that have very restricted and constrained about putting things in the cloud because of privacy concerns, or they might be in a country that has issues with things being the cloud or whatever. If that's the case, then yet you have the self managed option and then I would recommend it, but nor normally and typically I would definitely go for the cloud option. All right, so that's basically a very quick intro to what you find on the Gee Rob website on a very high level overview off era, and we'll get into that in a moment in more details. Like I said, if you go to the pricing tab, there is a free option, which is what I'm gonna use initially in this part of the course just to show you how to get started, etcetera. But there's also I'll show you later on a paid version way, even with some extra Adams that we pay for in the company that I work for and how we're using here are in, you know, in the real world, any real products, right? So if you were going to sign up for the free version, will you go to surprising page free? Get started? You don't take it, too is very basic. Sign a page. Like I said, cloud free from to 10 users to go. I don't stretch etcetera. It gives you the option to sign up with Google or with email. So I generally I prefer summing up with email. That's just me, but give you prefer exciting with Google. That's fine. So there's gonna go here, no break are required. Like I said, this is the free option. C. Enter your email address your past. You create a password you know you possible for gear up? First name, last name, agree and sign up. That's it. Pretty easy. Pretty simple. So I just do that. If you're signing up for Jiro for the first time.