Training for Scrum Master Certifications | Jimmy Mathew | Skillshare

Training for Scrum Master Certifications

Jimmy Mathew, Agile Consultant

Training for Scrum Master Certifications

Jimmy Mathew, Agile Consultant

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

    • 2. Scrum Refresher

    • 3. Addressing questions from topic Scrum Roles Part 1

    • 4. Addressing questions from topic Scrum Roles Part 2

    • 5. Addressing questions from topic Scrum Artifacts

    • 6. Addressing questions from topic Scrum Events

    • 7. Addressing questions from Scrum Basics and Other Topics

    • 8. Outro Our Courses in SkillShare

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





About This Class

*Updated as per the latest Scrum Guide, Nov 2020. We have updated the course content as per the changes made in the latest version of the scrum Guide(TM)

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


       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



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

Meet Your Teacher

Teacher Profile Image

Jimmy Mathew

Agile Consultant


Around 15 years in IT, 7 years of Agile experience, playing various roles of Agile Coach, Scrum Master, Trainer, etc.


Book: - Scrum Tales: Stories from a Scrum Master's Diary  

Book: - Agile Life: Understanding agile in a non-software context  



.      ICP-ACC - ICP Agile Coaching   

·      CSP – Certified Scrum Professional  

·      CSM – Certified Scrum Master  

·      SAFe - Scaled Agile Framework-Agilist  

·      PSM1 – Professional Scrum Master  

... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

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

Your creative journey starts here.

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

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

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



1. Course Introduction: Welcome to the course. We are following a different approach in this course. Instead of having an end to end Graham Training, we concentrate on some tips and tactics for passing Scrum Master assessment in this course covers all major topics in Scratch, but the focus is preparation for Scrum Master Certification assessments. This includes a session of Scrum in the first module. This is not a basic SCRUM training. This course focused on major topics in Scrum Masters 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: Welcome back. Here we will have a quick visit of the Scrum 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 Scrum processes. Every software projects is intended to convert a number of requirements into a working software. An increment or a change. Scrum follows an iterative and incremental approach. The work is carried out in multiple iterations. Code sprint. Sprint is time-boxed to a maximum of one month. The purpose of the spring is to create potentially shippable increments of working software. Before getting into details of this process, let's discuss different roles defined in Scrum. Consists of professionals who do the work of delivering a potentially releasable increment of done product. At the end of each sprint. They'd create the increment. They'd ourself organizing. They decide how they're going to create a shippable increment at the end of the sprint. They are cross-functional. They have all the skills required to convert the selected requirements into w1 shippable increment. The Product Owner is responsible for maximizing the value of the product resulting from work of the lepers. He or she owns the requirement. This activity consists of detailing 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 a coach. The Scrum Master is responsible for promoting and supporting Scrum. Scrum Masters do this by helping everyone understands Graham theory, practices, rules, and values. He or she insures that the Scrum is understood and enacted by the team. He or she facilitates the scrum events as required. Scrum Masters, make sure the impediments for the development are removed. The product owner and 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 the sprint planning meeting. This is time-boxed to eight hours for one month, sprint. For shorter sprints, it's usually shorter. Product Owner explains the Product Backlog Items and set the priorities. We will select items for upcoming sprint based on their capacity, team velocity, the size of the work that they've successfully delivered in the last sprint helps as a guideline while deciding their capacity for the next sprint. Together, The Scrum Team agree upon the Sprint goal. Team create an initial plan for converting the selected items to shippable increment. This may be in the form of technical tasks for each selected item, or maybe only for items to start with. The Sprint goal, with the selected backlog items, with a plan for achieving it. Make the sprint backlog, owns the sprint backlog and keeps it updated throughout the sprint. 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 will do whatever required to achieve the Sprint goal. Every day. Gorilla does a daily scrum meeting. This is a 15 minutes duration. This takes the form of a stand up meeting where the 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 Sprint goal? What am I going to do till next Daily Scrum? Am I seeing any threads for the Sprint goal? At the end of the sprint, the scrum team, the other stakeholders, as Invited by the product owner, conduct a sprint review. This is timebox to four hours for one month sprints. For shorter 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 retrospectives as an opportunity for the scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint. Time box, 23 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 iterative and incremental way. As mentioned before, we will create tested and shippable increments. At the end of each sprint. It may get deployed as it is, or wait for further increments. However, team will keep on producing shippable increments. As we've already seen, there are rows, ceremonies, and artifacts prescribed by Scrum. The rows are the product owner and the Scrum Master. The ceremonies are Sprint Planning, Daily Scrum Sprint Review, and Sprint Retrospectives. The artifacts are the product backlog, the sprint backlog, and The Product increment. 3. Addressing questions from topic Scrum Roles Part 1: Scrum roles are amongst the most visited areas in any Scrum Master Certification assessments. We can consider it as a favorite area for any examiner. Scrum defines three roles. They will abuse the product owner and the Scrum Master. Together, they are called the scrum team. That is, the Scrum Team consists of the product owner and the Scrum Master. Roles defined by Scrum and members in the scrum team. Our topics for direct questions. Basic points that we should remember while answering. These are the product owner owns the requirements we will abuse, 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 our 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 accepts or rejects the increment created by the team. In short, we can say that the product owner owns the content and the order. Other two key phrases frequently found in the questions related to the product owner role are business directions and maximize the value. The product owner represents the business and is the single source of requirements for the 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 can be another question. As we have already seen, the product owner creates and maintains the Product Backlog, his or her decisions on the business priorities and values are visible in the content and order of 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 and release. 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 increment. Another point to be noted here is 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. Only product owner has the authority to cancel a sprint. Questions may try to confuse us with other rows. 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 owner to be successful, everyone in the organization must respect his or her decisions. Other responsibilities that have not been discussed so far are 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 team. And other Golden Rule for the assessment is one product, one product backlog. You might have seen variations to this row. But for a scrum master assessment, stick to this rule. One product will have a single product backlog. All teams working on that product will share the same product backlog. 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 product 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, word clarity, et cetera. But the estimates are owned by those who do the work. Another point, the product owner gives the business direction, he or she sets the priorities and explains what he expects in the increment resulting out of the sprint. But how many items to be included in the sprint is a decision from the developed. They will abuse forecasts and their capacity for the upcoming sprint and decide how much work they can take up in the spring. 4. Addressing questions from topic Scrum Roles Part 2: Let's continue our discussion on Scrum roles. And next role is the only way the Product Increment. 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 shippable software increment. This includes everything, design, architecture, coding, all the levels of testing, build, integration, deployment, automation, et cetera. There are specific questions on any of these work items. The answer is the same. We will abuse is responsible. Three of widely used phrases are self-organizing, self-managing, and cross-functional. Self-managed means they organize, manage their work without being directed by someone outside the team. They decide as a team how to work towards the Sprint goal. Be careful here. This doesn't mean that they shut their doors. They will get inputs from an influenced by other roles, but they own the decision on the way to carry out the required work. They are 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 team is self-managing. They are cross-functional. There will be questions on the structure or composition of the team. There may be options like has programmers, testers, analysts, et cetera. 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 shippable increment. Same applies if asked about the amount of work required in the spring. We should do as much as required to convert the selected items to a done shippable increment. Continuing with a team conversation, let's see what will be an ideal size. If the assessment is based on Scrum guide, those groan girds, those grounding is marginal to remain nimble. Do not do significant work. We really do bigamy Jen, old fueled bubble. There are organizations that proposed 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 scale constraints. Can we changed the team membership? Yes, we can. But there will be a temporary impact on the team performance and productivity. This is because the team has to regroup to accommodate the changes. They will abuse electively, owns the work. There will be team members working on specific product backlog items, but the ownership, accountability remains with the entire team. So look for the key word accountability or Ownership and individual member never becomes absolute owner of the backlog items would be very clear on this concept of collective ownership. Laden 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 decides the capacity for the spring. Product owner and the valuable abuse can negotiate on this. But decisions is with laden, create and maintains any ground rules required. It can be a coding standard or an expected social behavior, et cetera. One sprint backlog. They are responsible for creating and maintaining the sprint backlog. Product owner track and forecast the likely completion dates for the product development. But within the Sprint best knows their progress towards the Sprint goal. They track the progress within the Sprint. Most of these cases disappears as a direct question. Product Owner is responsible for creating and maintaining the product backlog. Team can get involved in this activity. Last two points. Scrum prefers feature teams on competent teams. Feature teams work across layers and components, creating a capability or feature Scrum, The first co-located team. This brings in an effective communication, faster decisions, better coordination, and more crust. Let's discuss the next roll. The scrum master. Keywords that describe this grandmaster role, our facilitator, servant, leader, coach, protector, et cetera. Scrum Master makes sure that the Scrum is 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 timeboxing. He or she coaches the team on Self-Organizing. So Scrum Master has a coaching role to play while attending questions on impediments, we must clearly understand if it is an internal technical issue or an impediment that spreads outside the team boundaries. Team is self-managing once it escalate or has reached outside team boundaries, Scrum Master will get involved and facilitate the resolution. For all impediments the Scrum Master has eroded, track them, and facilitate the resolution. If the product owner becomes or create 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 goal. The Scrum Master helps the Product Owner in finding techniques for Product Backlog 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 affectively and teaches team The Art of timeboxing. But he or she is not a participant in this event unless he or she is a member of our loop. Daily Scrum is only for they are the only participants of 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 the religious. So one more point. A scrum master can be at the developer's 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 as the single source of requirement. 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. There may be two stakeholders with conflicting views or a single functionality in may have a different understanding of a requirement. Some influential role in the organization, maybe forcing the team to work on a different set of requirements. There will be a conflict of interest among stakeholders on the order of product backlog items. In all these scenarios, the answer, the responsible, that decision maker is the product owner. There may be disagreements are conflicting perceptions within team regarding the requirement team and must address it to the product owner and get it clarified. There can be other conflicts, personal or technical within the, remember the key concept or self-managing teams must resolve these and keep going. The scrum master coaches than team in self-organizing. So for such questions, the first choice may be team resolves within themselves. But be very careful here. This may be something which went out of the team's control or item than involves external parties. In these cases, the scrum master may step in. If product owner becomes an impediment. Scrum Masters steps in. Coaches, they expected Scrum values. Every conflict is different. We can't go with a single formula in this based on the above ground rule, we must analyze the situation and take a Cool. 5. Addressing questions from topic Scrum Artifacts: Let's move on to the next topic. We will see different artifact in Scrum. Scrum guy talks about three artifacts. The product backlog, the sprint backlog, and The Product increment. The Product Backlog is an ordered list of everything that is known to be needed in the product. It is a single source of requirements for any changes to be made to the product. Those Brinch by log is gumbo slot the Sprint goal. The second product backlog items selected for the sprint as reloads an actionable plan for delivering the increment. Increment is an non-Greek that where's the product Gore? 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, non-functional, 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 its content, availability and ordering. A few useful points for the assessments are, this is alive 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 Backlog Items have the attributes of a description or estimate and value. As mentioned in the last module, that developers are 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. Product owner is responsible for the product backlog and team can get involved in the Backlog Refinement activities. It is a common practice to create product backlog items in the form of user 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 is 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, but there will be multiple sprint backlogs, one for each team. Product backlog is an ordered 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 owner's 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 gumballs lock the sprint goal. So dot product backlog items selected for those sprint as we lost by an actionable plan for delivering the increment. In some questions to sprint backlog may be referred as a forecast him 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. Rubber labours 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 or answer is verbal abuse. No one else updates the 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 only 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 can grow in size. This is an important concept for the assessment. As the work start, more knowledge will be available and 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 team to track the progress within the sprint at any point of time, the total remaining effort in the sprint backlog shows the amount of identified work remains in the sprint. Please note the key word. 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. But there will be separate sprint backlogs for each team. Scrum 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. Increments is a stepping stone towards the product Gore. Each increment is addict due to all the ingredients aren't thoroughly verified, ensuring Dutch or increments work together. In order to provide value, the ingredients must be usable. Many of the questions on increment will be around the concept of done. An increment must be done in, must be completed in all aspects and ready 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 shippable 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, refered 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 is responsible for all estimates. Relative estimation may not be a direct question, but a basic knowledge will be helpful. Relative 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 are 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 as a recommended method. Scrum team decide the tools and techniques. Scrum teams are using different burndown charts at different levels. A sprint burndown chart shows the total identified work for remaining in the sprint against day in the sprint. These are not prescribed constructs but may be referred as a part of other questions. Keep this in mind. A temporary burn up is possible in a burn down chart. Because now items can be added to the sprint or product backlogs at any point of time. Velocity is the number of story points done by the team in a sprint. Term, velocity may not be directly referred in questions, but it will be referred as the past performance of the 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 sprints 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 defined in the Scrum. Scrum mandate for Events, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. This list itself can be a question. Scrum Guide refers to a backlog refinement, but this is not a formal or mandatory or prescribed event. Backlog refinement is an ongoing activity, not a prescribed event. Time box for each event is important. For daily scrum. It is fixed as 15 minutes. Irrespective of the Sprint Length. Time boxes for other three events can vary based on the sprint duration. For one month sprint time box for the Sprint Planning is eight hours. Sprint Review for hours and retrospectives three hours. This can be shorter for shorter sprints. In daily scrum, only developers participates in sprint planning and Sprint Retrospective, The Scrum Team participates in those sprint planning to otherwise, Sprint Review is an event where the people outside the Scrum Team actively participate. The participants for Sprint review include Scrum team and other stakeholders as Invited by the product owner. Role for events are mandatory and should not be avoided a 100 any conditions. Questions may present many situations, types of products, team structure, irrespective of all these 04 prescribed events are mandatory, exclusion of any of these events will have an impact on transparency and reduce opportunity to Inspect and Adapt. Lets read the above sentence again, exclusion of any of these events will have an impact on transparency and reduces opportunity to inspect and adapt. We should maintain proper sequence as well. Sprint. We'll start with a sprint planning meeting. There will be Daily Scrum every day. End of the sprint, we will do a review and Sprint Retrospective happens after the sprint review. Before next sprint planning. The difference between Review and retrospectives may be 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 collaborative effort of the entire scrum team. During the sprint planning, Scrum team participates and the timebox is eight hours for one month sprint. For shorter sprints, This can be shorter. The questions that are answered by this meeting are, why is thus brimmed? While what can be done in this bridge, how we will do some work done. Product Owner explains his expectations from the upcoming sprint. That is, gives the business priorities and explains the product backlog items which he thinks will achieve this expectation. But I repeat, remember labours decides how many items can be included in the sprint. Their capacity for this brand, and past performance for guided team and selecting the number of items. The product owner can clarify the items and negotiate the scope with the Durban labours. But the decision on the number of items that can be included is with verbal abuse. During sprint planning, the scrum team also crafts a sprint goal. The sprint goal is an objective that will be met within the Sprint throughout the implementation of the selected Product Backlog Items. And it provides guidance on why it is building the increment definition of spring goal is an important topic. Another key characteristic is that the sprint goal gives some flexibility for the development while defining the scope and while creating the increment. In other words, scope of work can be renegotiated without endangering the Sprint goal. Sprint Goal guys that team during the spring. These features with sprint goal often figure in multi-select, select the correct statement type of question. Rubella, team decide how to aspect, how to work as a self-organizing team and convert the selected backlog items to shippable increment. During this process, new knowledge, findings, issues may come up and the team can renegotiate the scope with the Product Owner. Sprint goal, the selected backlog items plus a plan for achieving it makes the sprint backlog. This is not completed. Gerber labours. We'll keep updating the sprint backlog. Throughout the sprint, developers collectively owns items in the sprint backlog. Accountability for an individual backlog item is not fixed with a particular team member. Please note, scope and sprint backlogs are not frozen and can be renegotiated with the product owner. But there is something phase. And that is the Sprint goal. We will move on to daily scrum. The daily scrum, Daily Stand Up, or simply referred as daly, is a 15-minute time-boxed event where the Durbar labours collaborate and plan their activities for the next 24 hours. Important points. The timebox is 15 minutes and the participants are only Durban labours. The scrum master, make sure that the events happen and the participants understand its purpose, but doesn't participate. There can 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 are not participants. Box 215 minutes. Unlike other events, this will not change based on sprint length. There will be questions on the timebox for daily scrum based on the sprint length, team size, et cetera. 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 the Scrum guy. A widely used format is of three questions. Every team member answered the same. What did I do yesterday to help the team meet the Sprint goal? What will I do today to help the team meet the Sprint goal? Do I see any impediment that prevents me from meeting sprint goal? Remember this format is not mandatory. Team can decide what works best for them. Gerber labours, assess their progress towards the Sprint goal. Daily Scrum makes 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 are this is an inspect and adapt event. Gerber labours 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. The bottom goes up. The sprint review is to inspect the outcome of the Sprint attribute remain foods of adaptations. A sprint review is held at the end of the sprint to inspect, increment and adapt the 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 answering options. Timebox 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. Note, people outside the Scrum Team is actively participating. Another frequently-used statement is on the product demo, which is part of the sprint 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 on likely 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 is a Revised product backlog that defines the probable product backlog items for the next sprint. Remember for the exam. And this is an inspect and adapt 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 project duration. 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 is the Sprint Retrospective. The Sprint Retrospective is do learn ways to increase quality and effectiveness. 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 sprint. While the sprint review focuses on the product, the retrospective focuses on the development process. This different itself can be a direct question. Timebox is three hours for one month sprint and can be lesser for shorter sprints. The entire scrum team participates, The Product Owner participates from their 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 timebox, The Scrum Master participate as a peer team member in the meeting from the accountability over the Scrum process. Above statements are important as the rows of product owner in Scrum Master in retrospectives 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, and areas to improve. They may inspect and adjust the definition of done. Scrum Team inspects how the last sprint when 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 sprint planning and the way the team continues its work. So this has to be conducted in proper sequence. This is after the sprint review, before the next sprint planning. Remember, this is not the only occasion for inspect and adapt. 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 as the longest event and scrum. It is a maximum of one month duration where a potentially shippable 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 as 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 useable 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. And newsprint starts immediately after the end of the previous sprint. When will the spring end? The answer is simple, straight and non-negotiable. A sprint ends and the timebox expires. And there will be many options that sound logical, but don't get carried away. Sprint ends. When timebox expires. There is only one type of spin. The one with the aim of producing a done shippable increment. There are no special types of sprints. There nothing hoods, hardening, spring, design, sprint or release print. A few of these may be 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 can be other items like review records, legal documents, training materials, et cetera. A sprint can be cancelled. Only product owner has the authority to counsel the sprint. This can happen when the sprint goal becomes obsolete. What will happen to the selected backlog items When a Sprint gets cancelled? When a Sprint is canceled, the items that are done can be reviewed and accepted by the product owner. If it is used for, 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 the product owner and accepted if it is useful 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. Move 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. We're activities. It may take as much time as 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 and order to items in the Product Backlog. This is an ongoing activity and can occur anytime during the product's existence. The Product Owner is responsible and Scrum Master can help in facilitating it. 7. Addressing questions from Scrum Basics and Other Topics: Welcome to this module. Here we will discuss ground basics and a few other topics is for Lean thinking. There can be direct questions on this. Remember three pillars of empirical process control, transparency, inspection, and adaption. And another point to remember is as empiricism knowledge comes from experience and decisions are made based on what is observed. Lean thinking reduces waste and focuses on essentials. Scrum maintains high levels of transparency. Scrum events, artifacts, and roles enables this. Inspection can be during anytime throughout the lifecycle. Scrum teams inspect frequently, but this should not be too frequent to create blockers in their work. Once the 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, is a lightweight framework helps you organize assertions genomic while you do adapt, do solutions for on blips. Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value. Remember, Scrum is a framework, not a process technique for 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, Changing look. So in order ideals of Scrum, leaving out elements or not following the rules of Scrum covers or problems on limited the benefits or scroll what actually un rendering it useless. Scrum roles, events, artifacts, and rules are immutable. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices. A few benefits of sram can be listed as follows. Accelerate time-to-market, increase product transparency. Address evolving requirements, improve collaboration, and reduce risk in the product development. Scrum inherently reduces risk and the product development by short delivery cycles, early testing and early customer feedback, high-visibility, early risk identification. How planning is done in Scrum as a hot topic, as there is a misconception that there is no or less planning in Agile. We do plan in Scrum, but we do enough planning at different levels. We have an overall high level plan for a long duration. And just in time J, IT planning n iterations. We have a release plan, sprint plan. And daily planning happens as part of daily scrum. Planning in Scrum is adaptive. Plans are flexible enough to accommodate changes. 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. Though 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. Scrum Guide states, Scrum dim or mixed goo at doing its goals are due supporting each other. Their primary focus is on the work-up, the sprint to make the best possible progress towards these goals. The scrum team, I did stakeholders are open, abort the work and the challenges. Scrum team members, the respect each other to be capable, independent people and are respected as such by the people with whom they work. Does grump team members, how the courage to do the right thing to work on tough problems. Let's review a few more topics. There is no rule Code, Project Manager and Scrum, but it may exist at other levels in the organization. So port for management is very important 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 as the development progresses. We start with a minimum required design which is extensible and keep improving it. Every team member should follow the architectural guidelines agreed by the team. In each sprint. Improve the architecture as needed for the features planned in the sprint. There is no special sprint dedicated for this silane architecture activities. Also, these activities are not done only in one sprint. It is an ongoing process. Developers are responsible for design and architecture. Definition of done DOD is used to access if all work required is done on the Product Increment 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 and release. This brings in more transparency, a shared understanding of what is meant by the term done. This guy's the team during sprint planning, helping them in evaluating the amount of work required. To main subtopics, our definition of done at organizational 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 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 oh, teams must collaborate and come up with a definition of done that makes their integrated increments ready to ship or done. All aspects. Non-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 Our Courses in SkillShare: We would like to provide an overview of our course is on the the the the the the, the opinions.