Agile & Scrum in Depth - Module 2: Scrum Framework - First steps of a Scrum Master or Product Owner | Ignacio Paz | Skillshare

Playback Speed


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

Agile & Scrum in Depth - Module 2: Scrum Framework - First steps of a Scrum Master or Product Owner

teacher avatar Ignacio Paz, Agile Coach and trainer, Professor

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

49 Lessons (1h 46m)
    • 1. Introduction

      2:19
    • 2. Section: Introduction to Scrum - Learning Objectives

      0:22
    • 3. What is scrum?

      4:30
    • 4. Scrum Framework

      1:52
    • 5. Scrum accountabilities

      6:13
    • 6. Scrum accountabilities

      6:18
    • 7. Scrum Flow

      4:22
    • 8. Uses of scrum

      1:28
    • 9. When to use Scrum?

      1:38
    • 10. Scrum Pillars: Empirical Process Control

      1:43
    • 11. Scrum Values

      1:52
    • 12. Section: Scrum Culture - Learning objectives

      0:22
    • 13. Scrum is very easy and very hard

      0:55
    • 14. Agile is about people

      1:19
    • 15. Scrum Implementations: Scrum-but, cosmetic scrum, agile fertile soil

      2:59
    • 16. Section: Scrum Accountabilities- learning objectives

      0:22
    • 17. Scrum accountabilities: Product owner

      2:25
    • 18. Scrum accountabilities: Developers

      3:27
    • 19. Scrum accountabilities: Scrum Master

      4:57
    • 20. Scrum accountabilities: Scrum team

      1:33
    • 21. Other Roles outside Scrum

      1:41
    • 22. Scrum Roles Self assessment

      0:34
    • 23. Section: Scrum events - Learning objectives

      0:22
    • 24. Scrum events: Overview

      2:59
    • 25. Scrum events: Time-box

      1:14
    • 26. Scrum events: Sprint planning

      3:47
    • 27. Scrum events: Sprint

      2:05
    • 28. Scrum events: Cancelling sprint

      2:02
    • 29. Scrum events: Daily scrum

      3:20
    • 30. Scrum events: Sprint review

      1:48
    • 31. Scrum events: Retrospective

      1:54
    • 32. Product Backlog Refinement (ongoing process)

      2:07
    • 33. Section: Create Scrum Events Agenda - Learning objectives

      0:22
    • 34. Scrum events agenda examples

      3:59
    • 35. Challenge: Create Scrum Team agenda

      0:51
    • 36. Section: Scrum artifacts - Learning objectives

      0:22
    • 37. Scrum artifacts

      1:40
    • 38. Scrum artifacts: Product Backlog

      2:34
    • 39. Product Goal - Commitment for the Product Backlog

      1:03
    • 40. Monitoring Product Goals Progress : Release Burn-down Chart

      2:51
    • 41. Scrum artifacts: Sprint Backlog

      2:20
    • 42. Monitoring Sprint Progress: Sprint Burn-down chart

      1:55
    • 43. Scrum artifacts: Increment

      2:44
    • 44. Definition of Done - Commitment for the Increment

      3:11
    • 45. Create the Definition of Done with a Template

      0:35
    • 46. Technical debt

      4:42
    • 47. Scaling Scrum with Nexus

      5:27
    • 48. Next Class

      0:38
    • 49. Thank you and Final thoughts

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

95

Students

--

Projects

About This Class

The guide to learn Scrum properly. The strong foundations to be able to move to advanced topics.

Are you looking to learn Scrum properly to become a successful Scrum Master, Product Owner or Scrum team member?

Did you know that many Scrum implementations fail because of wrong assumptions and lack basic but key knowledge of the Scrum Framework?

In this class we will go together through the key knowledge of Scrum that you must learn well and understand correctly in order to become a great Product Owner, Scrum Master or Scrum developer.

Many people want to start the journey to Scrum but they don’t know how to start.

This course covers all the concepts of the latest Scrum guide 2020 but in an easy to understand, visual and effective way. I know you will get great value from it.

With the challenges and final cheat sheet and assessment you will be able to validate your knowledge and gain confidence to speak loud about scrum at work, in a job interview or answer exam questions.

Note: If you have no knowledge of Agile, please take this class first: Understanding Agile

If you find this interesting, start this class now.

What you will learn?

  • Scrum Framework:
    • What is Scrum?
    • What Scrum Framework is
    • Uses of Scrum
    • When to use Scrum
    • The Scrum Pillars for Empirical process control
    • Scrum Values
  • Scrum Roles:
    • Product Owner
    • Scrum Master
    • Development team
    • Scrum Team
    • Interaction with stakeholders and organization
    • Scrum Roles self-assessment
  • Scrum Events
    • Sprint
    • Time-box
    • Cancelling a Sprint
    • Sprint Planning
    • Daily Scrum
    • Sprint Review
    • Sprint Retrospective
  • Scrum Events Agenda and Calendar
    • Examples
    • Challenge: Create Scrum teams‚Äô agenda
  • Scrum Artifacts
    • Product Backlog
    • Product Backlog Refinement
    • Monitoring Product Goals
    • Sprint Backlog
    • Monitoring the Sprint progress
    • Product Increment
    • Definition of Done
    • Template of Definition of Done
  • Technical Debt
  • Scaling Scrum with Nexus

What you will you create?

In this class you will:

  • Create Scrum Role self-assessment: Create a self-assessment in your desired Scrum role to detect your skills for such role, what to improve and define actions.
  • Create agenda of events: Create the agenda of events for sample scenarios of teams.
  • Create the calendar appointments for your team
  • Create Definition of Done: Use a template to create the DoD.
  • Validate your Scrum knowledge: Review a summary and take an open assessments to get a score and validate your knowledge of Scrum.

This course is specifically for:

  • People looking to learn Scrum from the beginning.
  • People struggling with Scrum that need to re-learn it in the proper way.
  • People that want to understand Scrum as described in the Scrum Guide.
  • People looking to take scrum exams.
  • People that is comfortable with concepts and theory.
  • Students who completed the class Understanding Agile¬†https://skl.sh/3bn5a2H

This course is not suitable for:

  • People that don‚Äôt know the Agile Manifesto. In that case, please take this class first: Understanding Agile¬†https://skl.sh/3bn5a2H
  • People that already know the Scrum Framework very well.
  • People looking for techniques, methods and tools to apply in Scrum. In that case, please take the User Story Mapping Workshop¬†https://skl.sh/3aC8ENH
  • People that wants shortcuts and just practical directions to avoid theory.

Why taking the class? What you will gain?

  • The right knowledge of scrum fundamentals as it is defined in the scrum guide.
  • Become keen and sharp about scrum knowledge.
  • After this class¬†you will be able to learn concrete methods and understand how they fit in Scrum correctly.
  • Validation of your knowledge with a score.
  • High Confidence to take job interviews and Scrum exams.

Congratulations! You read all the class description! What are you waiting? Start this class now.

If you have any questions, please start a discussion in the course and do not hesitate to leave me a question.

About me

Hi my name is Ignacio. https://www.linkedin.com/in/ignaciopaz/

My main goal is to help you with new knowledge that you can apply at work and be a successful and professional leader.

I led, coached, led and managed Agile projects and scrum teams since 2005 for customers from all over the world.

During my career of intensive learning I got many advanced scrum certifications including Certified Scrum Professional Scrum Master, Certified Professional Scrum Product Owner and Certified Agile Leadership.

I worked 15 years as a Professor for Agile Methodologies and Systems design.

I love to teach Agile and Scrum and I designed a lot of hours of training that I am bringing online. I prefer to teach with games and activities that can simulate the real world.

I trained hundreds of students in Agile that became top professionals in the industry. 
Teaching what I learned in my 20 years of experience allows the students to gain realistic learning that they can apply at work.

Meet Your Teacher

Teacher Profile Image

Ignacio Paz

Agile Coach and trainer, Professor

Teacher

Hello, I'm Ignacio 

https://www.linkedin.com/in/ignaciopaz/

https://twitter.com/nachopaz

I led, coached and managed Agile projects and scrum teams since 2005 for customers all over the world.

During my career of intensive learning I got many scrum certifications including Certified Scrum Professional Scrum Master, Professional Product Owner and Certified Agile Leadership which are very difficult to achieve.

I worked 15 years as a professor for Agile Methodologies and Systems design in one of the most important technological universities in Argentina.

I love to teach Agile and Scrum and I designed a lot of hours of training that I am bringing online. I prefer to teach with games and activities that can simulate the real world.

My... 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. Introduction: are you looking to learn scrum properly to become a successful scrum muster problem owner or scrum PTA member? Did you know that many scram implementations failed because of wrong assumptions and lack of basic but key knowledge Off the scrum framework? We will go together through the key know ledge of scrum that you must learn well and understand correctly in order to become a great product owner, scrum master or scrum developer. Many people want to start the journey to scrum with the right information and serves, but they don't know how to start. Thesis course covers all the concepts off the latest crime guide, but it any Cito understand visual an effective way. I know you will get great value from it with a final Cheech it an assessment, you will be able to validate your knowledge and gain confidence to speak loud about, scram a work in a job interview or answer some questions. Hi, my name is Ignacio Bas. I lead coached and managed actual projects and scrum teams for customers like MTBE Rider eHarmony suppose version one, which is one of the top agile project management tools and then the other since 2005 all over the world. During my career, off intensive learning and practice, I get many advance certifications, including certified scram professionals from Master Professional Problem owner and certified Watch our leadership I s Award 15 years, Professor for agile methodologies consistent signs I love to teach agile and scrum And I designed a lot of hours off training that I am bringing a line teaching what I learned in my 20 years of experience allows the students to gain practical and realistic learning that they can apply at work. This class can always be improved. So if you have any topic that you would like to know more, please let me know so I can include it in this class. Only future courses. What are you waiting? Start discourse now. 2. Section: Introduction to Scrum - Learning Objectives: 3. What is scrum?: Let's talk about what Scrum is. Let's start with the definition of Scrum. According to the Scrum Guide. Scrum is a lightweight framework that helps people, teams in organizations generate value through adaptive solutions for complex problems. Every word in this definition was carefully selected with a purpose. Let's analyze it. So scrum is a framework, not a method or technique. You will hear people saying things like the Scrum methodology. We'll use certain processes and methods inside Scrum, but those are not part of Scrum and there is not such thing as the Scrum methodology. In fact, this is one of the basic questions during the Scrum certification exams. You can imagine Scrum as the mole for cupcakes. You have one milled with just a basic shape, but you have to decide how to use it. You can try different ingredients and decorations every time to create different results for different occasions. You can improve your aside according to the gusto verse. You can adapt it for gluten-free begun people. That implies that it's a framework for people to work. We will see this later as the scrum team. No framework is the panacea or will do the work for us. We need to work on complex stuff and take decisions to achieve a goal. The framework will give us directions for people to work together. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. The people in the framework will address complex adaptive problems. We mean to solve real problems that are not only complex, but they will change according to variables that we cannot control or foresee. And this framework is to deliver products as a solution to the problems. Because the problems are complex adaptive, the products will be complex solutions and need adaptation of the highest possible value. We will work in a way to provide the most valuable things of this product that make our customers happy and successful. First, scrum is a framework for developing, delivering, and sustaining complex products. Scrum is not a process or technique or the infinitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and walk techniques so that you can continuously improve the product, the team, and the working environment that makes it lightweight, simple to understand, but difficult to master specific tactics for use in the scrum frameworks Barry and are described elsewhere. Actually, that is one of the keys for the success of Scrum. It is not attached to any particular method which allows the community to always improve the best practices and provide different options to apply it in different contexts. Scrum is founded on empirical process control. Instead of the defined process, we expect the unexpected and verify by observation and experience to take decisions. Scrum is also founded only in thinking. We want to focus on the essentials. We want to be productive, efficient, and avoid waste. We build the product with an iterative and incremental approach. That means that in each iteration we modify the product to add a few more features that are ready to use. So the product is always in progress and subject to change, but at the same time, it can be used by the customers. Scrum is a framework. But if we want to be agile, we still need to follow the Agile values and principles of the Agile Manifesto. By the end of this course, you should be able to understand the components of this framework, as well as some of the most effective practices and methods to apply within their framework and with your team. 4. Scrum Framework: The Scrum Framework. Scrum framework consists of a Scrum team and it's accountabilities, events and artifacts. The rules of Scrum bind together. The accountabilities, events and artifacts establish in their relationships and interactions between them. Each component within the framework serves a specific purpose and is essential to the success unused off Scrum. If you removed part of this components, you are no longer used in Scrum. On the other side, anything not described in the Scrum framework is not part of Scrum. Scrum is intentionally incomplete so the team can decide the processes and methods that they prefer to work within the framework. The scrum guide contains the definition of Scrum. Scrum was developed by Ken Schwaber and Jeff Sutherland. The Scrum Guide is written and provided by them together, they stand behind the scrum guide. The Scrum Guide is translated into 30 languages, so you can probably read it in your own language. You intend to take the certification exam. You need to read it unstudied in depth. However, the questions of the exams are in English, so it is recommended that you read it in English a few times to get familiar with the concepts and words that will be referenced in the exome. Reading the scrum guide will give you a good knowledge about Scrum, but it will not make you an expert or practitioner in Scrum. It is more like reading the loss of the game. For football, you will know what a corner is and when it's a goal, but you will not understand it until you played many times, undeveloped skills. 5. Scrum accountabilities: The fundamental unit of Scrum is a small team of people that we call the Scrum Team. Scrum defines a three specific accountabilities within the Scrum team. Do you know them? They are the product owner, the developers. On the scrum master. The product owner interacts with external people to the scrum team called the stakeholders. That includes users, customers, investors of the project, executives, managers, departments of the company, and more. They are not a role in Scrum, but they are the ones affected and benefited by the result of the product under development by the Scrum team, they are interested in getting a solution for their problems. The stakeholders usually have a lot of different ideas. And each of them might think that their ideas are important and she'll high-priority. I show the product owner as a funnel or she is the main interface of the scrum team to the stakeholders. She has to work with them to take decisions about the product, to translate their needs into a priority ties, unclear list of what to build. The product owner is the voice of the stakeholders and takes all the decisions of the product. Our second account doubles are the developers. They were previously called the Development Team. So you will hear and read a lot of references with that name. They will receive this clearly is from the product owner and they will build the product increment for each iteration or sprint. Scrum recognized no titles and no sub-teams inside the developers a lot team members might have specialized skills that developers as a whole are a cross-functional group of people that together have all the necessary skills to build and deploy the product without dependencies. No one tells them how to build it. They are a self-organizing team that decides how to build the product and choose the process and tools that they want to use. No one control them or manage them. They manage their progress themselves. Once they commit to a goal, they are accountable as a team. The only one that can tells them what to do for the product, but not how after discussion and agreement is the product owner. This doesn't mean that the developers cannot talk to the stakeholders. The product owner can promote collaboration and discussion between them so the team better understand the problems. But the stake holders cannot tell a team member to make a change or give priority to certain feature. If that happens, the stakeholders should be just sent back to talk to the product owner. The product owner is the only one who can take decisions about the product. The third accountability is the scrum master. The Scrum Master acts as a guide to the organization on Scrum theory practices and rules. The scrum master is a servant leader. He leads by helping his not a boss. He serves by modelling an agile mindset and skillful use of Scrum framework. Scrum master ensures that the product owner, developers, and organization as a whole understand how Scrum can be used to help them accomplish and align their goals. The primary goal of the product owner is to maximize the value of the product on the work of the scrum team. The scrum master is responsible for ensuring that Scrum is understood and used skillfully and effectively by the Scrum team. The primary goal of the developers is to build the product increment. In each sprint, only developers work on the product. The product owner is one person, not a committee. She represents anyone outside the Scrum team with interest in the product. The scrum master is one person. The size of the Scrum team should be small enough to remain nimble and large enough to complete significant work within a sprint. As a guideline, typically, they are 10 or fewer people fewer than May 3 encounter skill constraints to the lever, a potentially releasable increments. As soon as we add more team members, they have more people to talk to and to coordinate with. You can see how complex this becomes when we are more nodes, we just need more edges. That generates too much complexity for an empirical process to be really useful. Usually is preferred that the product owner and scrum master are dedicated full time to their roles. However, in some cases, they can also work as developers. Some people confuse the scrum team with what was previously called the Development Team. So make sure to notice the distinction, especially if you read the book or article based on a previous version of Scrum, like the Scrum Guide 2017, the development team is a group of people that build a product and is inside the scrum team in the Scrum guide 2020, this was renamed to the developers. The Scrum Team consists of product owner, scrum master, and developers. No other accountabilities are recognized in Scrum, a Scrum team. There are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on a product goal. Scrum teams are cross-functional, meaning the members have all the skills necessary to create value each sprint, they are also self-manage in meaning they internally decide who does, what, when, and how the entire Scrum team is accountable for creating a valuable, useful increment. Every sprint. 6. Scrum accountabilities: The fundamental unit of Scrum is a small team of people that we call the Scrum Team. Scrum defines a three specific accountabilities within the Scrum team. Do you know them? They are the product owner, the developers. On the scrum master. The product owner interacts with external people to the scrum team called the stakeholders. That includes users, customers, investors of the project, executives, managers, departments of the company, and more. They are not a role in Scrum, but they are the ones affected and benefited by the result of the product under development by the Scrum team, they are interested in getting a solution for their problems. The stakeholders usually have a lot of different ideas. And each of them might think that their ideas are important and she'll high-priority. I show the product owner as a funnel or she is the main interface of the scrum team to the stakeholders. She has to work with them to take decisions about the product, to translate their needs into a priority ties, unclear least of what to build. The product owner is the voice of the stakeholders and takes all the decisions of the product. Our second account doubles are the developers. They were previously called the Development Team. So you will hear and read a lot of references with that name. They will receive this clearly is from the product owner and they will build the product increment for each iteration or sprint. Scrum recognized no titles and no sub-teams inside the developers, a lot in members might have specialized skills. The developers as a whole are a cross-functional group of people that together have all the necessary skills to build and deploy the product without dependencies. No one tells them how to build it. They are a self-organizing team that decides how to build the product and choose the process and tools that they want to use. No one control them or manage them. They manage their progress themselves. Once they commit to a goal, they are accountable as a team. The only one that can tells them what to do for the product, but not how after discussion and agreement is the product owner. This doesn't mean that the developers cannot talk to the stakeholders. The product owner can promote collaboration and discussion between them. The team better understand the problems, but the stake holders cannot tell a team member to make a change or give priority to certain feature. If that happens, the stakeholders should be just sent back to talk to the product owner. The product owner is the only one who can take decisions about the product. The third accountability is the scrum master. The Scrum Master acts as a guide to the organization on Scrum theory practices and rules. The scrum master is a servant leader. He leads by helping his naughty boss. He serves by modelling an Agile mindset, unskillful use of Scrum framework. The Scrum Master ensures that the product owner, developers, and organization as a whole understand how Scrum can be used to help them accomplish and align their goals. The primary goal of the product owner is to maximize the value of the product on the work of the scrum team. The scrum master is responsible for ensuring that Scrum is understood and used skillfully and effectively by the Scrum team. The primary goal of the developers is to build the product increment. In each sprint, only developers can work on the product. The product owner is one person, not a committee. She represents anyone outside the Scrum team with interest in the product. The scrum team needs a single source of truth. The product owner. The scrum master, is one person. The size of the Scrum team should be small enough to remain nimble and large enough to complete significant work within a sprint. As a guideline, typically, they are 10 or fewer people fewer than May 3 encounter skill constraints to deliver a potentially releasable increments. As soon as we add more team members, they have more people to talk to and to coordinate with. You can see how complex this becomes when we are more nodes, we just did more edges. That generates too much complexity for an empirical process to be really useful. Usually is preferred that the product owner and scrum master are dedicated full time to their roles. However, in some cases, they can also work as developers. Some people confuse the scrum team with what was previously called the Development Team. So make sure to notice the distinction, especially if you read the book or article based on a previous version of Scrum, like the Scrum Guide 2017, the development team is a group of people that build a product and is inside the scrum team. In the Scrum guide 2020, this was renamed to the developers. The Scrum Team consists of product owner, scrum master, and developers. No other accountabilities are recognized in Scrum. A Scrum team, there are no sub-themes or hierarchies. It is a cohesive unit or professionals focused on a product goal. Scrum teams are cross-functional, meaning the members have all the skills necessary to create value each sprint, they are also self-manage in meaning they internally decide who does, what, when, and how the entire Scrum team is accountable for creating a valuable, useful increment. Every sprint. 7. Scrum Flow: This is how the Scrum flow works with its components. We start with a plan to do a delivery in what we call a sprint. That is a fixit timebox of, for instance, two weeks. Most of the demes prefer one week or two weeks. The idea is to keep the spring length constant. Once the team decides to go with two weeks, they don't change it unless there is a very good reason. When the team completes the delivery, they reflect and adopt on day start the cycle again. So far this is not very different from the Deming will non US plan, do, check, act. But let's look into more details to the events, roles, and artifacts added by Scrum. To plan, we need to consider as strategic view on a short-term goal defined in a sprint planning at a more strategic level, there will be a vision or product goal on the product backlog, which is basically a wish list with everything that we will like for the product. The product backlog contains Product Backlog Items. The most valuable items are usually on the top. The Product Backlog is maintained by the product owner. The sprint planning is the first event of the sprints were the scrum team meets to decide which items of the Product Backlog can be done in the sprint. Usually, these are the items on the top of the product backlog and they are added to the sprint backlog according to a sprint goal. However, because the developers are about to take a commitment, they must agree that they can do this work in the Sprint. To do this, they consider their past performance on building similar items under capacity for the sprint. The sprint backlog is just a new backlog that contains only the items that will be developed within the Sprint. The sprint backlog is just a forecast, not a promise as any forecast, it can fail. But if you fail in a two-week plan, the impact will be much less than failing in a six month plan. Once the item for the sprint are selected, they set a sprint goal on developers discuss how to build those items. And they split the items into smaller units of work, usually called tasks. After that, the developers start working and they meet every day in an event called Daily Scrum to check their progress against the Sprint goal and take corrective actions during the day. They do this every day until the end of the sprint. Hopefully, they are done with all the items. In order to say that a Product Backlog Items are done, they need to meet the requirements of the definition of done. At this point, the Scrum team will reflect and adapt about this print in two ways, regarding the product in an event called Sprint Review. Regarding the process in an event called retrospective. During the sprint review, they take a look at the results of the sprint, which is a usable and valuable product increment that is the same product of every sprint, but now with the new features described in the items of the sprint backlog, This product is ready to be released if that is needed, are requested by the product owner. They will show it to the stakeholders and receive feedback. In the retrospective, the team says, what went well, what needs to improve, undefined actions for improvement in the next sprint. As a result of the feedback, the product owner will update the product backlog. Some items that didn't seem important have more priority now, others are less important. And there may be new ideas are changes that are added to the backlog. This is usually done in an ongoing activity called refinement. 8. Uses of scrum: uses off scrum scrum was initially developed for managing UN developing products. Since 19 nineties has been used for software hardware and that software, autonomous vehicles, services, schools, government marketing, monitoring, the operation off organizations and almost everything in the daily lives off individuals and societies. Scrum has been used worldwide to research and identified viable markets, technologies and capabilities off products. The Yusof scram in dealing with increasingly environmental complexity is proven daily, develop, sustain and renew complex products and enhancements. Scrum is very effective in IT relative and incremental knowledge transfer release products and enhancement, frequently working with a small team off people that is highly flexible and adaptive. Alos to release us frequently asked many times per day scrum alos the collaboration off networks off people that developed, release, operate and sustain the work off products with sophisticated architectures and develop and sustain cloud on other operational environments for product use. 9. When to use Scrum?: 12 you scrum. When we analyze requirements, we want to know what to do. This requirements can be very clear and predictable or very unclear and unpredictable. We also want to know how to do it, where the technology is very related, that can also be certain or very uncertain when the what to do on how to do it are clear. We have a simple project when one of this is clear, but the other not so much. We have a complicated project. When the requirements on technology are very unclear or unpredictable. We have a chaotic project on when what things are somehow unclear. We are dealing with complex adaptive problems. Where do you think scrum fits better? Yes, Scrum is good for dealing with complex adaptive problems. Under use off empirical process control, the product owner is the one that will define the most valuable things off. What to build the mind set off The product owner will be to build the right thing. The development team will define how to build it. Their minds said will be to build the thing right. The scrum master will suggest the right approaches and mindset so the people can embrace the right process 10. Scrum Pillars: Empirical Process Control: Scrum pillars for empirical process control. While a defined process control expects predictable, repeatable outputs given the same inputs in Empirical Process Control, US backed the unexpected. That makes it good to deal with complex adaptive problems. The characteristics of an Empirical Process Control R that we learn as we progress, we aspect and embrace change. We inspect and adapt using shorter development cycles on the estimates are indicative only on may not be accurate. An empirical approach is based on observations and evidence to make good observations. And empirical process has three pillars, Transparency, Inspection and Adaptation. To create transparency, scrum events and artifacts are visible to all those responsible for their outcomes. Artifacts and progress are inspected towards a sprint goal to detect deviations, but in a frequency that doesn't get in the way of the work, still provides sufficient chances to correct if during the inspections anything is determined to be outside of the goals the process plants, or product are adopted. The adaptation is made as soon as possible to optimize for a better outcome. When the Agile and Scrum values are embodied and lived by the Scrum Team. The Scrum peelers come to live on build trust for everyone. 11. Scrum Values: The right use of Scrum depends on people. Adopt him five, values. Commitment, people personally committed to achieving the goals of the Scrum team. Agile teams only agree to take on task they believe they can complete as a shared goal. They trust each other to follow through on what they say they are going to do. Courage. The scrum team members have courage to do the right thing and work on tough problems. Agile teams must be brave enough to question the status cool when it hampers their ability to succeed, we act in alignment with our beliefs. Focus, everyone focuses on the work of the sprint and the goals of the Scrum Team. Scrum teams prefer to finish what is some progress rather than start new work. Respect. Scrum team members respect each other to be capable, independent people. Take a second look at how we view an appreciate others and their ideas, accept their unique capabilities, contribution in collaboration, openness. The scrum team on its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum teams are transparent about their work. They seek out new ideas and opportunities to learn. Agile teams are also harnessed when they need help, when the values of Scrum are embodied and lived by the scrum team. Does grumpy Lars of Transparency, Inspection, and adaption come to live and build trust for everyone. 12. Section: Scrum Culture - Learning objectives: In this section we will see some Scrum implementations on organizational cultural patterns. But Gould boast or prevent the success of Scrum. Let start. 13. Scrum is very easy and very hard: At this point, as you may have seen, we can say that Scrum is very easy. It just simple to understand their roles, event, and artifacts that work together. However, specific tactics for use in the Scrum Framework vary a lot and are not described by Scrum. That makes Scrum Barry hard. Scrum is difficult to master. We need methods, tools, skills, and strong human values like discipline, technical excellence, learn from mistakes, cooperation, trust, empiricism, embrace change, be pragmatic, keep quality, harnessed the skills and more. So we need to foster the right culture and mindset. 14. Agile is about people: one thing that makes crime difficult is that agile is a lot about people. I see it as a team whose force is driven by the agile values and principles in the beginning is hard because they are like in a slope they are moving. The plan to check act will to continuously improve until the perfection which will never come on the soil is not firm because they depend on a lot of human values. You cannot just tell people to be 100% perfect, collaborative, courageous, motivated in just be perfect human beings. Human and scram values will not just be adopted because someone put at least off nice and beautiful words in a poster on the wall. Human values are fragile and we need to take care of them a lot. So we see at perfect scrum at the end. But we cannot be perfect. What we can do is to work every day on every spring and just to be a bit closer to that perfection. Working hard but working smart within the framework rules 15. Scrum Implementations: Scrum-but, cosmetic scrum, agile fertile soil: There are a few patterns that one can observe in different Scrum implementations. The first one is the one that we all want. That is Scrum acid must be in its whole perfection with 100% trust, total cooperation equal boys, total empirical, total honesty and so on. That is another implementation that we call Scrum bat, also known as cosmetic Scrum or fluxes scrum. Where a team do things because they're Frank, War tells them, but they are really not going anywhere or improving. It is called Scrum bought because people say things like, yes, we do scrum, but we don't do the retrospective or we do scrum, but we don't have a product owner or we do scrum, but we don't have a sprint review. And there are always excuses, like we don't really have much to improve. Or developers can just talk to the customers or we have a contract so we don't really need to show it to the customer or release often. And they say things like, I'm not a purist, I take the best of each tool. Our businesses, the spatial, our product is different. They see Scrum as a set of things to do, usually with a predefined process which remain static. There is no agility. The second one is an organic agility, where they agility minds that is adopted by the team. These teams have an abbot of change and retrospective as a change agent towards perfection and to fix their pains. Customization of the process occurs naturally with an empirical approach, there is agility in movement. So scrum bat looks like a rock. While inorganic agility, you can see a clear and visible wheel of continuous improvement. So it's important to make the jump to the organic agility. Where is easier for the agile mindset to grow organically like a tree that grows from fertile soil in an organization where there is competitiveness, individualism, bureaucracy, strict rules and control is more difficult that the values of Scrum can grow Scrum in those contexts, Google looked like a dry tree and more like Scrum, but it might work for them, but that is not Scrum. It's something else in an organization where there is some culture of cooperation, collaboration, equality, pragmatism. It is more likely for the values of Scrum to grow naturally. A healthy on colourful tree, but of course, needs care and water to become stronger. 16. Section: Scrum Accountabilities- learning objectives: In this section we will see the accountabilities previously called the roles of Scrum in depth. You can also use the assessment to identify the skills that you need or want to improve in your desired accountability within the Scrum Team. Lead start. 17. Scrum accountabilities: Product owner: The Product Owner is responsible for maximizing the value of the product that results from the work of the Scrum team. You can imagine the product owner as the CEO of the product. Scrum does not describe what value is or how to measure it. That is up to the Product Owner and depends on the contacts. Examples could be the success of the product, the happiness of the customers. A product that users love, revenue or savings. The product owner owns and manage the product backlog. Product owner is one person not a committee. It may represent a committee, but anyone that wants a change must talk to the Product Owner. The Product Owner is responsible for managing the Product Backlog. That includes developing an explicitly communicate in the product goal, clearly expressing Product Backlog Items, ordering the items in the Product Backlog to best achieve goals and missions. Optimizing the value of the work that the scrum team performs, ensuring that the product backlog is B, civil, transparent and clear to all and shows what the Scrum team will work on next. Ensuring the developers understand items in the product backlog to the level that they need. There is no predefined techniques for that. The product owner may do all that work or delegated to others, such as the developers. However, the product owner remains accountable. For the Product Owner to succeed, the organization must respect his or her decisions that are visible in the Product Backlog. No-one else can tell the developers on what to work. The management of the organization supports the product owner by providing insights to set the vision or product goal. During the Sprint, the product owner collaborates with the developers as needed to clarify items and interact with the stakeholders as needed to understand their needs. The marketplace unmeasured the value that is being delivered. 18. Scrum accountabilities: Developers: The developers. The developers are a group of professionals who are responsible for creating a useable and Dan, increment of the product by the sprint review, only developers work on creating any aspect of a USA will increment. Developers organize and manage their own work. The resulting synergy optimize the efficiency and effectiveness of the development team. They are self-organizing. No one, even the Scrum Master can tell them how to build a product that developers in a Scrum team are cross-functional. Each one might have specific skills, but as a group, they have all the necessary skills to create a Product increment. A group of developers must be able to work on all the layers of the product or system. If multiple Scrum teams are working on the same product, they can not organize to work on different layers. Scrum deem must work on all the layers of the product. There are no titles between the developers over Scrum Team, Scrum recognize no sub-teams. This is to avoid things like a test sub team or an architecture sub-theme, or a business analyst sub-team. Those things are proven to just cause frictions. All developers are committed to the same goal and they are accountable for the results as a team, they create the sprint backlog as a work plan for the sprint and they adapt their plan each day, Terroir the Sprint goal, they are there to the definition of dam and equality defined in it. These are the characteristics of the developers. The developers are highly collaborative. They are responsible for estimating the effort required to get the items of the product backlog done. Because they are the ones that will do the work. They are the only ones that can estimate. They motivate to each other, help to each other, teach to each other. There is no dictated leadership or heirarchy. Everyone is a leader that takes initiatives. They take commitments, they are highly disciplined and DE, are given full autonomy that comes with greater responsibility for delivery. They manage their own progress. They take reasonable risk, make experiments, are learned through, they learn from failure, are reflection, high trust, and high commitment is an automatic outcome of a truly self-organizing team. They take decisions as a team. This is possible with a group small enough to discuss face-to-face and get ideas from everyone. They keep a creative and productive environment. They improve in every sprint and they decide how to build the product. The developers decide as a group, the team structure, and who should work for each Scrum Team. Changes in the Scrum. The membership should be done as needed, but a short-term reduction in productivity must be taken into account. 19. Scrum accountabilities: Scrum Master: The Scrum Master is responsible for promoting Scrum acid is defined in the Scrum guide to Scrum teams into organizations. The Scrum Master is accountable for the scrum team's effectiveness and productivity. He does this by helping the scrum team to improve its practices. The Scrum Master is a servant leader for his team, not a boss. He doesn't give orders. Rather than that. He has good skills for being a good coach, facilitator, moderator, and mentor. He facilitates scrum events as needed or requested. He's responsible for time boxes. He makes sure that events are within the Find the time boxes by facilitating unmoderated or coaching that team. So they learn how to keep focus on the events inside a timebox, unseal produce the expected outcomes. He's a mediator for problems. If something is not working out, he makes sure that problems are exposed and discussed. He also helps those outside the Scrum team on how to interact with the scrum team in order to maximize the value obtained by the scrum team, you can imagine the Scrum master as Gandalf in The Lord of the Rings. He makes sure that his team has a goal and everything they need to go for it. He protects and inspired them, but he empowers them to do their work and take decisions. Sometimes He appears to help them to overcome some impediments and protect them from destructions so they stay focus on their goal. He sells a like a bulldozer that helps the team to remove impediments on the way towards the goal. Scrum Master radiates information by ensuring that team's progress and success is highly visible to all stakeholders. Scrum master provides services to their product owner by ensuring that the domain of the product, product goal and scope are clear for everyone. For instance, suggesting things outside of their frame work like the finding a product mission, using a business model canvas, an elevator pitch, value proposition, Impact Mapping, defining an MVP and more, suggesting techniques for Product Backlog management. For instance, user stories, job studies, User Story Mapping. Helping the scrum team understand the importance of clear and small Product Backlog Items. For instance, by teaching how to slice Product Backlog Items, creating a definition of ready using persona's empathy maps and estimate them with planning poker. Understanding product planning in an empirical environment, ensuring that the product owner knows how to maximize value from the product backlog. For instance, coaching on how to discuss and determined that the value and priorities of the product backlog items with their stakeholders, facilitating the collaboration with stakeholders as a requested or needed and spread in the agile mindset. Scrum master provides several services to the scrum team, like coaching them in self-management and cross functionality. Help them to create high value products. Removing impediments that are on their progress. Ensuring that all scrum events stake glaze and our positive, productive and within a timebox and provide coaching in organizational environment in which Scrum is not yet fully adopted. An understood on the Scrum Master serves the organization by leading and coaching the adoption of Scrum. Planning Scrum implementations within the organization. Helping employees and stakeholders understand Scrum and empirical product development. Removing barriers between stakeholders and Scrum teams, acting as a change agent that increases the productivity of the Scrum team. And working with other Scrum Masters to increase the effectiveness of Scrum in the organization. At the same time, the management must support the Scrum Master to cause organizational change. The organization should not tell the scrum master how to implement Scrum or suggest variations outside the Scrum Guide. Like for instance, change in rules, terminology, or vocabulary. 20. Scrum accountabilities: Scrum team: The fundamental unit of Scrum is a small team of people called the Scrum Team. The Scrum Team consists of a product owner, developers, I'm a scrum master. Those are the only accountabilities recognized by Scrum know hierarchies, no sub roles, no titles, no sub-teams. Scrum teams are self-managing. That means that they choose how to accomplish their work rather than being prescribed by others outside the team. Furthermore, they are empowered by the organization to manage their own work. The entire scrum team is accountable for creating a valuable, useful increment. Every sprint. Working in sprints are the sustainable pace improves their focus. Consistency of the team. Working as a cohesive unit of professionals, focus on one product goal at the time. They are cross-functional together, they have the sum of all the skills needed to accomplish their work without depending on others outside the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. This scrum team has proven itself to be increasingly effective for all this uses an any complex work. 21. Other Roles outside Scrum: Other roles outside the Scrum Team. There are other roles that are not part of the Scrum Team and they are not Scrum roles. So just in case, remember that the only accountabilities recognized by Scrum are the product owner, Scrum Master, and developers. However, IT world mention them as they are organizations or individuals that interact with Scrum teams. There are the stakeholders, which is anyone who has an interest in the outcome of the project or product stakeholders can be investors, customers, providers, managers, project managers, id, users, system administrators, departments, other teams and more. The Scrum Master will teach them how to interact with Scrum teams to get the best value from their work. The stakeholders have different interests, point of views, and priorities. Dealing with many of them is not easy. The product owner will walk with them as a single point to capture their ideas, problems, expectations, and determined the most valuable things to work on. Organizations and managers must support and empower the product owner, squad, master, and developers to fully embody their roles as described in the Scrum guide, your organization will also provide alignment, direction, and insights to define the vision and goals for the Scrum teams. The organization might have a standard definition of w1, which in that case, the Scrum teams must follow at a minimum. 22. Scrum Roles Self assessment: Now that you know this crime rolls, please think of the role that you would like to be or that you may be performing and make a lease with all the responsibilities on skills for that role, according to this summary, classify each of them a CIF. It's something that you can do well or that you will need to improve. So, like the top items to improve, share them for discussion on create actions to make it happen. Use the provided spread should your L in the project or video description. 23. Section: Scrum events - Learning objectives: In this section we will see the scrum events, their inputs, their outputs, and the responsibilities of each role during each event. Let start. 24. Scrum events: Overview: Scrum prescribes event to create habits and to minimize the need for other meetings. The main event is the Sprint that represents one iteration on is a container for all the other events. The events inside a sprint are the sprint planning, which is the first event of the Sprint. The daily scrum that occurs every day. And at the end of the sprint, there are the Sprint review and retrospective. All these events are required. They are visible to the scrum team and they have a purpose to inspect and adapt something. All the events are time boxed. The maximum time box for a sprint, one month, usually teams prefer shorter sprint of one week or two weeks. Once a sprint starts, its duration is fixed and cannot be changed given a sprint of one month, the maximum time box for the Sprint Planning is eight hours, four hours for the sprint review, three hours for the retrospective for shorter sprint, shorter timebox are expected. The maximum time box for the Daily Scrum is 15 minutes. Because of the limited time that Tim tend to focus on the most important things during that time and avoid non-related topics. The scrum master ensures that all time boxes are not exceeded and moves the conversation along when it's not serving the meeting's purpose. The scrum master teachers, that team how to keep inside the timebox. Day events cannot be extended beyond the timebox, but they can add earlier if their purpose is achieved optimally, all events are held at the same time and place to reduce complexity, the backlog refinement is not an event, it is an ongoing activity that the scrum team decides when to do it inside sprints, the backlog refinement has no timebox and is done as needed, but it is expected to not use more than 10% of their developers capacity during the sprint planning, a scope of work is agreed for the sprint. During the sprint, this cobe may be clarified or changed as long as he is renegotiated between their product owner and the Scrum Team. However, no changes can be made that Google endanger the Sprint goal. Quality does not decrease and the Product Backlog is refined as needed in order to prepare unmake Product Backlog Items ready for the next sprint. By the end of the contents of this section, you should be able to understand all these events. By the end of the sprint simulation section, you should have a better idea of how you can use this events in your team. 25. Scrum events: Time-box: Have you ever had a date for an exam or essay in one month? And you may randomly read something, but you don't study hard until just a few days before the exam. Parkinson's Law says that work expands to fill the time available for its completion. This means that a meeting that is scheduled for one hour will tend to take the full hour regardless of what gets accomplished, it is sometimes applied to the growth of bureaucracy in an organization. Have you ever felt that if you make a perfect plan, you will have perfect results. So you dedicate eight hours, but then you realize that the plan will never be perfect, and it is slightly better than what you had in four hours. You will have used those hours to do their work. We said Time boxes because we want to set a maximum time at the point that an event is productive enough and you have what you need to move forward and start their real work to build a working product with real value. 26. Scrum events: Sprint planning: The Sprint Planning is the first event of the sprint. During the sprint planning, we plan in a collaborative way, the work to be done in the sprint. The attendees are all the members of the Scrum team. The product owner must ensure that attendees are prepared to discuss the most important Product Backlog Items and how they map to the product goal. Sprint planning has three topics to be answered. The topic one is, why is this sprained valuable? The product owner suggests how the product may increase its value with our work and effort for the current Sprint, the scrum team then collaborate to define a sprint goal that communicates why the sprint is valuable to the stakeholders. The Sprint goal must be the single objective for the sprint defined prior to the end of the sprint lining. The second topic is what can be done in this sprint. For these, the team will need the product backlog and the last increment, the Product Owner Present the desired sprint goal on the items that you'd like to add to the product. Developers will consider the capacity that they will have or the sprint underperformance on previous sprints in order to forecast the functionality that they can develop for this sprint through discussion with the product owner, the developers select items from the product backlog to include in the current sprint, the scrum team may also refine these items during this process to increase understanding and confidence. They move the items they think they can accomplish from the product backlog to the sprint backlog. Topic three is how to get it done, having the Sprint goal and selected the product backlog items for the sprint developers discuss how to build this functionality into a done product increments during the sprint, developers school start with technical discussions and they plan at least the work for the first days of the sprint often split into smaller units of one day or less. How this is done is at the sole discretion of the developers. No-one else tells them how to turn Product Backlog Items into increments of value. The product owner can help to clarify this items on make trade offs, the developers may detect that this is too much or too little work and renegotiate with the product owner. The scrum team may also invite other people to attend to provide technical or domain advice. By the end of the Sprint Planning, the developers should have a work plan that describes how they intend to work as a self-organizing team to accomplish the sprint goal and create the aspect that increment. From here, only the developers should make changes to the sprint backlog. The Sprint goal plus the product backlog items selected for this sprint plus the plan for the library in them is called the sprint backlog. The sprint goal is the objective for the sprint and provides guidance to the developers on the Scrum Team. The sprint goal is a commitment by the developers for the sprint backlog, but also provides some flexibility regarding the functionality implemented within the Sprint. The Sprint goal also creates coherence and focus, encouraging the scrum team to work together rather than on separate initiatives. 27. Scrum events: Sprint: Sprint. Each sprint starts after the other, and there is no time between sprints in order to be predictable. Sprint censure, inspection and adoption of progress toward a product goal. Sprint have consistent durations along the development effort. The Scrum team will not change their length unless there is a very good reason the length of the sprint cannot be changed. Once a sprint started, the sprint length cannot be more than one month. Much shorter time boxes are preferred sprints or one week or two weeks. Very common. It should be short enough to keep the business risk acceptable to the product owner and the synchronize the development work with other business events. Sprints consists of Sprint Planning, Daily scrums, the development work, The Sprint Review and Sprint Retrospective. At the end of every sprint, a potentially releasable, invaluable increment must be created. This increment is totally tested and with no technical debt as it might be used by end users. There is no such thing as special sprint Du Bei technical depth. During the sprint, no changes are made that gold put in risk, the sprint goal, quality goes do not decrease and some product backlog items that are not clear, maybe clarified by reviewing the scope and details. If the work is different than the development team expected, they collaborate with a product owner to negotiate the scope of the sprint backlog within the Sprint. Also, the Product Backlog is refined as needed. We work in short iterations because we want to start working as soon as possible to have early feedback loops and learned fast, we will fail. We prefer to fail fast and correct it with minimal impact. Instead of working moms to realize that it is a waste. 28. Scrum events: Cancelling sprint: Cancelling a Sprint. A Sprint can be Council before the springtime box is over. At Sprint will be cancelled if the Sprint goal becomes obsolete. Under sprint no longer makes sense. This may occur because of company's decisions or important changes in the market or technology because of the short durations of the sprints, cancellations rarely makes sense. Only the product owner has the authority to counsel the sprint for he or she may act under advice or influence of others. When a Sprint is canceled, any items of the sprint backlog that are done are reviewed if part of the work is potentially releasable, the product owner typically accepted all incomplete items of the sprint backlog are re-estimated and put back on the product backlog. The work done or partially done on them depreciates quickly and must be frequently re-estimated. Sprint cancellations consume resources since everyone regroups in another sprint planning to start another sprint. Sprint cancellations are often traumatic to the scrum team and are very uncommon. As a practical experience, I've seen cases where sprint goal change too much. But because sprints are short, instead of canceling, the product owner preferred to avoid the overhead of cancellation and continue the sprint until the end to finish the work in progress that was still useful for the increment and maybe renegotiate some items. In this case, the Product Owner still found more value in doing that, done canceling the sprint. So I personally think that the choice of counseling or continue shall considered the most valuable thing to do. 29. Scrum events: Daily scrum: Daily Scrum. Every day that developers meet in an event called The Daily Scrum to inspect how the work of the sprint backlog is going according to the status of the items under sprint goal and they adopt as necessary. This helps to increase the probability to meet the Sprint goal. The maximum time box they can spend in this event is 15 minutes. The structure of the meeting is defined by the developers. An example but not mandatory, is to answer these three questions. What did I do yesterday that help to meet the sprint goal? What will I do today to help the developers meet the Sprint goal? And do I see any impediments that prevents me or the developers from median desperate goal. Usually it's not recommended to fix the impediments or start technical discussions during the daily scrum. It is better to just detect things that need actions and meet after the Daily Scrum only with the people involved in the topic for detailed discussions to adapt or replan the rest of the spring work. A common anti-pattern is that someone that is not the developer joins the meeting regularly on developers feel that it is submitting to report status to a manager. That is not the idea. This is a meeting of the developers. For the developers, they took a commitment to develop an increment and they are required to attend. The Scrum Master has three responsibilities related to the daily scrum. He assures that the developers have the meeting. He assures that non developers do not participate. If others are present, the Scrum Master makes sure that they don't disrupt the meeting in a neutral air facilitative role only. He teaches the developers how to keep the mating within the 15 minute time box. Once the development team is comfortable with the timebox under meeting is held regularly as part of the daily work, The Scrum Master may choose not to attend. The daily scrum meeting is typically held at the same time and place each day to reduce complexity. As a few tips to encourage habits, it is recommended to start strictly on time or not to wait for people to join. This will help to get people used to be on time and avoid delays if the timebox is reached and not everyone has spoken because others spoke too much or with too much details, it is better to just end the median. So the next time people learned to speak less focus on the goal. I'll leave time for everyone to speak. As a result of the daily scrum, the developers may adopt the sprint backlog in order to plan their work for the next 24 hours. Daily scrums, improved communication helped to identify impediments, promote quick decision making, and eliminate the need for other meetings. However, the daily scrum is not the only time developers are allowed to adjust their plan. They often made throughout the day for more detailed discussions about adopting or replanning and the rest of the work. 30. Scrum events: Sprint review: Sprint Review. And Sprint Review is held at the end of the sprint to inspect the increments and adapt the product backlog if needed, the scrum team review what was done in the sprint with the key stakeholders usually invited by the product owner but not prescribed. The scrum team presents the results of their work to key stakeholders and progress though are the product goal is discussed, they received feedback and collaborate together to think of the next steps for the product are the Sprint Review. A done increment is required, non-mandatory example of steps during the sprint review could look like the followings. And review where the Product Owner explains which items are gone and which are not. The developers discuss what went well and how they solve problems during the Sprint. The scrum team makes a demonstration of the work that is done, received feedback and answer questions. Sometimes the sprint review is wrongly called the demo. But notice that the demonstration is only a step of the spring review, but not its goal. And the product owner discusses potentially delivery dates. The entire group collaborate on what to do next day, review changes in the market and potential users of the product to think of the most valuable thing to do next day, review the timeline, budget, capabilities, and marketplace to draft anticipated releases of functionalities. The result of the Sprint Review is a Revised product backlog that defines the top items for the next sprint. 31. Scrum events: Retrospective: Sprint Retrospective. The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness of the scrum team. During the Sprint Retrospective, the scrum team inspect itself and create a plan for improvements for the next sprint. The sprint retrospective occurs just after the sprint review and before the next sprint planning the Scrum Master encourage the team to improve on ensures that the median is positive, productive, and within the timebox, the Scrum Master participate as a peer team member in the medium from the accountability over the Scrum process. Sprint retrospective consists of reflecting about the last sprint regarding people, relationships, process and tools, identify what went well, detect potential improvements, and prioritize the most important factors. Create a plan for implementing improvements to make the work of the scrum team more effective and enjoyable. During each Sprint Retrospective, the scrum team plans way to increase product quality by improving work processes and practices or adapt in the definition of done if appropriate and not in conflict with product organizational standards. By the end of the Sprint Retrospective, the Scrum team should have identified the most important improvements that will implement as soon as possible, unmade be added to the sprint backlog of the next sprint. Implementing this improvements in the next sprint is the adaptation to the inspection of the scrum team itself. Team members shall have the initiative to make improvements at anytime. But the sprint retrospective provides a formal opportunity for it. 32. Product Backlog Refinement (ongoing process): Product Backlog Refinement. Product Backlog Refinement is not an event, but an ongoing process in which the product owner and the developers collaborate on the details of the Product Backlog Items. During the Product Backlog Refinement items are revised to add details, estimates, and order the items in the product backlog. Items on the top of the product backlog usually are more clear and with more detail than the lower ones. Developers are responsible for all estimates. The product owner may help to clarify, understand, and select trade-offs. The people who will perform the work, make the final estimate. Product Backlog Items that will potentially be developed in the upcoming sprint are refined and make them ready to say that a Product Backlog Item is ready to be added to a sprint. We need to refine it to a level that the development team understand it unsafe, that it can be done within one sprint. For instance, an item with a lot of value, but that is too big, maybe split into smaller items that can be done in one sprint with most of the value. During the sprint, the product backlog is refined as needed. Previous versions of the Scrum Guide suggested to spend no more than 10% of the capacity of the developers. So that can be used as a non-mandatory guideline. The scrum team decides how and when refinement is done. However, Product Backlog Items can be updated at any time by the Product Owner is not required to schedule a specific time in the agenda for the refinement. However, some teams like to schedule a fixed time during the sprint just dedicated to refine Product Backlog Items. 33. Section: Create Scrum Events Agenda - Learning objectives: In this section you will see how the scrum events look in the agenda of a given team. And you can also practice with an assignment. Let start. 34. Scrum events agenda examples: Scrum events, agenda, and calendar. This is an example of how the agenda for two weeks sprint of a team may look like. In this case, they have a daily scrum of 15 minutes as the first thing of the day, at nine AM, the sprint starts on a Monday with a sprint lining of four hours in the morning and ends on Friday of the following week with a sprint review of two hours on a retrospective of one hour and a half, because the spring is 2-week long, they decided to use half of the time box that is indicated for one month sprint. The backlog refinement is not an event, but this team decided to schedule, fix a time during the sprint to refine items of the product backlog that will likely be added to the next sprint. Of course, the refinement is an ongoing activity under product owner will be working on the bug look a lot during the sprint with help of the developers or specific members as needed. This is an example of another agenda, but in this case, the scrum team prefers to start the sprint on Thursday and ended on the Wednesday after two weeks. I have seen this configuration on teams that prefers not so much pressure to release on a Friday. And also in countries where there are many holidays on Mondays or Fridays. So with this casual, they avoid rescheduling some events. This is an example of the agenda of one week sprint. The team starts on Monday with a planning and ends on Friday with a sprint review and retrospective. In this case, the team decided to use a proportional time of the timebox for one month sprint. That is a quarter of that timebox except for the retrospective that she will be 45 minutes as a proportional timebox of three hours, but in this case is one hour. That makes sense. For instance, for a team that is just starting angle, prefer to spend a bit more time on the retrospective. The Scrum Guide establish the maximum time boxes poorest print of one month length announces that shorter time boxes are expected for shorter sprints, but does not mandate to use a proportional time. This team did not schedule any fixed time for the refinement and they do it as needed. Regarding the daily scrum on Mondays just before the sprint planning because the spring is over an unused Bryn Mawr start. I have seen teams that prefer to skip the daily unjust start this Brin planning as they will coordinate there too. That is probably practical as The Daily does not provide value for them on Mondays. And if it works, I guess it makes sense. However, if you are going to take a scrum certification, remember that this crumb guide says that the Daily Scrum is held every day and does not mention any kind of exceptions for not having it. In strict terms. This team is not aligned with the Scrum Guide. Now, in this agenda of a one week sprint. Sprint is starting on a Wednesday after aligned on, ending on the morning of the Wednesday of the following week with a sprint review on retrospective. Usually it is good to think of breaks during the event or between the events. As a good practice to create habits. Teams come on lick Riyadh recursive appointments in a shared calendar for each event, odd in the right attendees and booking a room. I also like to add an image that summarize the event so everyone is aligned on what the event is for. If you like that idea, you can use this light images to add to your scrum events. 35. Challenge: Create Scrum Team agenda : challenge create the agenda for scram teams in the case. One. There is a mature scrum team working with a two x sprint, and they will like to end the sprint on the Monday on Started on Tuesdays. They don't have a time preference. This team spend one hour per week together in refinement, and they go like that in their agenda. The second case is a new scrum team that will start working with a sprint off one week. They would like to end on start this prints on Mondays. They accept all your advises. Your assignment is to create an agenda with all this crime event for each of these teams and share it. 36. Section: Scrum artifacts - Learning objectives: In this section we will see the Scrum Artifacts, which roles are responsible for them. And finally, you will create your own definition of Dan. Let's start. 37. Scrum artifacts: Scrum's artifacts represent work or value to provide transparency and opportunities for inspection and adaption. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everyone has the same understanding. Artifacts. Scrum mandate, only three artifacts, product backlog, sprint backlog, and Product increment. Each artifact contains a commitment to ensure it provides the information that enhances transparency and focused against which progress can be measured. For the product backlog. That commitment is the product goal. For the sprint backlog, ED is the Sprint goal. And for the increment, it is the definition of done. This commitment exist to re-enforce and purism undescribed values for the scrum team and their stakeholders. There are other artifacts, methods, or tools that you might have heard of, but they are not part of Scrum. They are usually used in Scrum as well as in other frameworks. Some of them are bus board burndown chart, definition of ready velocity chart, Release, backlog, release, burndown chart, users.js, story points and more. So if we are going to take the certification exam, make sure to understand that the only artifact required and mentioned by Scrum are the product backlog, sprint backlog, and Product Increment. 38. Scrum artifacts: Product Backlog: Product backlog. You can imagine the product Barry luck, as a wishlist of every sin that is known to be needed in the product. The product owner is responsible for maintaining the product backlog. Only the product owner can change it. The Product Backlog Items has a description, Value Estimation, and they are ordered. Story points are usually used for estimation in Agile. But notice that Scrum does not mention or suggest any technique for estimation value or ordering. The product owner will decide how to measure the value and the order of the Product Backlog Items. The most important items are expected to be on the top. The Scrum team will decide how to estimate, but the development team will make the estimates. The product backlog items on the top are usually more clear and more detailed than the ones on the bottom. More precise estimates are made based on the greater clarity and increased detail. In the example, the estimations are expressed in story points and the product owner is used in the value divided by the estimation as a reference of importance for ordering the items. Product Backlog Items often include text descriptions to validate if it's really finished when it's done, a product backlog is never complete. It evolves as the product and the environment changes. The product backlog is dynamic and constantly changes to identify what the product needs to be appropriate, competitive, and useful as the product is used, the ideas and feedback provided by the marketplace and business are added to the product backlog if a product exists, it Product Backlog also exist. The product backlog items can be features, functions, requirements, enhancement, and fixes to be made to the product in future releases. If there are multiple Scrum teams working on the same product, each development team will have their own sprint backlog, but there will be only one product backlog, N1 Product Owner, the product Verilog is the single source of requirements for any changes to be made to the product. 39. Product Goal - Commitment for the Product Backlog: The product goal is the commitment of the product backlog. The product goal serves as a guidance for the scrum team to plan against a future state of the product that they need to achieve. The product goal is in the product backlog. The rest of the product backlog emerges to define what Ghoul fulfill this product goal. A product is a mean to deliver value. It needs a clear boundary. Well-known stakeholders and well-defined users and customers. A product, a service, a physical product, or even something more abstract like software. The product goal is the long-term objective for the scrum team. There can be only one at a time. They must fulfill their career objective before taking the next one. Or they may abandon the current goal to take a new one. 40. Monitoring Product Goals Progress : Release Burn-down Chart: Monitoring progress towards product goals. At any point in time, the total work remaining to reach a goal can be summed from the items of that goal in the product backlog, This information is made transparent to all stake holders. Various projective practices upon trending husband used to forecast progress like burndown charts, barn ups, cumulative flows. Suppose that the business need to add a new category of products to their webshop and allow to see these products in 3D. This is an example of a burn down chart. This chart shows the remaining work per sprint to achieve a goal, the product owner will sum up the efforts of just the product backlog, items in the product backlog that are necessary to meet that goal. The effort of each product backlog item is measured in story points. The total sum of those Product Backlog Items is 160 Story Points. Because for this team, it is suspected a velocity of getting done 14 story points per sprint with a trend in red, the product owner can forecast that all the items for that goal may be done in four sprints. But the reality is that as soon as the sprints are finished, new ideas and changes are detected with the feedback of customers and added to the product backlog that you can see in the red blocks and with the trend line in blue. Where do you think that this product goal will be achieved? Because we were, are the new items for this goal. In this case, the set of items in the backlog for such goal may be finished in the intersection of both trend lines by sprints six or seven. With this forecast, the product owner can reduce or increase the scope in order to meet a deadline with any increment that is good enough to go live in a target date. The release burndown chart is rarely used for all the product backlog as a whole project. Remember that the backlog is like a big draft, always grows and changes. If a product is used and it is successful, it will be evolved in unchanging for a very long time. This does not replace the importance of empiricism in complex environments. What will happen is unknown. Only what has already happened may be used for forward look in decision-making. 41. Scrum artifacts: Sprint Backlog: Sprint backlog. The sprint backlog consists of a set of product backlog items selected from the product backlog for this sprint to meet the Sprint goal, plus a plan of work needed for delivering them into a done increment. For the spirit of continuous improvement, it may include at least one high priority process improvement identified in the retrospective. The sprint backlog is not a promise, is a forecast by the developers about what functionality will be in the next increment. It makes visible all the work that the developers identify as necessary to meet the Sprint goal. The sprint backlog is a plan with enough detail. That is progress is Vc will and can be understood in the daily scrum. The developers modify the sprint backlog during the sprint. As they learned more about the work needed to achieve the Sprint Goal, details emerge. The developers remove unnecessary work at the New World to the sprint backlog and update the estimated remaining work. The sprint backlog is highly visible real-time picture. The work that the developers plan to accomplish during the sprint. And it belongs to the developers. Scrum does not mention any tools for this, but what you see is a task board, or sometimes called Scrum board. The task board is a simple idea and commonly used by Scrum teams. It contains cards that represent the work and columns with the status of the work. When a car that changes its status, it is moved to the corresponding column. To say that a card is done, it must be aligned with the definition of done. That is a shared understanding of what Dan means for the team. The sprint backlog is composed of the Sprint goal that y, the set of Product Backlog Items selected for this sprint, the Watt, as well as an actionable plan for delivery in day increment. The how 42. Monitoring Sprint Progress: Sprint Burn-down chart: monitoring Sprint progress at any point in time in a sprint, the total work remaining in the spring, Barlow can be some the development team trucks. This total work remaining, at least for every day this crumb to project the livelihood off achieve in the Sprint goal . By tracking the remaining worked throughout the Sprint, the development team can manage its progress. There is no official tool for monitoring the progress, but Sprint burned down charts are commonly used by scrum teams. The Sprint Bardem chart shows the total estimated effort for the total work in the spring backlog in the effort remaining to be done, updated every day off the sprint. In this case, the total effort off the spring bag log is eight. The development team works every day and have some working progress, but nothing is really done. Working progress or partially completed cannot be deducted from the remaining work. Only the effort off brother backlog items that are 100% completed according to the definition of them can be deducted from the remaining work. Work cannot be 90% or 99% done, it is done or it is not done. So the remaining work on Wednesday is still eight. On Thursday, they finish a brother backlog item off. Five points on the remaining work is three point. On Friday, they managed to complete another brother back. Look, I 10 up. Three points on There is no remaining work left. They completed all the work for the increment and achieved this print goal. 43. Scrum artifacts: Increment: Increment. When building a software product, there is usually a layered architecture like this, composed of user interface, business logic, data access layer, and database. If you need to build this software product, how would you start? Many people answer something like our welfare, Sybil, the whole database, then the data layer, business logic. And lastly, they user interface, or sometimes they say it in the opposite order. That is actually a modular development of the whole product. In Scrum. Instead of that, we want to think of vertical slices of functionalities of the product that we can build and make them available to the users. For instance, if we are building an online banking, maybe we start with a login on the ability to just display the account balance. We only build the necessary tables, components, and user interface for those functionalities. We don't build just in case for what is coming next, we just concentrate on these functionalities. In the next sprint, we add the possibility to see transactions and transfer money. In the third sprint, we add password recovery, credit card balance, and contact form. So we weren't producing three increments. Each increment contains the sum of the Product Backlog Items completed in that sprint. And each increment is additive to all prior increments and thoroughly verified, ensuring that all increments work together in order to provide value. They increment must be useable. By the end of the sprint, it is required to provide value with at least one use. I will increment that meets the definition of done of the team. That means that it must be in useable condition, tested, and ready to be released. Whether the product owner decides to really sit or not, multiple increments may be created within a sprint. The sprint review should never be considered again to release in value, it's a common misconception that teams can only deliver value one spares print. The increment is a step toward a vision or product goal. Only developers can create any aspect of a useable increment. 44. Definition of Done - Commitment for the Increment: Definition of Dan. Let me tell you a story. One night, Sophie was cooking for Jo. Jo was very busy playing a computer game. Surfeit says, Honey dinner Israeli, TO stop the game and goes to the living room. When he says the table, he says, there's nothing on the table. The food is not ready. Surfaces. The food is cooked and we can eat it. The food is ready. Please help me. Joe says that is not ready. Surfaces. Shut up. It is ready. So who's right? Well, both from their point of view. For Sophie, ready means that the food is cooked and can be eaten while Joe expected to see a table with the dishes and wine so he can just sit. And it this was a misunderstanding with difference of expectations. They clearly don't have a definition of done. The same thing can happen in your scrum team when a product backlog item or an increment is described as done, everyone must understand what Done means. Is this gag done? It is now done. The definition of dam is an agreement of the team made by the scrum Diem for any product backlog item that ensures that is 100% developed, tested, and ready to be part of the increment. It's a statement that no more work is left to be done on a functionality and it works without errors. 99% done doesn't count the moment a Product Backlog Item meets the definition of done, any increment is born. If the definition of Dan for an increment is part of their conventions, standards, or guidelines of the development organization. All Scrum teams must follow it as a minimum. If there are multiple Scrum teams working on the same system or product release, all the Scrum teams must work together to define the definition of done. Here you can see an example of the definition of dam for a software product. Code must be checked in all unit test must be agreeing and with 90% code coverage, the code must be refactored. The feature is deployed to a QA environment. It is approved by QE. All acceptance criteria are met and it was reviewed and approved by the product owner. The definition of done ensures artifact transparency on guides the development team in assessing the amount of work for each product backlog item, and therefore, how many product backlog items can be selected to be added to the sprint backlog during sprint planning. 45. Create the Definition of Done with a Template: this Is it implied that you can use to define your definition of done. Open the definition of than templates, Earl in the resources printed, or make a copy. Meet with your team, Mark or OG the items that you will like to include in your definition of done. Um, finally, keep it be civil in a wall or in a wiki page where everybody has access, remember, it must be transparent to everyone. 46. Technical debt: Technical depth is caused by choosing an easy and cheap solution. Now, instead of using a better approach that will take longer, it is often the result of using shortcut, quick fixes and patches rather than full-scale solution. Daily caldera was originally used to refer to flaws in the code, the sign of a software, but the concept can be applied to any type of product. In some cases, solutions with technical depth might work fine for a long time, but in many cases the product may become unstable, insecure, or even dangerous. What is the first problem with technical depth regarding productivity? A problem with technical depth is that implies rework. First, we have the time to implement these ISI but undesired solution with technical depth at some point, it might be necessary to implement it, right? So we have to add the time to undo the easy solution on the time to implement it in the right way. That process is also referred as Spain, the technical depth. So as you can see, the total time and effort used is a lot more than that. If we have a boy, the technical depth and implemented it correctly from the beginning. Carrying technical VAB could be intentionally for Bob or good reasons. Just like Guan can take financial depth to gamble in a casino or to make your business grow and pay the depth later with a profit. For instance, lack of professionalism, the team members are unprofessional or they don't care about the product. Accumulated technical depth. The product has so much technical depth that it seems impossible to implement new features correctly. Time pressure, the team is under time pressure, so the speed or released is priority ties over the well-designed the codes, lack of components. The team needs a spare part for the product that is not available and they need an alternative solution. Proof-of-concept experiment or MVP. The team is doing a proof-of-concept or MVP and prefers to deliver something with technical depth to test the demand of the product in the market, rather than building something technically perfect that nobody wants. Technical depth can also be unintentionally. For instance, lack of knowledge. The team members are two junior and they don't know the best practices are the right design patterns for the problems. New technologies, the team is using a new technology or framework and he's not aware of the best practices for it. When a team continuously encourage technical depth without paying it, it might cause several problems. Spaghetti code, they internally sign of the product might become very messy and looked like spaghetti code. And with high coupling, the product may be common, stable, dangerous, or insecure. The code becomes harder and harder to understand and making changes or adding new features require more effort and might easily break or other existing functionalities, whether with a good solution or with more technical depth. Basically, dealing with a cold ways becomes a pain. Hardware to pay. The more technical depth is accumulated. The hardware to pay, it is just like unpaid monetary depth and it's compound interest. Fake perception of high velocity at team constantly encouraging technical depth might look like very productive and with a high velocity for some time because of its quick solutions. But in the long term, the velocity will drop because of the complexity and lack of stability of the codebase. These can also cause addiction by the stakeholders or product owner to see fast deliveries. And Gould make hard duck sat in their future, the high cost of maintenance on fixing box. And furthermore, to accept that the code is garbage and it needs to be a refactor. The metaphor technical depth was originally created by word canning gram to frame how to think about dealing with this craft. To explain to his boss as an analogy to financial depth, the extra effort that it takes to add new features is the interest paid on depth. 47. Scaling Scrum with Nexus: There are many frameworks to work with scram at scale, we will use the Nexus framework as an example of scaling Scrum nexus is a framework built on top of Scrum. It does not modify the Scrum Guide. On the contrary, there are rules of scram fully apply within Nexus. However, Nexus in hands or some accountabilities, events, artifacts, and the rules on top of Scrum. An xs is a group of three to nine Scrum teams working together on the same product. Therefore, it has one product backlog, warm product goal, unwanted product owner for all the Scrum teams. Each Scrum team also has developers on the Scrum Master. The ScrumMaster may work for one or more teams on ISS accountable that the scrum team works according to the scrum guide. During the sprint, the Scrum teams in the Nexus collaborate to resolve dependencies and often integrate their work to deliver at least one integrated increment at the end of the sprint. And integrated increment is the sum of all integrated work completed by an excess. They integrate that increment must meet the definition of done, defined collaboratively by all the Scrum teams. Each Scrum team may have a more stringent definition of done but not less rigorous. The flow starts with the next two sprint planning where the product owner and the appropriate represent that DFS of Scrum teams meet to define the next sprint goal. Sprint goal for each team that is aligned with an extra sprint goal as sprint backlog for each Scrum team on the next sprint backlog, which is a composite of the items from all the sprint backlogs to highlight cross team dependencies during the sprint, appropriate represent that the shapes of each Scrum team meet in an exercise daily scrum to identify integration issues, cross team dependencies, and inspect the progress to the next sprint goal. As a result, the next sprint backlog may be updated. They might define actions for the day to meet the Sprint Goal on each team may discuss some of the issues in their daily scrum. By the end of this sprint, the Nexus on stakeholders meet in an extra sprint review. This event replaces the sprint review of individual teams during the next sprint review, the next sues present day integrated the increments to the stakeholders to receive feedback, discuss that progress to the product goal, collaborate on the next steps and adopt the product backlog. The last event is the next sprint retrospective, where all Scrum teams meet to increase the quality and effectiveness across the next sues by inspecting individuals, teams, interactions, processes, tools under the definition of done, undefined improvements. In addition, each Scrum team also has an individual retrospective, an excess cost, an ongoing activity called cross team refinement. Webrtc bonds of the Scrum teams meet as needed to work on reducing the cross team dependencies, on forecast which team may work on which product backlog item IT Scrum team may also have their own product backlog refinement. Next is add another accountability called the Nexus integration team, whose members are the product owner of the next sues the ScrumMaster on one or more Nexus integration the members, the goal of the Nexus integration team is coaching and guidance Scrum teams to use practices and tools for producing an integrated increment. The next disintegration team must ensure that an integrated increments is delivered per sprint. And it is responsible for ensuring the definition of done for the next source, the Nexus integration team does this by coaching and helping. However, the Scrum teams are the ones responsible for integrating their work often and mutually defined the definition of done. The next is integration. The members are people with the necessary skills and knowledge to help resolve. Next to C shoes, this grandmaster of the Nexus integration team is responsible for the next whose effectiveness and adoption as described in the Nexus guide, the members of the Nexus integration team, males or work on other Scrum teams. However, the membership to the next SSIS Integration team is prioritized over any other team. The next sprint in general, all the Scrum teams in zoos will have their sprints aligned with the sprint of the Nexus. However, this is not required. Each Scrum team can use other spring length on others sprint, start, and end date, as long as the Scrum teams collaborate to integrate their work in at least one integrated increments by the next sprint review, the only requirement is to have at least one integrated increment by the end of this sprint. 48. Next Class: If you enjoyed this class, you can invite a friend unused your referral code to take the advantage Spock referring a friend. Now it's time to continue with your next class. Now you came to denier with release backlog and Product Backlog management in order to maximize the value for, please feel free to take a look at my other classes in my profile. I have a great day and see you in the next class. 49. Thank you and Final thoughts: congratulations. Before I go any further, I want to say again, Congratulations for making your way through the cars. I know you will get great body from my main goal is to help you with the knowledge that you can apply at work become a successful, unprofessional leader. If you have any questions or if you think that something was Mason, please let me know so I can guide you in the right direction or include the topic in discourse or pewter curses. I hope that you enjoy the skirts on. You can recommend it to others. If you like this course, please don't forget to leave a review. You will help me to spread my word. Support me to bring more courses and you will have other people to take the decision off. Joining this class to thank you.