Training for Scrum Master Certifications | Jimmy Mathew | Skillshare

Training for Scrum Master Certifications

Jimmy Mathew, Agile Consultant

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
8 Lessons (1h)
    • 1. Course Introduction

      1:21
    • 2. Scrum Refresher

      7:28
    • 3. Addressing questions from topic Scrum Roles Part 1

      6:07
    • 4. Addressing questions from topic Scrum Roles Part 2

      10:21
    • 5. Addressing questions from topic Scrum Artifacts

      9:06
    • 6. Addressing questions from topic Scrum Events

      17:35
    • 7. Addressing questions from Scrum Basics and Other Topics of Interest

      7:24
    • 8. Outro: Bonus Lecture, our courses in Skillshare

      1:12

About This Class

This course is prepared keeping Scrum .org Professional Scrum Master® I (PSM I®) certification assessment in mind and follows scrum as described in the The Scrum Guide.

This course covers all major topics in scrum framework but the focus is Preparation for Scrum Master Certification Assessments.

  • ***********************************************************************

  • Prepared keeping Scrum .org Professional Scrum Master® I (PSM I®) certification assessment in mind

  • "To the point" training, less duration, more value

  • ***********************************************************************

This includes a session on scrum process in the first module, but this is not a basic scrum training. A basic understanding of scrum framework is recommended. This course focus on major topics in Scrum Master Certifications and discuss how to approach questions from each area.

Topics covered are

Introduction

       Course introduction

       Scrum refresher

Topic 1: Addressing questions from topic - Scrum Roles

       Product Owner

       Scrum Master

       Development Team

       Handling Conflicts

Topic 2: Addressing questions from topic - Scrum Artifacts

       Product Backlog

       Sprint Backlog

       Increment

       Estimation

Topic 3: Addressing questions from topic - Scrum Events

       Scrum Events

       Sprint Planning

       Daily Scrum

       Sprint Review

       Sprint Retrospective

       The Sprint

       Other Meetings

Topic 4: Addressing questions from Scrum Basics and other Topics

       Scrum basics

       Other Topics of Interest

 =======

*Professional Scrum™, Professional Scrum Master™, PSM, PSM I, PSM 1, etc. is the protected brand of Scrum org.

This course is neither endorsed by nor affiliated with Scrum org. This course uses content from the Scrum Guide. All the content related to Scrum Guide is taken from scrumguides org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at http://creativecommons org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons org/licenses/by-sa/4.0/. 

Transcripts

1. Course Introduction: welcome to the course Success tips Training for scrum master's certifications. We are following a different approach in this course. Instead of having an end to end scrum training, we cause and trade on some tips and tactics for passing scrum master assessments. This course covers all major topics in scrubs, but the focus is preparation for scrum master's certification assessments. This includes the session of scrum in the first module, but this is not a basic scrum training this course focus on major topics and scrum master certifications and discuss how to approach questions from each area. We will be proceeding in this order. We will have a quick refresher on the scrum before we start our discussion on scrum certification topics. If you have a good knowledge of scrum, you can skip the next video and move on to the next section. 2. Scrum Refresher: way. Welcome back here. We will have a quick visit of this grown process. If you have a good knowledge of scrum, you can skip this video and move on to the next section. Let's start with Squam Processes. Every software project is intended to convert a number of requirements into a working software. An increment or a change scram follows an intuitive and incremental approach. The work is carried out in multiple iterations called Sprints. Sprint is time box to a maximum of one month. The purpose of the Sprint is to create a potentially ship herbal increments of working software. Before getting into details of this process. Let's discuss different rose to find in scrum. The development team consists of professionals who do the work of delivering a potentially releasable increment of done product. At the end of each sprint, Onley members of the development team create the increment. Development teams are self organizing. They decide how they're going to create a ship herbal increment At the end of the sprint, Development teams are a cross functional. They have all the skills required to convert the selected requirements into done ship herbal increment. The product owner is responsible for maximizing the value of the product resulting from work of the development team. He or she owns the requirement. This activity consists of detail ING backlog items, ordering or prioritizing them to maximize the value and clearly communicating them to the team. He or she also reviews and accepts or rejects the increment produced by the team. The scrum master is a servant leader, a facilitator and coach. The scrum master is responsible for promoting and supporting squirm scrum Masters. Do this by helping everyone understands Crumb theory practices, rules and values. He or she ensures that the scrum is understood and enacted by the team here. She facilitates the scrum events as required scrum masters make sure the impediments for the development team are removed. The product owner, the development team on the Scrum Master together referred as the scrum team Product backlog captures all the requirements needed to be included in the product. This is created and maintained by the product owner. The product backlog is an ordered list of everything that is known to be needed in the product. Sprint starts with a sprint planning meeting. This is time books to eight hours for one month spent for short sprints. It's usually shorter. Product owner explains the product backlog items and set the Priorities Development Team Select items for upcoming sprint based on their capacity team velocity. The size of the work that they have successfully delivered in the last print helps as a guideline while deciding their capacity for the next sprint. Together, the scrum team agree upon the sprint gold in the second part of planning meeting team. Create an initial plan for converting the selected items to ship herbal increment. This may be in the form of technical tasks for each selected item, or maybe only for items to start with the selected backlog items with a plan for achieving it. Make the Sprint Backlog Development Team owns the sprint backlog and keeps it updated throughout the sprint. The development team starts working on the selected backlog items towards creating the increment. To achieve the sprint goal. They do design and development and testing all in the same sprint. They would do whatever required to achieve the sprint goal. Every day the development team does a daily scrum meeting. This is a 15 minutes duration. This takes the form of a stand up meeting where the development team collaborate and decide on actions to be done before next daily scrum. It is kind of a quick daily planning. Normally it takes a form where every member answers three questions. What have I done since last daily scrum for achieving the spring goal? What am I going to do till next daily scrum? Am I seeing any threats for the sprint gold at the end of the spin? The scrum team, the other stakeholders, as invited by the product owner, conduct a Sprint review. This is time books to four hours for one month sprints for short sprints. It is usually shorter. During the Sprint review, the scrum team and stakeholders collaborate about what was done in the Sprint. Based on that and any charges to the product backlog during the sprint, attendees collaborate on the next things that could be done. This is an informal meeting, not a status meeting, and the presentation of the increment is intended to elicit feedback and foster collaboration. The Sprint retrospective. It's an opportunity for the scrum team to inspect itself and create a plan for improvements to be enacted during the next print. This is time books to three hours for one month sprints. For shorter sprints, it is usually shorter. There are different methods used for retrospectives. For example, team may try to find out what went well, what didn't go well, and what are the areas of improvement. Both Sprint Review and Sprint retrospective may have outcome that impact the next sprint planning a new sprint starts immediately after the previous sprint ends. There is no gap in between. Scrum teams conduct sprints one after another, creating software increments in an intuitive and incremental way. As mentioned before the development team create, tested and ship herbal increments at the end of each sprint, it may get deployed as it ISS or wait for further increments. However, the development team will keep on producing ship herbal increments as we've already seen. There are rose ceremonies and artifacts prescribed by scrum. The roles are the product owner, the development team and the scrum master. The ceremonies are Sprint Planning, Daily Scrums, Sprint reviewing and Sprint retrospectives. The artifacts are the product backlog, The sprint backlog on the product increment. Okay, 3. Addressing questions from topic Scrum Roles Part 1: scrum roles are amongst the most visited areas in any scrum master sort of occasion assessments. We can consider it as a favorite area for any examiner. Scrum defines three rolls The Development Team, the product owner on the scrum master Together they're called this groom team, that is the scrum team consists of the product owner Development team and the scrum master rolls. The fine by scrum and members in the scrum team are topics for direct questions. Basic points that we should remember while answering. These are the perfect owner owns the requirements. The development team owns the work within the Sprint and the scrum Master as a servant leader. Take care of the scrum processes. There will be many basic direct questions on product owner responsibilities. The primary responsibilities of the product owner are owns the requirements that is, the product owner creates and maintains the requirements. He is responsible for creating and maintaining the product backlog. He has the final decision on the content and order of the product backlog items product owner accept or reject the increment created by the development team. In short, we can say that the Putt owner owns the content on the order. Other two key phrases frequently found in the questions related the product owner role are business directions and maximize the value. The product owner represents the business, and it's the single source of requirements for the development team. He or she best understands the business and gives the business direction to the team. He or she makes sure that the team is working on the items most valuable to the end user. How does the product owner carry out these activities? This could be another question. As we have already seen the product on a create and maintains the product backlog, his or her decisions on the business priorities and values are visible in the content and order off the product backlog items. Many times, questions will be on some decisions. It will ask, like who owns a particular decision? Let's see some decisions that the product owner owns. As we've already mentioned, the product owner decides the content and order of the product backlog items. Product owner decides the time for the production of release the development team keep creating increments, but when to release them to the production is a decision from the product owner. It may get released as it is or wait for further increments. Another point to be noted here. Yes, it is not mandatory to release the increment to the production at the end of every sprint. This is a very common question. In the case of any conflict regarding the content or order of product backlog, the final decision will be from the product owner. For such questions, look for an option where the product owner takes the final decision. Only product owner has the authority to cancel a sprint. Read this again. Onley product owner has Theo authority to cancel a Sprint. Questions may try to confuse us with other roles. Taking this decision, we should stick to this role. Other roles can influence the product owner decisions. I repeat. Other roles can influence the product owner decisions, but the final decision is with the product owner for a product on it to be successful, everyone in the organization must respect his or her decisions. Other responsibilities that I'm not been discussed so far. Product owner is responsible to make sure the backlog is visible, transparent and clear. To all required. He or she creates projections based on the current state of the product backlog, he or she should be able to predict the likely completion date based on what is so far known he or she accepts or rejects the work done by the development team. Another golden rule for the assessment is one product, one product backlog. One product owner. You might have seen variations to this role, but for a scrum master assessment, stick to this rule. One product will have a single product back. All teams working on that product will share the same product backlog. A product backlog will be owned by a single product owner. There are two aspects where we may go wrong or may have wrong assumptions. Let's have a look before we close this discussion. We have seen that the put up owner owns the product backlog, but the point to be noted down here, product on A doesn't own the estimates. Product owner is responsible for the availability, transparency, content or clarity, etcetera. But the estimates are owned by those who do the work. This is the development team, another point. The product owner gives the business direction Here, she says the priorities and explains what he expects in the increment sold ing out of the sprint. But how many items to be included in the sprint is a decision from the Development team Development Team forecasts their capacity for the upcoming sprint and decide how much work they can take up in the sprint. 4. Addressing questions from topic Scrum Roles Part 2: Let's continue our discussion on SCRUM wrote. The next role is the development team Onley Development Team members create the product increment. This summarizes all that we should remember while answering the questions about the development team. They are responsible for all the work towards creating the increment or, in other words, responsible for all the work required to convert the selected product backlog items to a working, done ship. Herbal software increment. This includes everything the sign architecture coding, all the levels of testing, build, integration, deployment, automation, etcetera. There are specific questions on any of these work items. The answer is the same. The development team is responsible. Three of widely used phrases are self organizing, self managing and cross functional. Self managed means they organized managed their work without being directed by someone outside the team. They decide as a team how to work towards the spring goal. Be careful here. This doesn't mean that they shut their doors. They will get imports from an influenced by other roles, but they own the decision on the way to carry out the required work. They're responsible to resolve any challenges on their way. They are self managed. They are themselves responsible for solving any internal issues. Conflicts within the team. This may sound different from some of us, but for the assessment, keep in mind that the development team is self managing. They're cross functional. There will be questions on the structure composition of the development team. There may be options like has programmers, testers, analysts etcetera. To confuse us, look for an option that says or means similar to all skills required to convert the selected product backlog items to a done ship. Herbal increment. Same applies If asked about the amount of work required in the sprint, we should do as much is required to convert the selected items to a done Schapelle increment. Continuing with the team composition, let's see what will be an ideal size of the development team. If the assessment is based on scrum guide, the answer will be 3 to 9 members. There are organizations that propose seven plus or minus two as an ideal size. Usually this comes as a direct question. More members will increase the complexity and brings in coordination issues. Less may lead to skill constraints. There were no titles within the development team pool. Our development team members. This awareness may be tested in an indirect way. Can we change the team membership? Yes, we can, but there will be a temporary impact on the team performance in productivity. This is because the team has to regroup to accommodate the changes. The development team collectively owns the work. There will be team members working on specific product back look items, but the ownership accountability remains with the entire team. So look for the key word accountability or ownership. An individual member never becomes absolute. Owner of the backlog items be very clear on this concept of collective ownership. The development team decides how to carry out the work within the sprint. They decide how many items can be included in the Sprint product. Owner tells the priorities, but Development team decides the capacity for the Sprint product owner and development team can negotiate on this. But decisions is with the Development Team Development Team create and maintains any ground votes required. It can be a coding standard or unexpected social behaviour etcetera Development team own sprint backlog. They are responsible for creating and maintaining the Sprint backlog product on a track and forecast the likely completion dates for the product development, but within the sprint, the development team best knows their progress towards spring goal. They tracked the progress within the Sprint most of these cases. This appears as a direct question. Product owner is responsible for creating and maintaining the product backlog, but development team can get involved in this activity, but not with more than 10% of their time. Last two points Scrum prefers feature teams on competent teams. Feature teams work across layers incompetents, creating a capability or feature scrum prefers school located team. This brings in an effective communication, faster decisions, better coordination and more trust. Let's discuss the next roll the scrum master keywords that describe this grandmaster roll our facilitator, servant, leader, coach, protector, etcetera, scrum master Make sure that this crumbs understood and enacted by the scrum team scrum master facilitates scrum events as required. Other points can be he or she coaches the team on time boxing. He or she coaches the team on self organizing, so scrum master has a coaching role to play while attending Westerns on impediments. We must clearly understand if it is an internal technical issue or on impediment that spreads outside the team boundaries team is self managing once it escalates or has reached outside team boundaries. Scrum master will get involved and facilitate the resolution for all impediments. The scrum master has to roll to track them and facilitate the resolution if the product owner becomes or creating an impediment the scrum master musket into his coaching shoes. He or she protects the team from external interference that blocks their progress towards achieving the sprint gold. The scrum master helps the product owner in finding techniques for product backlog of management. Scrum Master helps the team in Maine maintaining required levels of transparency. Scrum master role in daily scrum is a much discussed item in assessments. Scrum master makes sure that this event happens effectively and teaches the development team the art of time boxing but he or she is not a participant in this event. Daily Scram is on Lee for the development team. They are the only participants off the daily scrum. Should scrum master be a technical person? Not necessarily. Technical skills may help sometimes, but it's not mandatory unless he or she is a member of development team. So one more point a scrum master can be a development team member. Scrum master has responsibilities to the organization as well. He or she will contribute in leading coaching planning scrum implementations in the organization. But remember, the primary responsibility is to the scrum team. Now let's discuss some conflict situations and the roles involved. There will be many questions on resolving conflicts within and outside the scrum team. We should answer based on its origin. We will discuss a few categories. Product owner owns the requirements and it's a single source of requirement for the development team. No one else can ask the team to work on a different set of requirements. Any such requests, if they arise, must be directed towards the product owner requirement. Conflicts can take many forms. They may be to stakeholders with conflicting views or a single functionality. The development team may have a different understanding over requirement. Some influential role in the organization may be forcing the development team toe work on a different set of requirements. There will be a conflict of interest among stakeholders on the order off product back load items in all these scenarios. The answer The responsible. The decision maker is the product owner there may be disagreements or conflicting perceptions within the development team regarding the requirements the self managing development team and must address it to the product owner and get it clarified. They can be other conflicts personal or technical within the development team. Remember the key concept or self managing teams? The development team must first solve these and keep going. The scrum master coaches the development team in self organizing. So for such questions, the first choice, maybe the development team resolves within themselves. But be very careful here. This may be something which went out of the development teams control or item that involves external parties. In these cases, the scrum master may step in if product owner becomes an impediment. Scrum master steps in coaches. Three expected scrum values Every conflict is different. We can't go with a single formula in this. Based on the above ground rules, we must analyse the situation and take a cool 5. Addressing questions from topic Scrum Artifacts: Let's move on to the next topic way will see different artifact in scrum. Scram. Guy talks about three artifacts. The product backlog. The Sprint backlog on the product increment. The product backlog is an order list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Sprint backlog is the selected product Battle of items for the Sprint, and I have a plan for delivering them. The increment is the sum of all the product backlog items completed during a sprint on the value of the increments of all previous prints. First, we will discuss a few points on the product backlog. The product backlog is an ordered list of everything that is known to be needed in the product. It contains functional nonfunctional or anything that is required for the product, as mentioned earlier in this course, the product owner owns this artifact. The product owner is responsible for the product backlog, including is content availability and ordering a few useful points for the assessments are this is a live artifact at any point of time, new items can be added to the list. This can grow in size. A product backlog is never complete. It exists and gets updated as long as the product exists. Product back low items have the attributes of a description, order, estimate and value, as mentioned in the last module with the development team is responsible for the estimate. There will be indirect questions on the ownership of these estimates. Remember the rule. Those who are doing the work decides the estimate. Here it is. The development team product owner is responsible for the product backlog, but the development team can get involved in the backlog refinement activities utilizing not more than 10% of their time. It is a common practice to create product backlog items in the form of use her stories. But remember, this is not mandated by scrum. It is widely used format and it works well. But Scrum doesn't restrict the use of other formats, whichever be the format used. Product owner must make sure that it is well understood by all required parties. Another area to be focused on its multi team environments where more than one scrum team is involved in the development of a product. Remember the Golden Rule One product has one product backlog owned by a single product owner, but there will be multiple sprint backlogs, one for each team. Product backlog is an order list. Then what should be the technique used for ordering? There will be many options, including well known prioritization technique. But remember, scrum is a framework within which we can deploy different techniques. Scrum itself doesn't specify any techniques, so this ordering will be a product. Owners discretion. Look for an answer that tells the ordering is done. Whatever way deemed to be appropriate by the product owner, we will move on to the next artifact. The Sprint backlog. The Sprint backlog is the selected product backlog items for the Sprint and a plan for delivering them in some questions to Sprint Back low, maybe referred as a forecast from the development team on the expected functionality from the Sprint. This may take the form of engineering tasks for each selected product backlog item. But remember, this is not a strict rule development team own Sprint backlog and have the complete authority on this. They decide on the format for this artifact. There will be questions on the ownership and updating of this artifact. The answer is development team. No one else updates to Sprint backlog. Another point is that the Sprint backlog and need not be completely formed by the end of the Sprint planning. Detailed task level planning may be done on Lee with a few items to start with. This is expected. This is a live artifact. Tasks can be added or removed at any point of time, so at times please listen carefully at times this and grow in size. This is an important concept for the assessment. As the work start, more knowledge will be available on team will identify new tasks. They may remove a few as well in the assessment. Sprint backlog may also be referred as a document used by the development team to track the progress within the Sprint at any point of time. The total remaining effort and the Sprint Back log shows the amount of identified work remains in the Sprint. Please note the keyword identified work means this is based on what is known so far, not a frozen absolute value. When there are multiple teams in the same product. One product, one product backlog and a single product honor, but there will be separate sprint backlogs for each team. Scram. Teams may be maintaining many other documents. Those may add value to their work. But remember, these are the only two backlogs mandated by scrum. The next artifact is the increment. We will start with the increment. The definition itself demands our attention. The increment is the sum off all the product backlog items completed during a sprint and the value of the increments of all previous prints. Please note it is not just the output from the last print. It is the accumulated some of product backlog items completed during a sprint on the value of the increments of previous prints. Many of the questions on increment will be around. The concept of done. An increment must be done. It must be completed in all aspects and very for deployment in production. But it may not get released to production. Every sprint. The time of release will be a decision by the product owner. It may not get released or may wait for more sprints, but every sprint produces a readily ship herbal increment. No additional development or testing is required on it to make it ready for deployment. Now let's discuss a few points of estimation. Estimations can be part of who referred to in many questions. Two of the main points to remember here are estimates can change as more knowledge is available and people who do the work. The development team is responsible for all estimates. Relative estimation may not be a direct question, but a basic knowledge will be helpful. Related estimation consists of estimating something not separately and not in absolute units but by comparison with one another. It is also done by grouping of items of equivalent size. In short, estimation is done in relative way in comparison with one another T shirt sizing in story points or two example of relative estimation. It is very important to remember that Scrum doesn't give any specific techniques. Story pointing is a widely used estimation method, but it is never mentioned. Ass of recommended Method Scrum Team decided the tools and techniques Scrum teams are using different burned down charts at different levels. A sprint burned down chart shows the total identified work remaining in the sprint against Day in the sprint. These air not prescribed constructs but maybe referred as a part of other questions. Keep this in mind. A temporary burn up is possible in a burned down chart because now items can be added to the sprint or product backlogs at any point of time. Velocity is a number of story points done by the development team in a Sprint turn. Velocity may not be directly referred in questions, but it will be referred as the past performance of the development team. This is useful in deciding the number of backlog items, amount of work that can be taken up in the next sprint. This performance can be used to compare across prints for the same team, not for comparing the performance of different teams. 6. Addressing questions from topic Scrum Events: Let's move on to the next topic. We will discuss different events define in this groom. Scram Mandate four events. Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. This list itself could be a question scrum Guide refers to a backlog refinement, but this is not a formal or a mandatory or prescribed event. Backlog. Refinement is an ongoing activity, not a prescribed event. Time books for each event is important for daily scrimmages fixed as 50 minutes irrespective of the sprint length. Time boxes for other three events can vary based on the sprint duration for one month sprint time. Books for the Sprint planning is eight hours Sprint Review. Four hours and retrospective three hours. This could be shorter for shortest prints in daily scrum. Onley Development Team participates in Sprint planning and Sprint retrospective. The scrum team participates. Sprint Review. It's an event where the people outside the scrum team actively participate. The participants for Sprint Review includes scrum team and other stakeholders as invited by the product owner. All four events are mandatory and should not be avoided under any conditions. Questions may percent Many situations, types of products, team structure, irrespective of Elise Hu for prescribed events are mandatory. Exclusion of any of these events will have an impact on transparency and reduce opportunity to inspect and adapt. Let's read the above sentence again. Exclusion off any of these events will have an impact on transparency and reduces opportunity to inspect and adapt. We should maintain proper sequence. A swell sprint will start with a sprint planning. There will be daily scrum every day. End of this friend. We would do a review and Sprint retrospective happens after this. Bring review before next. Sprint. Planning the difference between review and retrospective, maybe straight and simple, but an important topic. The Sprint Review focuses on the product. The retrospective focuses on the development process. We will discuss these events in detail. We will start with the Sprint Planning. Sprint is planned as a collaborate effort off the entire scrum team. During the spring planning scrum team participates and the time boxes eight hours for one month. Sprint for short is prints. This could be shorter. The questions that are answered by this meeting are what can be delivered as part of the increment resulting from the next print and how can it be delivered product owner explains his expectations from the upcoming sprint that IHS gives the business priorities and explains the product backlog items which he thinks will achieve this expectation. But I repeat, the development team decides how many items can be included in the sprint. Their capacity for the sprint and past performance will guide the development team in selecting the number of items. The correct owner can clarify the items and negotiate the scope with the development team, but the decision on the number of items that can be included is with the development team. During Sprint planning, the scrum team also crafts a sprint gold. The sprint goal is on objective that will be met within the sprint throughout the implementation of the selective product backlog items, and it provides guidance to the development team on why it is building the increment Definition of spring goal is an important topic. Another key characteristic is that the Sprint Gold gives some flexibility for the development team while defining the scope and while creating the increment. In other words, scope of work can be re negotiated without endangering the Sprint Gold Spring Gold Guys, the development team during the sprint. These features of Sprint gold often figure in multi select. Select the correct statement type of question. In the second part, the development team decide how to aspect how to work as a self organizing team and convert the selected backlog items to a ship. Herbal increments. During this process, new knowledge findings issues may come up and the development team can re negotiate the scope with the product owner. The selected back look items plus a plan for achieving it makes the sprint backlog. This is not completed. The development team will keep updating the sprint backlog throughout. The Sprint Development Team collectively owns items in the sprint backlog. Accountability for an individual backlog item is no fixed with a particular team member. Please note scope and sprint backlogs are not frozen and can be re negotiated with the product owner. But there is something face and that is the sprint gold. We will move on to daily scrum daily scrum daily, stand up or simply referred us daily is a 50 minute time boxed event where the development team members collaborate on plan their activities for the next 24 hours. Important points. The time box is 50 minutes and the participants are only development team members. The scrum master. Make sure that the events happen and the participants understand it's purpose but doesn't participate. There could be many questions like What is the role of product owner, scrum master or senior management in the daily scrum? The answer is straight and simple. They're not participants. It is time box to 50 minutes. Unlike other events, this will not change. Based on sprint length, there will be questions on the time box for daily scrum based on the sprinkler length team size etcetera. The answer remains the same 50 minute it is recommended that daily should happen at the same place same time. This reduces complexity and make it more predictive. This formal event reduces the need for many other meetings. Please note it reduces, not removes. There can be meetings other than those prescribed in this Graham guide, a widely used format also referred. A scrum guide is off three questions. Every team member answered the same three questions. What did I do yesterday to help the development team meet the sprint goal? What will I do today to help the development team meet the sprint gold? Do I see any impediment that prevents me or the development team from meeting the sprint goal. Remember, this format is not mandatory. The development team can decide what works best for them. Development teams assess their progress towards the sprint goal. Daily Scrum. Make sure that this happens at least once a day means this is not the only occasion where the progress is assessed. Main points to remember our this is an inspect and an adaptive int development team track their progress in this. This improves communication Focus is on the product towards achieving the sprint goal and the outcome will be a plan for the next 24 hours. Lengthy discussions or technical problem solving must be avoided in this meeting if needed . The required members can regroup after the daily scrum for this purpose. Now let's discuss Sprint Review. A Sprint review is held at the end of this print to inspect increment and the depth of product backlog if needed. During the Sprint review, the scrum team and stakeholders collaborate about what was done in the Sprint. Based on that and any other changes to the product backlog. During the sprint, attendees collaborate on the next thing that could be done to optimize value. What is given here is the statement taken from scrum guide. Every sentence is important and usually figure as a part of question or answer options. Time Box is four hours for one month sprint and can be lesser for shorter sprints. Participants are the scrum team and stakeholders as invited by the product owner. Please note this is the only event where people outside the scrum team is actively participating. Another frequently use statement is on the product demo, which is part of this print review. The presentation of the increment is intended to elicit feedback and foster collaboration. Also, remember the actual working software is presented, not the screenshots or presentation slides. The product owner explains the product backlog as it stands and make predictions unlikely. Completion date based on what is known. Other points discussed can be review of the timeline budget, potential capabilities and marketplace for the next anticipated release or functionality or capability of the product. The result of the Sprint Review. It's a revised product backlog that defines the probable product backlog items for the next sprint. Remember for the exam. This is unexpected and a deft event. This gives an opportunity to get feedback from a larger audience. But this is not the only opportunity for the product owner to get stakeholder feedback. There will be constant interactions throughout the product oration. The sequence and timing for this event is equally important. Decisions from Sprint Reviews will impact Next Sprint Planning This may uncover some areas that need to be discussed as part of the Sprint retrospective, so the Sprint Review should happen at the end of the sprint before the Sprint retrospective . Next, it's the Sprint retrospective. The Sprint retrospective is an opportunity for the scrum team to inspect itself and create a plan for improvements to be enacted during the next print. Well, the Sprint Review focuses on the product. The retrospective focuses on the development process. This different itself can be a direct question. Time boxes three hours for one month sprint and can be lesser for short sprints. The entire scrum team participates. The product owner participates from the responsibilities as part of scrum team. The scrum master ensures that the meeting is positive and productive. The scrum Master teacher. So to keep it within the time books, the scrum master participates as appear team member in the meeting. From the accountability over the scrum process above statements are important as the rows of product owner and scrum master in retrospective are frequently visited areas. This is another inspect and adapt opportunity format for this meeting is decided by the scrum team. Teams may discuss what went well what not an areas to improve. They may inspect and adjust the definition of done. Scrum team inspects how the last print went with regards to the people relationship process and tools. They come out with a plan for identified improvements. Results of this event or action items from this have impact on the next print planning and the way the team continues its work. So this has to be conducted in proper sequence. This is after this print review before the next spring planning. Remember, this is not the only occasion for inspect and adapt but retrospective. Make sure this happens at least once in every sprint. Let's discuss a few points regarding the sprint. The sprint itself can be considered asked the longest event in scrum. It is a maximum of one month duration where a potentially shift herbal increment is produced This is an important point. Intention of every Sprint is to produce a done incremental product, which is ready to deploy when to release it. It's a decision from the product owner. There are many considerations in deciding the sprint length, the duration, that the requirements can remain unchanged short enough to reduce risk long enough to create usable increment. Whatever the considerations, it will be one month or less. Always prefer a short duration. What can we do during the time between two sprints? The answer is, there is not time or gap between two sprints. A new sprint starts immediately after the end of the previous sprint. When will the sprint end? The answer is simple, straight and non negotiable. A sprint ends on the time books expires. There will be many options that sound logical but don't get carried away. Sprint ends when time books expires. There is only one type of sprint, the one with the aim of producing a done ship herbal increment. There are no special types of sprints there, nothing colds, pardoning, sprint to science, print or release sprint. A few of these, maybe existing in our organization, but forget it for the time being. In short, there are no sprints with those fancy names. Is the increment only output from Sprint? It depends on the definition of done followed for the sprint. If mandated by the definition of done, there could be other items like review records, legal documents, training materials, etcetera. A sprint can be canceled. Only product owner has the authority to counts of the sprint. This can happen when the sprint gold becomes obsolete. What will happen to the selected backlog items when a sprint gets canceled when a sprint is canceled, the items that are done can be reviewed and accepted by the product owner. If it is useful, rest of the items will be re estimated and put back in the product backlog. The same actions apply when the development team is unable to finish the sprint scope. The items that are done will be reviewed by their product owner and accepted. If it issues full for the product, rest of the items will be re estimated and put back in the product backlog. In both cases, please note the items are not directly moved to the next sprint. Can there be meetings other than the prescribed ones. Yes, there are prescribed events reduced need for other meetings but doesn't eliminate them. There can be other meetings. Scrum doesn't specify any time books for such meetings. For activities it may take, a much time is required without introducing any waste in the process. One such activity is product backlog refinement. Product backlog. Refinement is the act of adding detail estimates on orderto items in the product backlog. This is an ongoing activity and can occur any time during the product's existence. The part owner is responsible and scrum master can help in facilitating IT. Development team can spend a maximum of 10% of their time on this activity. 7. Addressing questions from Scrum Basics and Other Topics of Interest: welcome to this module here. We will discuss scrum basics on a few other topics. Scrum is based on empirical process control theory. There could be direct questions on this. Remember three pillars of empirical process control transparency inspection on adoption. Another point to remember is as empiricism knowledge comes from experience and decisions are made based on what is known. Scrum maintains high levels of transparency scrum events, artifact and rolls enables this inspection ca NBI during any time. Throughout the lifecycle scrum teams inspect frequently, but this should not be too frequent to create blockers in their work. Once a deviation is found, the corrective measures must be put in place at the earliest moment to avoid further deviation. Definition of scrum as given by scrum guide is a good point to remember scrums, a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value. Remember scrum missive framework, not a process technique or definitive method. Rather, it is a framework within which you can employ various processes and techniques. We can apply different techniques or tools within this framework, a scrum guide says. Scrum rose events artifact and rules are immutable. And although implementing Onley parts of scram is possible, the result is not scrum scrum exists only in its entirety and functions well as a container for other techniques. Methodologies onda practices A few benefits of scrum can be listed as follows accelerate time to market increased product transparency, address evolving requirements, improve collaboration and reduced risk in the product development. Scrum inherently reduces risk in the product development by short delivery cycles, early testing and early customer feedback. High visibility early risk identification. How planning is done in scrum is a hot topic as there is misconception that there is no or less planning in agile. We do plan is Graham but we do enough planning at different levels. We have an overall high level plan for a long duration and just in time J. I t planning in inspirations, we have a release plan Sprint plan and Daily planning happens as part of daily scrum planning. Is Graham is adaptive. Plans are flexible enough to accommodate changes. Story planning is participatory. The team is empowered and participate in planning. It is not command and control. It is not the product manager makes the plan for the team scrum guide has introduced five values, commitment, courage, focus, openness and respect. There will be scenarios where we should find the value exhibited by the team or that is missing in the team. For the first, we must remember these five values scram guide states. People personally commit to achieving the goal of the scrum team. The scrum team members have courage to do the right thing and work on through problems. Everyone focuses on the work of the sprint and the goals of this crime team. The scrum team and its stakeholders agree to be open about all of the work and the challenges with performing the work. Scrum team members respect each other to be capable independent people. Let's review a few more topics. There is no rule called project manager in scrum, but it may exist at other levels in the organization. Support from management is very important and in the success of scrum, the role of management will be supporting and empowering the scrum team to be a successful self managed entity. There will be in question on how design and architecture are handled in scrum. Remember the key statement, design and architecture evolves asked the development progresses. We start with a minimum required to sign, which is extensible Andi. Keep improving it. Every development team member should follow. The architectural guidelines agreed by a development team in each sprint improved the architecture as needed for the features planned in the sprint. There is no special sprint dedicated for the sign in architecture activities. Also, these activities are not done Onley in one sprint. It is an ongoing process. Development team is responsible for design and architecture. Definition of done D o. D is used to excess. If all work required is done on the product increment, it is defined by the development team and is in agreement with the product owner. So the development team should do as much work on the increment as defined in the definition of done. Please keep these points in mind. This can be defined for backlog item Sprint on release. This brings in more transparency, a shared understanding of what is meant by the term done. This guy's the team doings, print planning, helping them in evaluating the amount of work required. Two of main sub topics. Our definition of done at organization level and multiple teams working on the same product . If a definition of done exists in the organization, the team should follow it as a minimum and add product specific items to it. If not, the development team can create the definition of done in agreement with the product owner . What if multiple teams are working on the same product? The focus will be integration and all teams must collaborate and come up with the definition of done that makes their integrated increment ready to ship or done all aspect Known. Functional requirements are handled in many ways by scrum teams. One method is to add it to the definition of done. This makes sure that every increment satisfies these requirements. 8. Outro: Bonus Lecture, our courses in Skillshare: we would like to provide an overview of our courses on agile and scrum.