Agileteka - Master the Agile Scrum framework! | Asterios Stamatis | Skillshare

Playback Speed


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

Agileteka - Master the Agile Scrum framework!

teacher avatar Asterios Stamatis, Software Proj. Manager | PMP, SAFe, PSM

Watch this class and thousands more

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

Watch this class and thousands more

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

Lessons in This Class

47 Lessons (1h 35m)
    • 1. Chapter 1: Trailer

      2:00
    • 2. Chapter 1: What is Agile Scrum

      1:19
    • 3. Chapter 2: Roles within Agile Scrum

      0:52
    • 4. Chapter 2: Product Owner

      1:12
    • 5. Chapter 2: Development Team

      3:47
    • 6. Chapter 2: Scrum Master

      6:10
    • 7. Chapter 2: Agile Scrum Roles Outro

      1:03
    • 8. Chapter 3: Introdfuction to Artifacts

      0:45
    • 9. Chapter 3: What are the artifacts

      0:54
    • 10. Chapter 3: Product Backlog

      3:50
    • 11. Chapter 3: Sprint Backlog

      6:20
    • 12. Chapter 3: Product Increment

      2:08
    • 13. Chapter 3: Artifacts Outro

      0:24
    • 14. Chapter 4: Introduction to the Meetings

      1:16
    • 15. Chapter 4: Sprint Planning

      6:13
    • 16. Chapter 4: Sprint Planning - How to take advantage of it

      5:24
    • 17. Chapter 4: Sprint Planning - Things to avoid

      2:41
    • 18. Chapter 4: Daily Stand Up

      1:33
    • 19. Chapter 4: Daily Stand Up - How to take advantage of it

      1:58
    • 20. Chapter 4: Daily Stand Up - Things to avoid

      1:03
    • 21. Chapter 4: Product Backlog Refinement

      2:58
    • 22. Chapter 4: Product Backlog Refinement - Take advantage of it

      1:56
    • 23. Chapter 4: Product Backlog Refinement - Things to avoid

      1:32
    • 24. Chapter 4: Sprint Review

      2:34
    • 25. Chapter 4: Sprint Review - How to take advantage of it

      2:35
    • 26. Chapter 4: Sprint Review - Things to avoid

      1:16
    • 27. Chapter 4: Sprint Retrospective

      4:42
    • 28. Chapter 4: Sprint Retrospective - How to take advantage of it

      3:03
    • 29. Chapter 4: Sprint Retrospective - Things to avoid

      3:27
    • 30. Chapter 4: Agile Scrum Meetings Outro

      0:42
    • 31. Chapter 5: Values and Philosophy Introduction

      1:21
    • 32. Chapter 5: Philosophy of Agile Scrum

      1:17
    • 33. Chapter 5: Philosophy Pillar 1 - Transparency

      0:54
    • 34. Chapter 5: Philosophy Pillar 2 - Inspection

      0:38
    • 35. Chapter 5: Philosophy Pillar 3 - Adaptation

      0:46
    • 36. Chapter 5: Values in Agile Scrum

      0:14
    • 37. Chapter 5: Value 1 - Commitment

      0:29
    • 38. Chapter 5: Value 2 - Courage

      0:47
    • 39. Chapter 5: Value 3 - Focus

      0:45
    • 40. Chapter 5: Value 4 - Openness

      1:02
    • 41. Chapter 5: Value 5 - Respect

      0:45
    • 42. Chapter 5: Agile Scrum Values and Philosophy Outro

      1:00
    • 43. Chapter 6: Sprint Workflow Introduction

      0:59
    • 44. Chapter 6: Sprint workflow

      5:47
    • 45. Chapter 6: Sprint Workflow Outro

      0:54
    • 46. Chapter 7: Course conclusion

      1:28
    • 47. Chapter 7: Bonus lecture

      0:34
  • --
  • 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.

53

Students

--

Projects

About This Class

What will you learn?

  • Everything you need in order to start working within the Agile Scrum Framework tomorrow!

  • Agile Scrum definition and why it can be used in almost every Job Sector (not only in Computer Engineering ¬†/ IT).

  • All about the Agile Scrum Roles. For each Role:

    • Its position within the Agile Scrum Organigram

    • Technical info regarding the Role

    • What are the rights & the responsibilities of the Role.

  • All about the Agile Scrum Artifacts.¬† For each Artifact:

    • The concept behind it

    • An in-detail analysis of the Artifact

    • Practical example using high quality graphical representation

    • Which Role is the owner of the Artifact.

  • All about the Agile Scrum Meetings. For each Meeting:¬†

    • The scope of the Meeting

    • What happens during the Meeting in detail

    • How to take maximum advantage of the Meeting (a separate analysis is done for each of the Roles)

    • What pitfalls you should avoid during the meeting (a separate analysis is done for each of the Roles).

  • Essential theory about the Values and the Philosophy of Scrum.¬†You will grasp the Agile Mindset!

  • Agile Sprint Walkthrough:

    • You will know how a typical Sprint of Agile Scrum looks like, starting from Day 1, until it finishes.

    • All the Meetings and necessary activities are put in place and in the correct order.

    • You will learn what you are supposed to be working on every single day of the Sprint, no matter who is your Role.

  • You will be 100% prepared for it!

What's included in the class:

  • Smart Quizzes in order to test your knowledge and focus on the important points!

  • Sprint Planning Excercise. You will be able to successfully plan a Sprint by taking into account all the necessary factors - real life scenario!

  • High-quality Videos (visual &¬†audio) so that you can watch the class from any device with great comfort.

  • Hand crafted graphics & organigrams that will help you understand the Agile Scrum Roles, Meetings, Artifacts etc

  • Lifetime access - No expiration.

  • Q&A¬†support from the instructor on your questions.

  • Free class updates - The material is constantly updated and you will receive all the actualisations.

Why you should watch this class

  • You will learn how to act within the Agile Scrum Framework, no matter who is your Role!

    • How to interract with the rest of the Roles

    • What to do during each Meeting

    • How to use the Artifacts

  • You will get a very accurate picture of the daily work within the Agile Scrum Framework.

  • The class is not focused on boring theory, but I¬†provide you with as much practical information possible, so that you can start working within the Agile Scrum Framework tomorrow!

  • Get taught by a successful profesional with several years of experience in managing teams &¬†projects.

  • I¬†have worked with various development methodologies &¬†frameworks. As a result, I know the strong &¬†weak points of each methodology, and what you should be careful about.

  • I¬†apply all the information taught in this¬†class¬†successfully and on a daily basis.

This class is ideal for:

  • People with zero up to intermediate knowledge regarding Agile Scrum. This is why in this class I explain even the smallest details from scratch - no IT¬†or Agile prior knowledge is needed in order for you to take on this class!

  • People who will start working for a company / team /¬†organisation that makes use of the Agile Scrum framework. This is why I¬†walk you through each Agile meeting as well as a typical Sprint, so that you will be ready to use Agile Scrum even from Day 1 on your new job!

  • People who will give a job interview or will face questions regarding Agile Scrum. This is why you will be provided with many practical examples and you will get to know everything about the Agile Scrum Roles, Artifacts and Meetings step-by-step. As a¬† result, you will have a clear &¬†solid understanding of every Agile Scrum concept!

  • Managers and directors who want to establish the Agile Scrum Framework in their companies /¬†organisations / business units.

  • People that just want to know what Agile Scrum is all about!

This class is NOT for:

  • People that want just to pass an Agile Scrum Exam /¬†get a certification. Even though, in this class you learn almost everything that you need in order to pass an Agile Scrum exam, this is not the main focus of the class. I¬†do not try to cover all the possible theoretic questions that you might face during an Agile Scrum exam. On the other hand, I¬†give you practical information that will clarify all the concepts and your doubts, and that will prepare you for your daily work with Agile Scrum.

  • People who are not willing to study. Everything is provided to you within the class, however, you need to put in the effort and the hours in order to absorb the material.

  • People who just want to focus on the theory of Agile Scrum. Even though I cover most of the Agile Scrum theory, my main focus is on providing you practical information and examples, that will¬† make your daily work with Agile Scrum a lot easier.

PRICING POLICY

  • 5% of the monthly income will be donated to NGOs, starting from Nov 2021.

Meet Your Teacher

Teacher Profile Image

Asterios Stamatis

Software Proj. Manager | PMP, SAFe, PSM

Teacher

In a few words

Engineer at heart,  with keen interest in Management methodologies, Leadership styles, Human Psychology, Empathy, Communication.

 

The Job

- Project Manager within the Agile Scrum Framework.

- ex Scrum Master within the Scaled Agile Framework.

- ex Software Leader within the Waterfall approach.

- ex Embedded Software Engineer.

 

Education

- MSc in Computer Science (Mobile & Ubiquitous Computing) - Trinity College, Dublin, Ireland

- Computer Engineering & Informatics Bachelor's Degree - University of Patras, Greece

 

Certifications

- Project Management Professional - PMP

- Certified SAFe® 5 Agilist

- Professional Scrum Master 1 - PSM I

... 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.

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.

Transcripts

1. Chapter 1: Trailer: Hello, welcome to Agileteka, the course that will teach you everything you need to know, to rock in the world of Agile Scrum. This course is aimed at people who want to work within an Agile Scrum environment, at people who want to prepare themselves for a job interview regarding this topic and at the people who just want to know what Agile Scrum is all about. By the end of the course, you will be able to not only start working within an Agile Scrum environment, but to take full advantage of the framework's, tools for your own gain and you will be able to identify the pitfalls you shall be avoiding. The course is based the Scrum Guide, which is the golden rule book for everything related to Agile Scrum. However, I am expanding on it with technical details, practical examples, and topics that will prepare you for the real world. I will guide you through various chapters about the Agile Scrum roles, the Scrum artifacts and the Scrum meetings, followed by the Values and Philosophy of Agile Scrum. Finally, in the last chapter, I gather all the information together and present you a typical sprint from start to finish with all the meetings and the flow of information in the correct order, so that you know what to expect! If you are a university student or a professional and you want to work within the Agile Scrum framework, or if you are a manager and you want to know what Agile Scrum is all about, then this course is for you! Agileteka is open to people from all professional backgrounds and there are no prerequisites for enrolling in the course. I am Asterios and I'm looking forward to sharing my knowledge with you and to helping you achieve your goals. Enjoy the course, and welcome aboard! 2. Chapter 1: What is Agile Scrum: So let me ask you a couple of questions first: What is Agile Scrum in the end? The answer here is very simple. I Agile Scrum is just a framework. Okay, great. And what does this framework consists of? Well, this framework consists of a number of people that have specific roles. They're using a predefined set of tools known as artifacts, and they're going through a prescheduled set of very specific meetings. Okay, great. And what is the purpose of the framework? Well, the ultimate purpose of the framework is to help us plan, execute, monitor, control, and close the work that we have to do. Okay, cool. So last question: Where can this framework be applied? The answer here is very simple as well. It can be applied everywhere. It is true that it's mostly popular within the IT and engineering industry. However, it can be applied to the public sector, to a bank, to a hospital, to a school. Because in the end, it just helps us do our job in a more efficient way. 3. Chapter 2: Roles within Agile Scrum: Hello. In this section, we are going to talk about the different roles that people might have within the Agile Scrum framework. And those roles are three: The Product Owner, the Development Team, and the Scrum Master. Each of those roles will have a separate video. In the beginning of its video, we will express in a few sentences what is the concept behind each role, and then we'll analyse in detail the characteristics of the role. Finally, in the end of each video, we are going to list in detail all the responsibilities that the role has towards the processes of the Agile Scrum framework and towards the other roles of the framework. 4. Chapter 2: Product Owner: Let's talk first about the Product Owner or else known as PO. The Product Owner, as the name suggests, is the main responsible for decisions related to the product / projects that we're working on. The Product Owner is a management role and hierarchically he sits on top of the rest of the Team who are the technical problem solvers and feature developers. In the end, the Team members, shall see their PO as their client. And why is that? Because every single day the PO shall be in constant alignment with higher management of the product, with the client itself and with other POs, gathering all this information, filtering it out, processing it, and giving it to his own Team in form of tasks. Based on all these alignments, gathering and processing of information that the PO is constantly doing, he or she in the end is responsible for: deciding on which activities that Team is going to work on, which of those activities have the most priority and what is the deadline for finishing them. 5. Chapter 2: Development Team: Let's talk now about the Team in the Agile Scrum framework. The Team in Agile Scrum is much more respected than in traditional approaches such as the Waterfall. The power of the team is just much more recognized here. Each team in Agile Scrum is comprised of somewhere between three to nine people. Within the team, all the team members are equal and there should not be any kind of separation between them in terms of seniority, specialization, and in any case there should be no role assignments. For example, we should never say that, Asterios will be testing our software, or Asterios will be the guy who'll be writing our requirements, or Asterios will take always easier task because he is the most junior. There should not be any kind of separation within the Team members and everyone should be equal and be able to support the rest of the Team in any way. In addition, theory says that the Team, shall be cross-functional. This means that within the Agile Scrum Team that members have all the required skills in order to fully integrate a feature within the product. For example, there should not be a Team which is consisted only of developers who are developing a feature, and then in order to test it, they shall send it to another team, which is consisted only of testers. An Agile Scrum Team, shall be able to fully develop, test, and integrate a feature into the product. However, the reality is most of the times different. In Agile Scrum and within the Team, the accountability shall always go to the whole Team and never to a single person. Even if we're talking for a success or a failure, we should always say "we" and "us", and we should never say "me" or "I". A very important point is that in Agile Scrum a Team shall be self-organized. What does it mean is that in contrast to other frameworks, in Agile Scrum a Product Owner shall not assign a task to a specific member of the Team. He shall assign it to the Team, and then the Team Members shall decide between themselves who is the best candidate to undertake the task, according to their workload and their preferences. And as we said before, the Product Owner is responsible for WHAT we have to do as a Team, however, the Team is responsible for deciding HOW we're going to do it. In addition, the Product Owner might have some idea on his mind regarding when the activities that he wants to do shall finish, however, in reality, it's the Team, the ones who should confirm if this is feasible or not. Last but not least, the Team should expose to the Product Owner any hidden complexities within the activities that he plans to do, as well as any dependencies. So in order to sum up, we mentioned earlier that the Product Owner decides the activities that the team is going to perform. However, the Team is the one to decide how they're going to execute those activities. In addition, they have to mention to the Product Owner the estimation of those activities, and this estimation, of course, has to be respected. And they're responsible for providing to the Product Owner information regarding any hidden complexities and dependencies between those activities that he or she might not know. Last but not least, of course, the Team is responsible for the successful completion of the activities. 6. Chapter 2: Scrum Master: So let's move on to the role of the Scrum Master. As the name suggests, a Scrum Master is a person who knows the rules and the philosophy of Agile Scrum, and he or she is responsible for their establishment and application. It is worth mentioning that a Scrum Master is not the management role, but it is a technical role. A Scrum Master might be applying this role part-time or full-time. This depends on the size of the Team and, of course, on the Team's workload. In smaller teams of three or four people, it's most probable for one of the members to have a part-time Scrum Master role, just because there are not too many activities to keep track of. On the other hand, on bigger teams of eight or nine people that have heavy technical workload, it's most probable to see one of the Team members to have a full-time Scrum Master role. That's because there are just too many activities to keep track of and there are too many Team members that will need the Scrum Master's support. So what does the Scrum Master do? A Scrum Master helps the Team members and the organization that he works for to apply the Agile Scrum framework. He or she is just the person who knows the rules and the processes. And here is a very important clarification: The Scrum Master is just acting as the glue that joins everything together. This means that his main job is to bring together the Team members with the Product Owner and make sure that they're working very nice together and they're having a good cooperation. And of course, he shall be able to, let's say, ease out any tension that might arise from time to time. So let's break this down a bit further. A Scrum Master is not a decision-maker. Let's make it very clear. As we said earlier, the Product Owner decides the activities that the Team is going to do, and the Team decides the activity's duration and their feasibility. However, the Scrum Master does not decide anything, apart from how is Scrum going to be applied. A very important role and part of the nature of the Scrum Master is to help the rest of the Team members and the Product Owner, of course. In case that someone is blocked and cannot perform his or her job for whatever reason, the Scrum Master is the responsible for making sure that this problem will be solved as soon as possible. In other words, he's acting as a facilitator. The Scrum Master has to make sure that the workflow is as uninterrupted as possible. And let's go back to the glue thing. As we said earlier, the Scrum Master acts as a glue between the team and the Product Owner and makes sure they have a smooth cooperation. So it is the Scrum Master's job to protect the Team members from the Product Owner's demands if those demands are not feasible, according to the Team's technical analysis, of course. So the Scrum Master has to step up there and protect the Team members. On the other hand, and as part of these two-faced responsibility, the Scrum Master has to make sure that the Product Owner is as happy as possible from the Team's performance. This means that the Scrum Master has to make sure that any logical requests that come from part of the Product Owner are met by the Team and that the Team is as productive as possible in order to keep management happy. Another task of the Scrum Master is to be the right hand of the Product Owner. This means that the Scrum Master and the Product Owner will have to be working very closely together. The Scrum Master shall be able to help the Product Owner with various tasks such as refining the tasks that are in the Backlog. And we will explain later what is the Backlog. The Scrum Master shall be able to monitor and provide feedback to the Product Owner regarding the activities that the Team is currently executing. The Scrum Master shall be able to remind the Product Owner of things that he or she has to do: Emails that need to be sent, discussions that need to be done, and so on. So, as we said earlier, the Scrum Master is not a decision-maker. However, as you can see, the role of the Scrum Master within the Team is very, very important and it's quite complex sometimes. Even if, as we said earlier, a Scrum Master is a role that belongs to a technical position and not to a management position, in order for someone to be a successful Scrum Master, he or she shall have for sure leadership and management skills. Being a Scrum Master is a first step to a management carrier path. You can read a lot of things around the web regarding the different leadership styles. The Scrum Master shall fulfill the Servant Leadership style. And what do I mean by that: It should be the Scrum Master's nature to serve the others, his or her teammates, the Product Owner, and the organization as well. The Scrum Master shall be the first one who uses the word "we" and "us" instead of "I" and "me". So, in order to sum up: The Scrum Master's responsibilities are the establishment and correct application of the Agile Scrum framework within that Team and the company. To unblock the teammates and the Product Owner every time something inhibits their work. To protect the Team from excessive and not feasible demands from the side of the Product Owner. And last but not least, to be the right hand of the Product Owner and help him or her as much as possible with his or her tasks. 7. Chapter 2: Agile Scrum Roles Outro: Congratulations, you have finished this section! Now, you should have a very good first idea about each of the roles within the Agile Scrum framework. And as you have already noticed, each of those roles serves a specific purpose and sees things from its own point of view. Before moving to the next section, please make sure that you have understood the concept behind each of those roles and most importantly, the responsibilities that each one of them has. However, I can already tell you that in the following sections, we are going to see in more detail how each one of those guys or girls are using the Agile Scrum artifacts and what they are doing during the meetings. As a result, by the end of this course, the understanding that you have about each of those roles will be even more in-depth. 8. Chapter 3: Introdfuction to Artifacts: Hello. In this section, we're going to talk about the Artifacts within the Agile Scrum framework. Initially, I will explain to you what are the Artifacts and why they are so important for the framework. Then we'll go through each of those Artifacts separately. In each of those videos, initially, I will introduce you to the concept of the Artifact. Then we will have an in detail analysis on how to use it, followed by a practical example. Last but not least, we will discuss about who is the person in charge about each of the Artifacts. 9. Chapter 3: What are the artifacts: Now let's start talking about the Artifacts. The Artifacts in reality are tools that provide information regarding the product that we are developing, the activities that we are currently doing in order to develop the product, and the activities that are needed in the product's lifetime in order to complete the requirements regarding the product. In addition, with those tools we will be able to see the estimation for those activities and other necessary and very important information. In general, we can say that the artifacts are created in order to give maximum transparency over the product. And make sure that everyone (the Team, the Scrum Master, the Product Owner) has the same understanding over the things that need to be done in order to reach our objective. 10. Chapter 3: Product Backlog: So let's move on to the first Artifact. This is the Product Backlog. So what is the Product Backlog? The Product Backlog is the full list of tasks and activities that we have to do in order to complete the development of our product. So by taking a look in this list of tasks and reading the information that we have about each task, we should know what we have to do in order to complete the product. Ok take great! So, what information should we have in this list for every single task or activity that we have to do? So each task should have a title. Then, it should have in description - a more detailed information regarding what is this task about. It should have some acceptance criteria. By acceptance criteria, we mean what should be the status of the task in order to be considered as completed and accepted by the Product Owner. It should have an assignee, a person who is responsible for completing this task. And it should have a duration, a rough estimation: that this task might take us one day to be completed or three days or a week or whatever. Another very important information: A Product Backlog is never complete, is never finished, is never frozen. This means that the Product Backlog will be different today, it will be in status A today, and tomorrow will be in status B. Every day we receive new information about the product, and by receiving information, we have to reflect this information to the Product Backlog. So let's take an example: Our task is to construct a bicycle. And we know that this bicycle should have two wheels. So, we have a task which is called "Put two wheels on the bicycle". Then the next day we receive from the customer arequest that those wheels should be of a specific brand and should have a specific size. This means that we go to the Product Backlog, we go to the specific task that says "Put two wheels on the bicycle" and we update the specific task with the new information that we received. This means that we updated or refined the Product Backlog. So every day by receiving new information, we have to update the Product Backlog. And this is why we are saying that the Product Backlog is a living Artifact. The person who is responsible for the status, update and maintenance of the Product Backlog is the Product Owner. The Product Owner is the person that, as we said, he has to add new information to the tasks, according to what the client and management tells him. He's the person who should create new tasks, delete the obsolete ones, create dependencies between them, and keep the Product Backlog as up-to-date as possible. Of course, it would be of great benefit to the Product Owner if the Scrum Master can help him here. A good cooperation between the Scrum Master and the Product Owner is necessary for optimal performance of the Agile Scrum framework. So, many times the Scrum Master shall suggest to the Product Owner changes in the Product Backlog: to update it with specific information, remind him of things that he might forget. So the Scrum Master, has to take always a second look in the Product Backlog and give a helping hand to the Product Owner. 11. Chapter 3: Sprint Backlog: The next Artifact should be the Sprint Backlog. But before talking about the Sprint Backlog, I would like to talk to you about the Sprint. What is the sprint? In Agiel Scrum, in order to keep things more under control and more flexible and agile, we are breaking the time into time slots, into time periods. And those time periods are called Sprints. A Sprint typically lasts two weeks. However, there are Sprints of three or even four weeks, which is the maximum. By this way, a project that lasts one whole year, it will be broken into smaller, smaller timeslots of two weeks. So, in smaller mini-projects. For each of those mini-projects or else Sprints, that Team is planning what it has to do, then it's executing - and the Scrum Master and the Product Owner are monitoring the execution, if everything goes well. And then in the end of the Sprint, they're closing the activities and see the results: if everything was under control or not. So, by breaking down a project's duration into those smaller time slots, we can have better control over the activities. Imagine the case that something went wrong during a Sprint. Then by the end of it - this means after two weeks, we will see what went wrong, we will analyse it, we will do corrective actions, and then, in the next Sprint we will be more prepared and get back on track. So, we will not have to wait until the end of the project, in order to see things that are going wrong. So now, you know what is a Sprint and what is its purpose. So, let's talk now about the Sprint Backlog. As we said earlier, the purpose of the Sprint is to break down a project into smaller mini-projects called Sprints. And as the whole project has its own backlog, which is called the Product Backlog, the same way, the Sprint which is a mini-project, should have its own backlog, which is called the Sprint Backlog. The Sprint Backlog is the list of tasks that the Team shall perform during the Sprint, during the mini-project. And how is the Sprint Backlog created? In the beginning of the Sprint, there is an event which is called Sprint Planning. We will talk about this event in detail later on. The general idea is that the Product Owner goes to this event and says to the Team the tasks that he would like the Team to perform during the upcoming Sprint. Ideally, those tasks are included in the Product Backlog. So the Product Owner goes into this meeting with his tasks and a goal in his mind. He communicates the goal for the upcoming Sprint and the tasks that he would like the Team to do, and if the Team agrees to the goal and they believe that they can perform those tasks within the upcoming Sprint, then they take those tasks from the Product Backlog and they create the Sprint Backlog. In addition, maybe the Team will create some additional tasks in the Sprint Backlog. In the end, the Sprint Backlog will have all the necessary tasks that the Team believes that they have to do in order to reach the goal that the Product Owner has set for the upcoming Sprint. In contrast to the Product Backlog, whose owner is the Product Owner, the owner of the Sprint Backlog is the Development Team. So, during a Sprint, only the Development Team is allowed to modify the Sprint Backlog. So, let's go through a practical example in order to make sure that we understand that Sprint Backlog. Let's suppose that the Product Owner would like the Development Team to construct the front wheel of the bicycle, mount it on the bicycle and make sure that there is a smooth experience. For this activity, on the Product Backlog, there are the following tasks: First task is to construct the aluminium structure of the wheel. Then, the second task would be over this aluminium structure to place the wheel tire. The third task would be to mount the wheel on the bicycle, and the fourth task would be to calibrate the wheel and the bicycle, in order to make sure that there is a smooth experience. The Development Team, so discuss with the Product Owner and if they believe that during the upcoming Sprint, it's doable to construct and mount the front wheel on the bicycle, then what the Development Team shall do is to take those four tasks from the Product Backlog and put them into the Sprint Backlog for the upcoming Sprint. Now, imagine the case that the Development Team, because they are experts, they have two different tire types in mind and they would like to check both those types in order to make sure that the experience for the end-user will be the best. In that case, the Development Team will create an additional task into the Sprint Backlog which will be called: "Test the two different tire types on the wheel and choose which is the best one". So the Sprint Backlog would be then the four tasks that the Development Team took from the Product Backlog, plus the extra task that they created, in order to make sure that they will make the best choice. This will be the Sprint Backlog. And the final goal, of course, is by the end of the Sprint that all the tasks are completed and that the goal is achieved. So this is what the Sprint Backlog is about. 12. Chapter 3: Product Increment: Let's go now to the last Artifact. The Product Backlog and the Sprint Backlog, are real tools that everyone is using all the time. This last Artifact is called Increment, and it's more of a theoretical one. I would explain it, just for you to know what it is. But in reality, it's more theory rather than practice. So don't worry too much about it. So what is an Increment? The Increment is the result of the work that the Development Team did during the Sprint, in addition to all the rest of the work that they have done until now. So, let me give you an example: Let's suppose that the goal for the Development Team during this Sprint was to add a front wheel on the bicycle and test it. And now let's suppose that the Development Team managed to successfully completed. So the Increment by the end of the Sprint is the front wheel on top of the bicycle, along with all the rest of the bicycle that was constructed until now. This is the Increment. The owner of the Increment is the Product Owner. So the Development Team is working towards the Increment, but in the end of the Sprint is the responsibility of the Product Owner to decide if he will accept the Increment and release it with a product or if he will reject the Increment. So imagine the case that during the Sprint, the goal of the Development Team was to add the front wheel on the bicycle and test the functionality. The Development Team managed to put the front wheel, but they did not have time to test it thoroughly as they should. So, it's quite probable that by the end of the Sprint, the Product Owner will reject the increment. 13. Chapter 3: Artifacts Outro: Congratulations! We have just finished the Artifacts of the Agile Scrum framework. Pay close attention to the Product Backlog and to the Sprint Backlog. Know those artifacts very, very well. But regarding the Increment, just keep it on your mind, on the back of your head, just for you to know what it is. 14. Chapter 4: Introduction to the Meetings: So let's talk about the meetings in Scrum. We already mentioned earlier what is a sprint? And we said that the spring is like a mini-project. So all of the meetings that we're going to talk about, they take place within a sprint. For each one of the meetings, you will see three different videos. On the first video, we will first have a very quick and in a few words description about the meeting so that you will quickly know what is this meeting about. But it will be followed by an very in detail analysis of it. Then on the second video of every single meeting, will all explain to you how shall you take the maximum advantage of the meeting, no matter which is your role within the Scrum framework. So let's say No matter if you are the product owner or scrum master or a team member, what you have to do in order to take the maximum advantage of every single meeting. Last but not least, on the third video about every meeting, we will explain to you things that you have to avoid doing during this meeting. Again, no matter which is your role within the framework. 15. Chapter 4: Sprint Planning: Hello. Let's talk now about the sprint planning meeting. As its name suggests, the goal of the sprint planning meeting is to plan the activities for the upcoming sprint. Usually it takes place in the first day of the newsprint. However, sometimes the themes, like doing it in the end of the outgoing spring, according to the Agile Scrum Guide, should last somewhere between four to eight hours. Four hours for the two-week sprint, and eight hours for the one-month Sprint. However, according to my experience, it usually lasts one hour more or less. So in a few words, in the spring planning, the objective is to come to an agreement between the product owner and the development team regarding the sprint goals that will be said afterwards. The other objective is to feel the sprint backlog with all the necessary tasks in order to complete those goals. So how does the spring planning carbon? Usually, when a sprint comes to an end, in the next sprint is approaching, the product owner creates on his mind a set of goals for the upcoming sprint. He creates the set based on all the inputs that he is receiving from higher management, from the client and from discussing with other product owners at work on the same project, then those goals normally shall be reflected with tasks that exist on the product backlog. Those tasks are put on the product backlog during the backlog refinement meetings, which we are going to discuss later on or in Salt alignment meetings between the product owner and the Scrum Master. The just add those tasks in the product backlog during the lifetime of a sprint. So by having a list of goals on his mind and equivalent tasks on the product backlog, the product owner can proceed and create a draft plan for the upcoming sprint. Usually, it would be ideal if this draft plan will be done with the help of the Scrum Master. So there will be two opinions about this. In order to have a good draft plan. The PO, the product owner and the Scrum Master shall first see that the goals that they want to achieve and in the next sprint are translated into existing tasks in the product backlog and that there is nothing missing. If there's something missing, it should be added. So in order for the draft plan to be realistic, the product owner and the Scrum Master shall take into account the velocity of the team. By velocity, we mean the amount of work that usually a team is able to produce within a sprint. So for example, if a team is able to produce usually x amount of work during a sprint, the draft plan should more or less contain a similar amount of work and not the double, for example, last but not least, in order for the draft plan to be realistic, the product owner and the Scrum Master shall take into account the days that the team members are able to work. For example, they have to take into account vacation days or any possible trainings that may occur during the next sprint. And this may limit the number of available working hours. So when the time arrives for the sprint planning meeting, the product owner goes there and he presents to the team the list of goals for the upcoming sprint and the draft plan that he has created, that he or she has created. The more elaborated is the draft plan, the less work will be needed to be done during the sprint planning meeting. Obviously, then the team cell take a look into the sprint goals and the draft plan. But the product owner and the Scrum Master have created and some of those things probably will be accepted. Some of those things may be will be rejected and some of those things may be, will be modified. In the end, there will be an agreement between the development team and the product owner for a list of specific goals and a concrete plan for the next sprint. Again, I would like to repeat that in the agile scrum framework, if all the meetings are done correctly by the team, the product owner, scrum master. And there is good communication. And the product owner and the Scrum Master have elaborated a draft plan. Then during the spring planning, everything shall be more or less clear from the beginning with a few exceptions, of course. And things can move quite fast. However, it's quite probable sometimes to have bigger or smaller modifications due to last main information that we received from the client or from a key stakeholder, scrum master salad 10 the sprint planning meeting. And make sure that the negotiations regarding the goals and the tasks to be performed are going smoothly. This means that the team shall be happy regarding the amount of work that they will have to do. And the product owner shall feel happy that he is able to achieve the goals that he wants during the upcoming sprint. When we reach an agreement about the objectives and the specific tasks, the development team takes those darks from the product backlog, it puts them into the sprint backlog. They add any additional tasks that may be needed in order to read the sprint goals. And the team in the end has to commit to achieve their greed sprint goals. Of course, it is important to state that everything shall be done under good will and spirit. And even if there are some differences, It's very important that when people leave the meeting room, a common ground will have been reached. 16. Chapter 4: Sprint Planning - How to take advantage of it: Now let's take a look on how can we take the maximum value out of the sprint planning meeting for the product owner. And you will take the maximum value out of it if you have elaborating the plant quite well before the sprint planning meeting, of course, it's ideal to have the head of the screw master here. So you can have a second opinion and receive his or her input and help as well. Apart from the Scrum Masters input, you will have the things input taken from the sprint backlog refinement meetings with we will explain later on. So in order for you, the product owner, to have a good draft plan made before going into the sprint planning meeting. You should have on your mind a list of goals that you want to achieve for the upcoming sprint, and a list of tasks that fulfill those goals. This list of tasks Sal be existing in the product backlog. Ideally. In addition, you should be aware of any inter-dependencies between those tasks, their complexity, and which of those tasks have the higher priority for being completed by the team. Please take into account any vacations or trainings that your team members might have during the next sprint. This is known as capacity, the amount of hours that the development team can dedicate during a sprint. Last but not least, one very important thing as well to take into account is the team's velocity. As we said earlier, the amount of work that the team usually can produce during a sprint, it does not make sense to plan the double amount of work that the team usually produces. So by having this draft plan well elaborated, you as the product owner will step into the sprint planning meeting. Sure about yourself, knowing all the little details, you will have probably no surprises. And you will transmit confidence to the team in order for the development team to take full advantage of the sprint planning, you as a team member will have to make sure that you really understand what the product owner is asking you to do. In case that you don't understand, please feel free to ask even at 1000 times until it's really, really clear to you. And it's really important for everyone if the development team members can give good estimations about the task duration and complexity, it really makes a difference if we know in advance that the task my more or less Last one day or if we need two weeks in order to complete it, this will change that plant significantly. In addition, in case that you notice that the rest of the team members and the product owner have forgotten about a dependency between tasks, or that they forgot to add a specific task that needs to be completed in order to reach a goal. Please don't be afraid to raise your hand and make the rest of the team and management are aware of it. They will really appreciate your efforts. So in a few words, for you as a team member, you should make sure that by the end of the sprint planning meeting, you have a very clear picture of glad you have to do during the upcoming sprint that you're comfortable with it. If not, you shall raise your hand. Okay? So in order for the scrum master to take full advantage of the sprint planning meeting. You as a scrum master shall have a good idea of the draft plan beforehand. This means that it would be better if you give a helping hand to the product owner and created together so that you can have a second opinion on it and check what is this about? If the product owner likes to do the plan by himself or herself. You can always ask kindly in order for you to have a quick look on it. In addition, you, as a scrum master during the sprint planning meeting, have to make sure two things. First of all, that the draft plan, the idea that the product owner had on his mind about the upcoming sprint gets accepted to as higher extent as possible by the development team. Unless of course, there is a special reason not to. This is going to make the product owner happy in the end. On the other side, you have to make sure as well that the annotations that the development team is making regarding dependencies that may be management did not take into account. And the estimation about the activities that the development team is giving. They have to be respected by everyone. This means that in the end, the development team has to be respected and they shall not be overbooked with tasks. Finally, on a general note, you as a scrum master, will have to make sure that everyone respect each other and that there is a goodwill and good spirit during the meeting. And that the team is above everyone. 17. Chapter 4: Sprint Planning - Things to avoid: Let's check now what things we shall avoid doing during the sprint planning meeting in case that you are the product owner, you shall avoid at all costs going to the planning meeting without a clear set of goals in your head and without having a draft plan already made, you have to make sure that the goals are clear and the tasks well explained, and that every single one of the development team members will have enough work for the upcoming sprint. However, don't overdo it and don't overload them either. In addition, you, as the product owner, will have to avoid ignoring the input that the scrum master and development team is giving you during the sprint planning, you have to take into account the development teams estimations regarding the tasks and their input regarding the task complexities and interdependencies. In the end, the development team is responsible for the technical part of the project. If you are in development team member, you have to respect the product owners wills. You as a development team, are responsible for deciding how to do the activities. However, the product owner is responsible for deciding which activities has shall be done, which of them have the higher priority. So make sure that you make yourself clear in terms of technical feasibility and complexity and estimation of their activities. However, please respect the product owner's authority. Now, if you are the scrum master, you shall make sure that there are no hard feelings within the sprint planning. You have to make sure that the product owner gives enough tasks to the development team, but does not overload them either. And you have to make sure that those tasks are really well defined and that the development team does not have question marks. Last but not least, you have to make sure that the development team is not rejecting the product owners plants and that they respect him or her as authority. You have to make sure that the product owner is happy with the performance of a development team and that he has the feeling that the development team is making everything possible in order to move towards the correct direction. 18. Chapter 4: Daily Stand Up: So let's move on to the daily standup meeting is the name suggests. During this meeting, the whole beam gathers up in order to track their progress towards completing the sprint goals. The required attendance for this meeting are the development team members and the Scrum Master can't be there. However, it's not necessarily the product owner can take part in this meeting. However, he should not interfere at any cost. So in a few words, during the daily standup meeting, each of the team members has to say, What did he do yesterday? What he's going here c is going to work on today and if there are any blocking points for this team member. So let's get into more detail. As we said earlier, the whole team cell gathering to the same place and every single member has to say the three aforementioned point. The reporting shall be done fast. One minute per person is enough. However, if it can be done faster, that would be even better. The Scrum Master and the Product Owner cell follow-up on the blocking point and make sure that they are solved as soon as possible. In addition, they have to make sure that everything is going according to what was said in the sprint planning. If not, countermeasures shall be taken immediately in order to be able to achieve the sprint goals by the end of the sprint. 19. Chapter 4: Daily Stand Up - How to take advantage of it: Let's see now how can we take maximum advantage of the daily Scrum meeting in case that you are the product owner, you shall interfering the meeting as less as possible. If no one asks you a question, then it's better to not say anything. Your goal here is to make sure that everything that was said during the sprint planning is being followed and everything is progressing according to the initial estimation. Last but not least, if there are any blocking points that you as a product owner consult, please do it as soon as possible. If you are the scrum master, the same things apply to you to the product owner tried to make your presence as less noticed as possible. In addition, the main responsibility for a blocking the development team members falls on you. So make sure that you cannot as fast as possible. Last but not least, as a scrum master, you are responsible for following the Scrum rules. So make sure that the daily standup meeting is time-boxed and it does not get too much prolonged. The goal here would be to give a very quick report rather than overextending the meeting with analysis over analysis over analysis. If on the other hand, you are part of the development team, then you have to know that you should keep your report as short and punchy as possible. Keep it straight to the point and try not to over extend it. You have to report what you did yesterday and what you are working on today. But the main point here is to report if there are any deviations from what was originally planned and you had undertaken. Last but not least, if you are blocked, then reported to the scrum master as soon as possible. 20. Chapter 4: Daily Stand Up - Things to avoid: So now let's move on to the things that we shall avoid doing during the daily standup meeting. In case that you are a product owner, please avoid making your presence really noticed. As we said earlier, if you're not ask something, then it's better not to say anything. In addition, please always keep in mind that this is just a quick reporting meeting. So try to avoid having long technical conversations during the guys around. Exactly the same applies to the Scrum Master. In addition, you as a Scrum Master, have to make sure that the rules are really followed and that this meeting does not get too long. Last but not least, regarding the team members, avoid forgetting the important things if you're blocked on something or if something is deviating from the original plan, you really have to say those things first. 21. Chapter 4: Product Backlog Refinement: Let's discuss now about the product backlog refinement meeting. As the name suggests, in this meeting, the product owner, the scrum master and development team, they all gathered together in order to refine, slash, groom the product backlog. Caution here, we're not talking about the sprint backlog, which is the backlog of the tasks that we have for the actual spring. We're talking about the product backlog, which includes all of the tasks that we have to complete in order to reach to a final product in the end of the project, the product backlog refinement meeting happen as much as possible because the product backlog changes all the time. We always get information about the product and the tasks that are in the product backlog should include this information. However, it would be nice to do it twice per sprint. This means once every week. So in a few words, what are the goals of the product backlog refinement, meeting? The goals of this meeting are first, to refine the existing tasks of the product backlog. This means that we have to change information such as the tasks, title, description, assignee, duration, priority, dependencies, the sprint that we are planning to execute this task. And more things. Of course, in case that any of this information has changed. Another objective is to create new tasks. So maybe we have received an email that says that the client wants something additional that initially was not planned. So we have to add a new task for that in the product backlog. On the contrary, maybe we will have to delete some of the tasks in the product backlog because now they are obsolete and we don't have to do them anymore. The overall objective, let's say, is in the end, to have the product backlog is up to date as possible. According to the current information our disposal. Let's get into more detail about this meeting. How does this meeting happen? So usually the product owner shows the product backlog to the development team and the Scrum Master and go through the list of tasks one by one during this process, if the product owner, the scrum master, or any of the team members have new information about the task currently in review. They mentioned it and the task is updated when they will have gone through all the list of tasks and they have added all the tasks that they shouldn't that to the product backlog, Then the meeting is over. 22. Chapter 4: Product Backlog Refinement - Take advantage of it: So let's talk now how to take advantage of the product backlog refinement meeting. In case that you are the product owner, you have to make sure that when you stepped into the meeting, you are well-prepared, that you have read all your emails, you have all the latest news and you can bring to the team and to the meeting all their latest information regarding each of the tasks, then you should try to extract from the development team as much technical information as possible regarding dependencies and regarding the task duration. And if the team believes that something within the task has changed and it needs to be reflected to the product backlog, it is better that the team handles the tasks, assignments between themselves. If you are part of the development team, you have to respect the product owner's decisions regarding tasks, priorities. On the other hand, you should feel incurrent and comfortable to give your opinion regarding that task's duration, any possible dependencies between tasks and you're feeling about the feasibility of a task. In short, you should never be afraid to say your opinion, even if your opinion is not a positive one about the feasibility of a task, for example, you're really welcome to say it. I'm sure that management will appreciate it because management needs your vision and opinion on the technical side of things. Last but not least, if you are the scrum master, you don't have too much things to do in this meeting. Make sure that the development team's opinions are reflected on the backlog, as well as the priority is set by the product owner, are respected as well. 23. Chapter 4: Product Backlog Refinement - Things to avoid: Now let's talk about the things that we shall avoid doing during the product backlog refinement meeting in case that you are the product owner, you have to avoid going to the meeting unprepared. You have to make sure that you have the latest news about the tasks, at least to the extent that it is possible and that you have to make sure weeds task is the highest priority for the client and for higher management. In addition, you should avoid at all costs, not accepting the development team's opinion regarding the complexity of an issue, the dependencies that it might have, as well as time estimation that they assigned to it. If you are part of the development team, you should of course, express your opinion about the complexity, the estimation, and the dependencies of its task. However, you should give some space. Always do the product owner so that he can make up his or her mind in the end. In addition, you should, at all costs, avoid disrespecting the opinion of the product owner regarding the priority set for the task severe, the Scrum Master, you shall avoid the situation where someone in the meeting is left with doubt. Everyone soon leave the meeting room. Having a clear scope of every single task and what is required in order to complete it. 24. Chapter 4: Sprint Review: Hello. Let's talk now about my next meeting, which is the sprint review. This meeting happens once indian of the spring. And as the name suggests, the goal of this meeting is to review the job that we did during the spring. The ideal theory says that this meeting should normally last for hours. However, in real life, and according to my personal experience, it lasts 30 to 60 minutes. All the members of the framework can participate in this meeting. This means the product owner, the scrum master and development team, as well as any stakeholders. This means any kind of higher management can be present in this meeting. So let's talk about the goal of this meeting briefly. In a few words, the goal of the sprint review meeting is to go through the tasks and the goals that we have said in the beginning of the sprint. And see what we managed to do out of all those things. So we will see what was done, what was not done, and of the things that are still in progress, which is the current status. If we have a lot to do still or if they're almost finished. In addition, during the sprint review, or we can do a demo of the product, of the current status of our product, and we can get immediate feedback from the stakeholders from higher management. So let's talk a little bit more in detail about the execution of this meeting. First of all, the whole team with a product owner and scrum master and development team. They go through the goals that we have said in the beginning of the sprint. And we just check if we did them or not. Then we move on to task level. So we take all the tasks that were put in the sprint backlog. We see that tasks that we managed to do and the tasks that we're not done. And we have to reflect on why those tasks were not done in the end. So the result of this conversation is to do non-typical backlog refinement once more because we're talking about the task that they were not done, what is remaining there? And then the product owner and the Scrum Master take notes and make decisions on how to handle the remaining open tasks. 25. Chapter 4: Sprint Review - How to take advantage of it: Now, let's move on and discuss on how we can take advantage of the sprint review meeting in case that you are the product owner. The first thing that you will have to do will be to congratulate the development team about their efforts. Even if you really believed deep inside you that some things could be done a little bit better, as mentioned earlier, always tried to be patronizing. Being too judgmental will not help anyone because in the end, everyone is trying his or her best. Always have this on your mind. Prepare yourself before the meeting. So when you will be going through the spring goals that were not achieved with the rest of the participants. Try to have your own reflection and opinion about what went wrong there. And based on that reflection, try to propose alternative solutions. This is the best and most positive thing that you can do. If you are a member of the development team, have an opinion on why you believe that the specific goal was achieved by you or not, in case that the goal was not achieved, have a really good justification on what happened there, what went wrong. Because in the end, it's a goal that you committed to do. And you did not manage to always have in your mind that even if the cause for not achieving a goal is yourself, there is nothing wrong with taking responsibility for the failure. On the contrary, it is really brave. Of course, only in case that reason is you last, but for sure, not least, be able to celebrate and emphasize on big achievements that the team has done in case that you are the scrum master. Your role here is to overview the meeting. You have to make sure that praises were given to the development team no matter what. In addition, when we're talking about bad performances, make sure that they are commanded by the product owner or the team. They, that everyone is trying to find an explanation on what went wrong and justification. In addition, you have to make sure that no personal accusations are done. That there is mutual respect among all the team members of the framework. And that team speed is prevailing. 26. Chapter 4: Sprint Review - Things to avoid: Let's discuss now about things that you should avoid doing during the sprint review meeting in case that you are the product owner. The worst thing that you can do is to go in this meeting and prepared. This means going into the meeting without having an accurate overview of what was initially planned and what was finally achieved. Or in addition, if you forget to mention a big or a not so big milestone that was achieved or not achieved for getting to mention things, if you are part of the team, not being able to justify your performance, why you managed to do some things, and why you did not manage to do some other things. It's something that you should avoid during this meeting, you should come prepared and being able to give accurate feedback. If you are the scrum master, the same applies to you. So you have to go to the meeting prepared, have an accurate overview of what happened and what not happen. And you should have your personal opinion about things. In addition, you should avoid letting the meeting go out of control. 27. Chapter 4: Sprint Retrospective: Hello. Now we will talk about the Sprint Retrospective. The Sprint Retrospective happens one time per sprint. It is the last meeting of the sprint. Happens usually straight after the sprint review. And it is the meeting that brings officially closure to the sprint theory says that in this meeting, the development team and the Scrum Master shall be the participants. But according to my experience, the product owner can be there as well, depends on the team spirit. According to Scrum theory, the Sprint Retrospective should last three hours in case that we have a monthly sprint. So in case that we have a typical sprint of two weeks, this means that according to theory, the Sprint Retrospective should be lasting one hour and a half. However, according to my experience, I think that the optimal time is 30 to 60 minutes depends on the size of the team, of course. Now, let's say in a few words, what is the goal of this meeting? So mainly the goal of this sprint retrospective meeting is to check how the team is doing in terms of performance, in terms of processes and tools that they're using, in terms of interpersonal relationships and how the tin can improve on all that. This is a very important meeting for improving the quality of the way that the team works. And during this meeting, we have a unique opportunity that every single team member can take the speed and express his or her opinion in front of the others regarding, of course, the way that the team works. Let's get now in more detail about the way that this meeting is done. The main organizer of this meeting is the scrum master is usually the sprint retrospective is split into two parts. First of all, we have the quantitative review. During this part, the Scrum Master presents to the rest of the team that team goals and they discuss together if the team goals were achieved or not. In addition, the Scrum Master presents some metrics related to team performance. For example, that team velocity, the number of tasks completed and various others. And the Scrum Master compares the numbers of the current sprint with the numbers that we got in the previous sprints in order to find out if the team performance has improved or not based on those metrics. Then we move on to the second part of the sprint retrospective, which is that qualitative review. During the qualitative review, first, the Scrum Master presents to the team the improvement tasks that were identified in the previous sprint and were planned for the current sprint. And they comment altogether regarding if those improvement tasks were finally achieved or not. Some examples of improvement tasks could be to improve the tin communication. Another example of improvement task would be to do some modifications in the server that the team is using so the team can have less downtime and faster performance. Then, after commenting on the team improvement tasks that we had to do for the current sprint. We move on to the funniest part of the retrospective. In this last part of the meeting, the Scrum Master, along with the team, they will try to elaborate and find new improvement tasks that they will plan for the next sprint. In order to do that and find those improvement tasks, there are numerous ways to do it, and the Internet is full of team games and Tim activities that help the team find new improvement tasks. But this is out of the scope of this course. I will only say here that after doing those activities, you will probably have a list of improvement tasks. And you will have to select one or two and plan them for the next sprint. 28. Chapter 4: Sprint Retrospective - How to take advantage of it: Let's check now how you can take advantage of the sprint retrospective meeting. If you are the product owner and you are invited in the sprint retrospective meeting, you should always bear in mind that this meeting is focused on the team. So the best thing that you have to do is to not interfere and not talk too much unless you are asked to. Of course, you have to congratulate the thing on the metrics that the scrum master will present. And if the metrics are not, the expected ones are not good, then try to provide some creative feedback. If you are asked in case that you are part of the development team, then this meeting is your meeting. What do I mean by that? Is that in this meeting, you have to talk, talk, talk and suggests, suggests, suggests. You have to talk openly about the positive points that you see, about the negative points that you notice about any improvements that you have in your mind. And you think that they could help that team performance. You have to always bear in mind that this is your chance to talk about your needs within the team regarding work and about your feelings regarding the team spirit. So the more you talk and the more you open yourself towards the other team members, it's the best for you in case you are the scrum master when going through the quantitative review, the first part of the sprint retrospective meeting, instead of just presenting the metrics of the team performance, being able to have a critical thought about those metrics and the reason why we have those numbers. Then, during the second part of the retrospective meeting during the qualitative review, please, being able to judge what is the status of the improvement tasks if they're complete or not, and up to which extent, so come prepared to the meeting and know the status of the improvement tasks. Last but not least, in the funniest part of the of the sprint retrospective meeting. First of all, as a scrum master, you have to make everyone feel comfortable. You have to find a way and give incentives to the team members to talk. They have to express themselves. One thing that you can do is to start and give the speech to every single member. And well, this is quite a traditional way of course. But as I said earlier on the Internet, there are numerous team games that can have a really good results. 29. Chapter 4: Sprint Retrospective - Things to avoid: Now let's discuss about things that you should avoid doing during the sprint retrospective meeting. So in case that you are the product owner, if you are invited in this meeting, is a good sign that the, that the team feels comfortable with you. However, as we said earlier, avoid making yourself notice too much unless you're asked, of course, to say your opinion or to comment on the discussion. In any case, tried to be creative, try to be positive and try be supportive. If you are part of the development team. During the sprint retrospective meeting. Even when you are talking about things that you don't like and things that you would like to be improved. Always talk with respect regarding your teammates, regarding the scrum master, regarding the product owner? Yes. It is true that the nature of the sprint retrospective is to mention to point out things that we don't like and things that we want to be improved among the positive things, of course. However, everything shall be done with respect and with a creative and a constructive attitudes. In addition, you should avoid talking only about negative things. And don't hesitate to mention that things that you like because this is something very important as well, and it's always a lifting the team spirit. Another common mistake that a lot of team members are doing is that during the team retrospective, they are not expressing themselves. And you should avoid doing that are told course, because this meeting is for you. It's helping you, it's helping your situation within the project, within the team. So take advantage of this meeting. Last but not least, avoid not having worked on the improvement tasks that were assigned to you. Now, in case that you are a ScrumMaster, if you don't try hard to make everyone express themselves, this is something that you should really work on. In addition, if you don't bring on the table things that you noticed during the sprint. This is a bad habit because in the end, this is the goal of this meeting. Another thing to take into account is to not walk into this meeting with a very serious attitude. This meeting takes place in the end of the spring. Everyone is exhausted and everyone would appreciate a relaxing and kind of fun atmosphere. Last, but for sure, not least, a very important mistake that you as a scrum master will have to avoid at all costs is letting things get out of control. Yes, it is true that during the sprint retrospective meeting, negative things and points for improvement will be mentioned by the participants. However, it is your job to make sure that those things are mentioned in the creative and positive way. 30. Chapter 4: Agile Scrum Meetings Outro: Congratulations. You have just completed a very important section of the course. Here, I would like to note that each of those meetings that we have just analyzed are equally important and necessary in order to have a high-performing team, please feel free to go back to this material because it is very important for you to understand the concept behind each of those meetings and how they are supposed to be executed. Then in order to maximize your performance, pay attention to where you should focus or needs meeting and the pitfalls that you have to avoid. 31. Chapter 5: Values and Philosophy Introduction: Now let's discuss about the values and the philosophy of this gram, Agile framework. Even though the Scrum agile framework is quite open and flexible as a framework so that all sorts of people can work together, no matter which is the personality of each one of them. It still has some values and philosophy that we all have to respect. So it is quite important that the higher management of a company and the key roles of the people within a company share the same beliefs and have the mindset of the Scrum Agile framework. Because this will permit the company to better execute the framework. After that, it is the responsibility of the Scrum Masters of a company to instill this mindset, those values and this philosophy to the engineering teams, the product owners, and the rest of the people working in a company. Since my goal with this course is to give you more practical information about the day-to-day work within the Scrum framework. And to give you real life examples, I will not focus that much on the values and the philosophy of the framework. However, I will quickly go through them so that you can have a general idea. 32. Chapter 5: Philosophy of Agile Scrum: So let's talk first about the philosophy of this grammar giant framework. The people who have built the Scrum Agile framework, they have used their years and years of experience in order to do that because they know what works best in the most efficient way. So this means that the scrum framework is built using an empirical approach. This is why the first thing that all of the Agile Scrum teachers and coaches will tell you is that you have to use there all the artifacts, the tools, the meetings of the Agile Scrum framework, exactly the way they are meant to be used and no, to try to do any modifications on them. In short, they will tell you not to try to reinvent the wheel. There is a reason behind that. So in this mainly goes to all the Scrum Masters and the higher management of the company who are of course, the main responsible for the correct execution and application of the framework. So regarding the philosophy of the Agile Scrum framework, it is based on three pillars, transparency, inspection, and adaptation. 33. Chapter 5: Philosophy Pillar 1 - Transparency: So let's talk first about the transparency. Everything related to the Scrum framework there, all the artifacts and the meetings are built in order to provide maximum transparency to everyone. And by transparency, we mean that all the responsible site within the framework, the PO scrum master, the development team. They have attained point maximum visibility of what are the goals that we have set. We'd see is the status of the current work in progress and what are the next steps to be done in order to finally complete the planned work and the Agile Scrum framework with their old the artifacts and the meeting that it has, its offering, that transparency so that everyone can have the same opinion regarding the definition of done of the tasks. 34. Chapter 5: Philosophy Pillar 2 - Inspection: Let's talk now about the inspection. The Scrum agile framework is built in such a way in order to provide to all of its participants quick inspection at any given point in time. What I mean by that is that even if we're talking about the product owner, the scrum master, or any member of the development team. They can at any given point in time, take a quick look at the current progress status and check if there are any deviations from the initial plan. 35. Chapter 5: Philosophy Pillar 3 - Adaptation: Now, let me tell you about the third and last pillar of the Agile Scrum framework philosophy. The third pillar is called adaptation. What I mean by that is that if someone within the Agile Scrum framework does an inspection, which is the second pillar, and notices a deviation from the initial plan goals. This person, she has to inform the product owner and the Scrum master as soon as possible about the deviation that he noticed. Then the product owner, the scrum master, along with the development team, they have to adapt as soon as possible. The plan in order to minimize the damage done. 36. Chapter 5: Values in Agile Scrum: Now let's discuss about the values of the Agile Scrum framework. Those values are 5, commitment currents, focus, openness, and respect. 37. Chapter 5: Value 1 - Commitment: Let's talk about the commitment. In the Agile Scrum framework. Everyone has to commit to specific goals and objectives. One very clear example here are the sprint goals that we're setting on the sprint planning meeting in the beginning of every single sprint. The commitment to those goals by the development team should be the development teams driving force until the end of the spring. 38. Chapter 5: Value 2 - Courage: Let us discuss now about carets. Here. We don't have too many things to say really. It is true that during the sprint we will face many positive, enjoyable and even funny moments. However, it is almost certain that we will face some negative and difficult moments. For example, maybe we will not have enough time to complete a task 100 percent according to the definition of done. And we will have to describe it a little bit. There will be moments that we will face unexpected results. Moments that we will have to make difficult and unpopular decisions. During all those moments. It is really important that everyone within the team will have courage. 39. Chapter 5: Value 3 - Focus: Now let's move on into the focus. In order to achieve the commited goals. It is very important that the development team stays focused during the whole sprint. It is a responsibility of the scrum master, the product owner, and even of higher management within the company, to provide the development team all the tools necessary in order for them to reach their goals. In addition, we'll have to remove any impediments as soon as possible, which are blocking the development team's workflow. And last but not least, there will have to filter out any kind of noise that my reads the development team during the spring. 40. Chapter 5: Value 4 - Openness: Now let's move on to one of my favorite values, which is openness. By openness, we mean that everyone should be able and feel comfortable to express their opinion. Even this is not a positive or very popular one. And we're talking about opinions regarding the goals that we have set, the tasks, the way that we are working as a team. Everything, however, we have to make it clear here that all sorts of opinions should be accompanied by a good reasoning. The Scrum agile framework though, makes it clear that the ability to provide accurate feedback from management to their team, from the team to the management. He's a key in order to have a winning performance. So be open, be willing to receive constructive feedback no matter from home. It gums, and be able to listen to an opinion which might be different than yours. 41. Chapter 5: Value 5 - Respect: Last but not least, let's talk about respect here. Really. We don't have to say too many things in every aspect of our lives, during our personal life, during our professional life. When we are exercising a hobby with some friends, we always have to show and be treated with respect. And the same applies to this grammar gel framework. So in order to take full advantage of the framework, we have to respect every single one of the participants along with their rights and responsibilities that each one of them has according to their own, the artifacts and their usefulness. The meetings in their purpose. 42. Chapter 5: Agile Scrum Values and Philosophy Outro: Nice. You have just finished the section about the values and philosophy of file types gram. As you have seen in this section, you did not find much practical information about the framework. However, as you move on in your career and you gain experience, is equally important to know the mindset based on which he's built the Agile Scrum framework as you advance in your career. And in order for you to be an integral and leading part of the team, it is very important that you absorb this mindset and principles and integrate them into your daily behavior and way of working. So don't try to learn the values and philosophy or fat cells ground by hat. This is not the point. Just read them, go through them, and try to make them part of yourself. Let them be your guiding light and competence. 43. Chapter 6: Sprint Workflow Introduction: Hello, In this section, I am going to present you the sprint workflow. This means that we will go through a sprint together, starting from day one, step-by-step until the end of it until now, we have analyzed in detail the roles, the artifacts, and the meetings of the Scrum framework. So the scope of this section is to put together all this information and in the correct order. So you have a clear picture of how a sprint looks like. We're not going to enter into too much detail though, about a specific meeting or about what a specific role has to do with him miss meeting since this information is presented to you already. Now, we will just focus on the flow. So in case that you have any doubt, feel free to go back to the previous sections and use them as a reference. 44. Chapter 6: Sprint workflow: So let's start. The first thing that we're going to do when the sprint starts is the sprint planning meeting? It is true that some scrum masters schedule the meeting sometimes in the end of the previous sprint. However, I personally prefer it to the sprint planning meeting to coincide with the physical start of the sprint. What happens more or less during the sprint planning meeting is that the product owner, the scrum master, and development team, they all gather into the same place in order to set the sprint goals for the next sprint. In order to achieve those goals, they take the relevant tasks from the product backlog and they put them into the sprint backlog. And they decide on how to implement those tasks and in which order, in order to finally meet the Sprint goals. The objective is that by the end of the sprint planning, everyone has the same understanding of what needs to be done in which priority and in the end, how to get to those goals after the sprint planning meeting, as we said, that team shall have a clear objective. So for the next couple of days, they should really be focused towards meeting this objective and working uninterrupted. The only interruption for the development team members, ideally, for the next couple of days shall be the daily standup meeting. This meeting, Sally, ideally be quite short. And the purpose of it is to provide quick feedback to management regarding the work progress during those days where the development team is focused on meeting the sprint goals. Ideally, the product owner and scrum master are spending their days doing alignments with the project manager, with other teams, product owners and Scrum masters, and with the client, the information that they're gathering from all those alignments is helping the product owner and the Scrum Master for constantly refining the backlog and planning the next sprint to come. In addition, during those days, the product owner and scrum master. So keep an eye on the team's progress and block the team when they are facing and bloating issue and provide feedback to the development team when something unexpected happens. Then at some point during the first week of the spring, there shall be the backlog refinement meeting. I usually prefer having the backlog refinement meeting towards the middle end of the week so that we can have some distance from the planning day. During the backlog refinement meeting, we are processing all the information that we have received during the week from the Project Manager, from other product owners and Scrum masters of other teams, from the client, from the development team. In order to define every single task in the product backlog with focus on the next spring to come after the finish of the backlog refinement meeting, live continuous the same way as before. The development team chalet duly keep working focused towards meeting the sprint goals while the product owner and scrum master are continuously doing alignment with external people. Same way as before. The only Scrum meeting that the framework members will have to participate for the next few days is the daily standup meeting. Then at some point during the middle end of the second of the spring, I would like to have the second backlog refinement meeting of the spring here, the goal of the second meeting is exactly the same as the goal of the first backlog refinement meeting that we had during the first week, putting together all the information that we have received during the last few days in order to update every single task within the Product Backlog, create new tasks if necessary, etc. Always looking towards the next spring. In addition, after the second backlog refinement meeting, the product owner and scrum master shall be really preparing themselves for the next sprint to come. They shall be creating a draft plan. Then if we're talking about a two week sprint, in the end of the second week, we have reached the closing day of the sprint. During this closing day, there are two important meetings, the sprint review and the Sprint Retrospective. During the sprint review, the product owner, the scrum master, that development team and maybe some stakeholders gathered together in the same place in order to discuss if the sprint goals were met or not and discuss any possible improvements. Maybe present a demo of the work done. Then the last scrum meeting is the sprint retrospective meeting. With this meeting, we are closing the sprint and usually this meeting is done in a relaxing atmosphere. The participants of the sprint retrospective meeting is the development team and the Scrum Master. Usually, the goal of the sprint retrospective meeting is to reflect on the team performance, the processes that tools and find ways to improve them. Now, we have finally reached the end of the sprint. So now you know what is the sequence of events that you have to follow? 45. Chapter 6: Sprint Workflow Outro: Congratulations, you have just finished a quite short but quite important section of the course. In this section, I wanted to put together all the information that we have learned until now in the correct order so that you have a clear image of what a sprint looks like. In this way, you will be prepared about what you're going to face the first day that you're going to step your foot in a company or in an organization that are applying the Agile Scrum framework. Of course, there may always be some small differences and deviations depends on the preferences of Fritz scrum master. However, this is mainly how a sprint looks like. So feel free to revise this section in order for you to be on your toes. 46. Chapter 7: Course conclusion: Congratulations, we have reached the end of this course. I have tried to be quite analytical and provide you with practical examples in real life information regarding the Agile Scrum framework. By now, you should have a solid understanding of the different roles that people have within the Agile Scrum framework, the artifacts, the meetings that you have to participate, and how you can take advantage of those meetings, the pitfalls as well that you have to avoid during those meetings. Moreover, we had a short introduction to the philosophy and the values that characterize the framework. Last, but not least, we went through a sprint together and put all this information in place by finishing this course. Now, I think that you are able to start working within the Agile Scrum framework tomorrow without facing any big surprises. I believe that you have all the knowledge necessary in order to pass an interview that includes questions regarding Agile Scrum. And I think that you are more than capable of having a meaningful conversation with your friends and colleagues about this topic. Finally, I really hope that I gave you all the necessary incentives that you need in order for you to further seek knowledge regarding Agile Scrum. A big, big thank you. From my side.