Training for Scrum Masters: How to answer questions on Scrum | Jimmy Mathew | Skillshare

Playback Speed


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

Training for Scrum Masters: How to answer questions on Scrum

teacher avatar Jimmy Mathew, Agile Consultant

Watch this class and thousands more

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

Watch this class and thousands more

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

Lessons in This Class

8 Lessons (55m)
    • 1. Lecture: 01 Course Introduction

      1:02
    • 2. Lecture: 02 Scrum Refresher

      6:57
    • 3. Lecture: 03 Addressing questions on Scrum Roles Part 1

      5:54
    • 4. Lecture: 04 Addressing questions on Scrum Roles Part 2

      8:37
    • 5. Lecture: 05 Addressing questions on Scrum Artifacts

      9:19
    • 6. Lecture: 06 Addressing questions on Scrum Events

      15:08
    • 7. Lecture: 07 Addressing questions on Scrum Basics and Other Topics of Interest

      6:38
    • 8. Outro Our Classes in SkillShare

      1:10
  • --
  • 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.

186

Students

--

Projects

About This Class

Training for Scrum Masters: How to answer questions on Scrum

This course prepares the student to answer any questions on Scrum Master Role. This course follows scrum as described in the The Scrum Guide‚ĄĘ.

*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‚ĄĘ

This course covers all major topics in scrum framework but the focus is on answering questions on Scrum Master role.

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 about Scrum Master role 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. 

Meet Your Teacher

Teacher Profile Image

Jimmy Mathew

Agile Consultant

Teacher

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

Publications  

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

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

Certifications

 

.      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!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

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

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

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

Transcripts

1. Lecture: 01 Course Introduction: Welcome to the course. We are following a different approach in this course. Instead of having an end-to-end scrum training, this course prepares the student to answer any questions on Scrum master role. This course follows Scrum as described in the Scrum guide. This course covers all major topics in the Scrum framework. What the focus is on answering questions on the Scrum master role. Updated as per the latest Scrum Guide, November 2020. This includes a session on the Scrum framework in the first module, but this is not basic scrum training. A basic understanding of the Scrum framework is recommended. This course focuses on major topics about the Scrum master role and discusses how to approach questions from each area. If you have good knowledge of Scrum, you can skip the next section and move on. 2. Lecture: 02 Scrum Refresher: Welcome back. Here, we will have a quick visit to the Scrum framework. If you have a good knowledge of Scrum, you can skip this section and move on to the next section. Let's start with the Scrum framework. Every software project is intended to convert a number of requirements into working software and increment or change. Scrum follows and iterative and incremental approach. The work is carried out in multiple iterations called sprints. Sprint is timebox to a maximum of one month. The purpose of sprint is to create a potentially shippable increments of working software. Before getting into the details of this process, Let's discuss different roles defined in scrum developers or the people in the Scrum team that are committed to creating any aspect of a usable increment. Each sprint, they decide how they are going to create a shippable increment. At the end of the sprint. They had all the skills required to convert the selected requirements into a done shippable increment. The specific skills needed by the developers vary with the domain of work. Developers are always accountable for creating a plan for sprint. This will be in the form of Sprint Backlog, which we will see later. They are accountable for the quality of the product. Every day they inspect and adapt their plan to maximize the chances of achieving the sprint goal. The product owner is responsible for maximizing the value of the product resulting from the work of the team. He owns the requirements. This activity consists of detailing backlog items, ordering or prioritizing them to maximize the value and clearly communicating them to the team. They develop an explicitly communicate a clear product goal. The product owner main delegate some of the product backlog management responsibilities to others, but the accountability remains with the product owner. The Scrum Master is a true leader or facilitator and a coach. The scrum master is responsible for promoting and supporting Scrum. Scrum masters do this by helping everyone understand Scrum theory, practices, rules, and values. He or she ensures that the Scrum is understood and enacted by the team. He or she facilitates the Scrum events as required. Scrum master makes sure the impediments for the development or removed the product owner, the developers and the Scrum Master, together referred to as the scrum team. The scrum team is small enough to remain nimble and large enough to complete significant work within a sprint, typically 10 or fewer people. The 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. Start with a sprint planning meeting. This is time-boxed to eight hours for one month sprints. For shortest sprints, it is usually shorter. The Product Owner explains the product backlog items and explains the expectations. The whole Scrum team then collaborates to define a sprint goal that communicates why the sprint is valuable to stake holders. Through discussion with the product owner, the developers select items from the product backlog to include in the current sprint. Developers select item for upcoming sprint based on that capacity. Team velocity, the size of work that they are successfully delivered in the last sprint helps us a guideline while the signing of that capacity for the next sprint. In other words, what is going to be included in the sprint is decided here. The team creates an initial plan for converting the selected items to a shippable increment. This may be in the form of technical tasks for each selected item, or maybe only for items to start with. This explains how the team is going to achieve the sprint goal. The sprint goal selected backlog items with a plan for achieving it. Make the sprint backlog. Developers own the sprint backlog and keep it updated throughout the sprint. They start working on the selected backlog items toward creating the increment to achieve the sprint goal. They do design, development and testing all in the same sprint. They will do whatever is required to achieve the sprint goal. Every day, developers do a daily scrum meeting. This is a 15 minute duration. This takes the form of a standup meeting where they collaborate and decide on actions to be done before the next Daily Scrum. It is kind of quick daily planning. Normally, it takes a form where every member answers three questions. What have I done since the last Daily Scrum for achieving the sprint goal? What am I going to do till the next Daily Scrum? Do I see any threat for the sprint goal? At the end of the sprint scrum team and 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 changes to the product backlog during the sprint, attendees collaborate on the next things that could be done. This is not just a status meeting. The presentation of the increment is intended to elicit feedback and foster collaboration. 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. This is timebox to three hours for one month sprints. For shorter sprints, it is usually shorter. There are different methods used for retrospectives. For example, the team may trying to find out what went well, what didn't go well, what are areas of improvement? Both sprint Review and Sprint Retrospective have an outcome that impacts 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 the other, creating software increments in an iterative and incremental way. As mentioned before, the team create, tested and shippable increment at the end of each sprint. It may get deployed as it is all waits for further increments. However, the team or keep on producing shippable increments. As we have already seen, there are three roles, three artifacts and for ceremonies in Scrum, the roles are product owner, developers, and scrum master. The ceremonies are Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. The artifacts are product backlog, sprint backlog, and the increment. 3. Lecture: 03 Addressing questions on Scrum Roles Part 1: Scrum roles and accountabilities are among the key topics for questions regarding Scrum. Scrum roles are among the most visited areas in any Scrum Master Certification Assessments. We can consider it as a favorite area for any examiner from defines three roles. Developers, the product owner and the Scrum Master. Together, they are called the Scrum team. That is, the Scrum Team consists of the product owner, developers and the Scrum Master. Roles defined by Scrum and members in the scrum team on topics for direct questions. Basic points that we should remember while answering are the product owner owns the requirements. Developers on the work within the sprint. And the Scrum Master as a true leader, take care of the Scrum framework. There will be many basic direct questions on product owner responsibilities. The primary responsibilities of the product owner owns the requirements. That is, the product owner creates and maintains the requirements, 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 increments created by the team. In short, we can say that the product owner owns the content and the order. The other two key phrases frequently found in the questions related to the product owner role, our business direction 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 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 her decisions on the business priorities and value of visible in the content and order of the product backlog items. The product owner may do the above work or may delegate the responsibility to others. Regardless, the product owner remains accountable. 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 right time for production release. The team keeps creating increments that went to release them to the production is a decision from the product owner. It may get released as it's all waits for further increments. Another point to be noted here, 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 the 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. The product owner may represent the needs of many stakeholders in the product backlog. Those wanting to change the product backlog can do so by trying to convince the product owner. Can we cancel a sprint as spring can be cancelled before the sprint timebox is over. It is a decision from the product owner. Only the product owner has the authority to cancel the Sprint. A Sprint will be canceled if the Sprint Goal becomes obsolete. This will be a rare case as the sprint duration is shorter. For a product owner to be successful, everyone in the organization must respect his her decisions are the responsibilities that have not been discussed so far are product owner is responsible for making sure the product 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. Another golden rule for the assessment is one product, one product backlog. You might have seen variations to this rule, but for the scrum master exam, stick to this rule. One product will have a single product backlog. Stick to this rule. One product will have a single product backlog. All teams working on that product will share the same product backlog. Also, remember the product owner is one person, not a committee. The product owner is responsible for creating and explicitly communicating the product goal. This can be a direct question. The product goal describes a future state of the product which can serve as a target to the scrum team to plan against. The product goal is in the product backlog. Remember the key statement, the product goal is the long-term objective for the scrum team. 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 owner doesn't own the estimates. Product owners accountable for the availability, transparency, content, order, clarity, et cetera. But the estimates are owned by those who do the work, that is the developers. Another point, the product owner gives the business direction. He or she sends 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 developers. Developers forecasts and our capacity for the upcoming sprint and decide how much work they can take up in the sprint. We will continue on discussion on Scrum roles in the next section. 4. Lecture: 04 Addressing questions on Scrum Roles Part 2: Let's continue our discussion on Scrum roles. The next role is the developers. The developers or the people in the Scrum team that are committed to creating any aspect of a usable increment for each sprint, developers create the Product Increment. They are accountable for all work towards creating the increment. Or in other words, accountable for all work required to convert the selected product backlog items to a working done shippable software increment. This includes everything, design, architecture, coding, all levels of testing, Build, Integration, Deployment, Automation, et cetera. There are specific questions on any of these work items, and the answer is the same. Developers are accountable. Three 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, and this doesn't mean that they shut their doors. They will get inputs from and be influenced by other roles, but they own the decisions on the way they carry out the required work. They resolve any challenges on their way. They are self-managed. They are themselves responsible for resolving any internal issues, conflicts within the team. This may sound different for some of us, but formally assessment, keep in mind that the team is self-managing. They are cross-functional. There will be questions on the structure, composition of the team. There may be options like hands, programmers, testers, analysis, et cetera, to confuse us, look for an option that says OR means similar to all skills required to convert the selected backlog items into a done shippable increment. The same applies if asked about the amount of work required in the sprint, we should do as much as required to convert the selected items to a done shippable increment. Continuing with the team composition, let's see what will be an ideal size. If the question is based on Scrum guide. The Scrum Guide says, the scrum team is small enough to remain nimble and large enough to complete significant work within a sprint, typically 10 or fewer people. 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 skill constraints. Can we change 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. The team collectively 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 the absolute owner of the backlog item. Be very clear on this concept of collective ownership. The 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 developers decides the capacity for the sprint. Product owner and developers can negotiate on this, but the decision is with the developers. They create and maintain any ground rules required. It can be a coding standard or unexpected social behavior, et cetera. They own the sprint backlog. They are responsible for creating and maintaining the sprint backlog product on a track and forecasts the likely completion dates for the product development. Within sprint, the developers best know their progress towards the sprint goal. They track the progress within the sprint. In most cases, this appearance as a direct question. The product owner is responsible for creating and maintaining the product backlog. But the team can get involved in this activity. Product owners can delegate some of that backlog management activities. Last two points. Scrum prefers feature teams over component teams. Feature teams work across layers components, creating a capability or feature. Scrum prefers co-located teams, and this brings in effective communication, faster decisions, better coordination, and more trust. Let's discuss the next roll, the scrum master, keywords that describe the Scrum master role of facilitator, true leader, coach, protector, et cetera. Scrum Master. Make sure that Scrum is understood and enacted by the Scrum Team. Scrum Master facilitates scrum events as required. Other points can be they coach the team on timeboxing, he or she conscious the team on self-organizing. So Scrum Master has a coaching role to play while attending to questions on impediments, we must clearly understand if it is an internal technical issue or an impediment. The team is self-managing. Once it escalates or has a reach outside team boundaries, scrum master will get involved and facilitate the resolution. For all impediments. The Scrum Master has a role in tracking them and facilitating the resolution. If the product owner becomes all creates an impediment, the scrum master must get into his coaching shoes. Protects the team from external interference that blocks them progress towards achieving the sprint goal. The Scrum Master helps the product owner in finding techniques for the product backlog management. Scrum Master helps the team in maintaining required levels of transparency. Scrum master role in daily scrum is a much discussed item and assessments. Scrum master, make sure this event happens effectively and teaches the team the art of timeboxing is not a participant in the event unless he or she is a member of the developers. Daily scrum is only for developers and they are the only participants in the daily scrum. Should Scrum Master be in technical person. Not necessarily. Technical skills may help sometimes, but it is not mandatory unless he or she is a member of developers. So one more point, a scrum master can play the role of a developer as well. Scrum Master has responsibilities to the organization as well. He or she will contribute to 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. The product owner owns the requirements and is 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 on a single functionality. The team may have a different understanding of a requirement. Some influential roles in the organization may be 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 accountable, the decision-maker is the product owner. There may be disagreements or conflicting perceptions within the team regarding the requirements. The team must address it to the product owner and get it clarified. There can be other conflicts, personal, all technical within the Scrum team or development. Remember the key concept of self-managing teams. They must resolve these and keep going. Scrum master coaches, the team is self-organizing. So for such questions, the first choice, maybe team results within themselves. But be very careful here. This may be something that went down to the team's control or an item that involves external parties. In these cases, the scrum master must have been. If the product owner becomes an impediment, Scrum Master steps in, coaches the expected Scrum values. Every conflict is different. We can't go with a single formula and that's based on the above ground rules. We must analyze the situation and take a coal. 5. Lecture: 05 Addressing questions on Scrum Artifacts: Let's move on to the next topic. We will see different artifacts in Scrum. Scrum guide 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 the single source of requirements for any changes to be made to the product. The sprint backlog is composed of the sprint goal, the set of backlog items selected for the sprint, as well as an actionable plan for delivering the increment. And increment is a concrete stepping stone toward the product goal. 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 accountable for the product backlog, including its content, availability and ordering. A few useful points for answering questions are, this is a live artifact. At any point in time, new items can be added to the list, and this can grow in size. A product backlog is never complete. It exists and gets updated as long as the product exists. Product's backlog items have the attributes of a description, order, estimate, and value. Attributes often vary with the domain of work. As mentioned in the last module, 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 decide the estimates. The product owner is responsible for the product backlog, but the team can get involved in 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 a widely used format and it works well. But Scrum doesn't restrict the use of other formats, whichever be the fomite use, the 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? The 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 we the technique used for ordering? There will be many options, including a 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 at the product owner's discretion. Look for an answer that tells the ordering is done in 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 composed of the sprint goal, the set of product backlog items selected for the sprint, as well as an actionable plan for delivering the increment. In some questions, the sprint backlog may be referred to as a forecast from the team on the expected functionality of the sprint. This may take the form of engineering tasks for each selected product backlog item. But remember, this is not a strict rule. Developer's own sprint backlog and have 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 developers. No one else updates the sprint backlog. Another point is that the sprint backlog need not be completely formed by the end of the sprint planning. Detailed task level planning may be done only to extend weather team can confidently predict what can be included in the sprint. Detailed plans may be for a few items to start with. This is expected. Sprint backlog is alive artifact and tasks can be added or removed at any point in time. So at times, please listen carefully. This can grow in size. This is an important concept for the questions. As the work starts, more knowledge will be available and the team will identify new tasks. They may remove a few as well. In the assessment sprint backlog may also be referred to as a document used by the team to track the progress within the sprint at any point in time, the total remaining effort in the Sprint Backlog shows the amount of identified work that remains in the sprint. Please note the keyword identified work. This means this is based on what is known so far, not a frozen absolute value. When there are multiple teams in the same product 1, product, 1 product backlog. But there will be separate sprint backlogs for each team. Scrum teams may be maintaining many other documents which may add value to their work. But remember these only to backlogs mandated by Scrum. The next artifact is the increment. We will start with the increment. And increments is a concrete stepping stone toward the product goal. Each increment is additive to all prior increments and thoroughly verified, ensuring that all increments work together to provide value. The increment must be usable. Many of the questions on increment will be around the concept of done. An increment must be made, it 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 depend on many factors. It may get released. All may wait for more sprints. But every sprint produces a readily shippable increment. No additional development or testing is required to make it ready for deployment. Another important point is the commitments connected to these artifacts. Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured. For the product backlog, it is the product goal for the sprint backlog. It is the sprint goal for the increment. It is the definition of done. Use, definition and ownership of these fingers in many questions, remember, product owner creates a product vision and it is part of the product backlog. The scrum team creates a sprint goal and answered in the sprint backlog. The definition of done is a formal description of the state of the increment when it meets the quality measures required for the product. Definition of done in itself is a source for many questions. The definition of done grades transparency by providing everyone has shared understanding of what work was completed as part of the increment. An important point, every increment must satisfy the definition of done. If not, it is not considered as done and it cannot be released or even presented at the sprint review. Definition of done is among the topics discussed in the sprint retrospective where it can get updated. The source of definition of done is another topic. It can be from the organization or created by the Scrum team. If the definition of done for an increment is part of the standards of the organization. All Scrum teams must follow it as a minimum. If it is not an organizational standard, the scrum team must create a definition of done appropriately for the product. Now let's discuss a few points on estimation. Estimation can be parts of 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 are responsible for the estimates. Relative estimation may not be a direct question, but basic knowledge will be helpful. Relative estimation consists of estimating something not separately and not an absolute units, but by comparison with one another. It is also done by grouping of items of equivalent size. In short, estimation is done relatively in comparison with one another. T-shirt sizing and story points are two examples 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. The scrum team decides the tools and techniques. Scrum teams are using different burn down charts at different levels. As Sprint Burndown chart shows the total identified work remaining in the sprint against the days in the sprint. These are not prescribed constructs but may be referred to as parts of other questions. Keep this in mind. A temporary burn up is possible in a burndown chart because new items can be added to the sprint or product backlogs at any point in time. Velocities the number of story points done by the team in a sprint. The term velocity may not be directly referred to in questions, but it will be referred to as past performance of the team. This is useful in designing the number of backlog items, amounts 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. Lecture: 06 Addressing questions on Scrum Events: Let's move on to the next topic. We will discuss different events defined in 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 backlog refinement, but this is not a formal or mandatory or prescribed event. Backlog refinement is an ongoing activity, not a prescribed event. Timebox for each event is important. For daily scrum, it is fixed, is 15 minutes irrespective of the sprint length. Time boxes for the other three events can vary based on sprint duration. For one month sprints, the timebox for sprint planning is a maximum of eight hours. Sprint review a maximum of four hours, and retrospective a maximum of three hours. This can be shorter for shorter sprints. In daily scrum only develop his participate in sprint planning, sprint Review, and Sprint Retrospective, the Scrum Team participates. Grantee may also invite other people to attend sprint planning to provide advice. The participants for sprint review include the scrum team and other stakeholders as invited by the theme. If the product owner or scrum master or actively working on items in the sprint backlog, they participate as developers. All four events are mandatory and should not be avoided under any conditions. Questions may prevent many situations, types of projects, team structure. Irrespective of all these, all four prescribed events are mandatory. Exclusion of any of these events will have an impact on transparency and reduces the opportunity to inspect and adapt. Let's read the above sentence again, exclusion of any of these events will have an impact on transparency and reduces the opportunity to inspect and adapt. We should maintain a proper sequence as well. Sprint, we'll start with Sprint Planning and there will be a daily scrum every day. End of the sprint, we do a sprint review and the Sprint Retrospective happens after the sprint review, before the next sprint planning. The difference between Review and retrospective may be strengthened simple, but it's 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 sprint planning. Sprint is planned as a collaborative effort of the entire scrum team. During the sprint planning, the Scrum Team participates and the timebox is eight hours for a one-month Sprint. For shorter sprints, this can be shorter. Scrum team may also invite other people to attend sprint planning to provide advice. The questions that are answered by this meeting. Oh, why is the sprint valuable? What can be done by the sprint? How will the chosen work get 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. Through discussion with the product owner, the developer select items from the product backlog to include in the current sprint. I repeat. The developers decide how many items can be included in the sprint. Then capacity for the sprint and past performance will guide the team in selecting the number of items. The product owner can clarify the item and negotiate the scope with developers. But the decision on the number of items that can be included is with the developers. During sprint planning, the scrum team also crafts a sprint goal. The Sprint Goal is an objective that will be met within the sprint through the implementation of the selected Product Backlog items and it guides on wines is Bolding the increment definition of Sprint Goal is an important topic. The Sprint Goal is the single objective for the sprint. Another key characteristic is that the Sprint Goal gives some flexibility for the developers while defining the scope and while creating the increment. In other words, the scope of work can be renegotiated without endangering the sprint goal. Sprint goal guides the team during the sprint. These features of Sprint Goal often figure in multi-select, select the correct statement type of questions. The developer's team decides the how-to aspect, how to work as a self-organizing team and convert the selected backlog items to a shippable increment. During this process, new knowledge, findings, issues may come up and the team can renegotiate the scalp with the product owner. Sprint Goal, the selected backlog items plus a plan for achieving it makes the sprint backlog. This is not completed. Developers will keep updating the Sprint Backlog throughout the sprint, developers collectively own items in the sprint backlog. Accountability for an individual backlog item is not thanks with a particular team member. Please note scope and sprint backlog or not frozen and can be renegotiated with the product owner. But Something fixed. That is the Sprint Goal. We will move on to daily Scrum or daily Scrum or daily stand-up, or simply referred to as daily, is a 15-minute time-boxed event where the developers collaborate and plan their activities for the next 24 hours. The purpose of the Daily Scrum is to inspect progress toward the sprint goal and adapt the sprint backlog as necessary, adjusting the upcoming planned work. Important points. The timebox is 15 minutes and the participants are only developers. If the product owner or scrum master or actively working on items in the sprint backlog, they participate as developers. The Scrum Master, make sure that the events happen and the participants understand its purpose. There can be many questions like, what is the role of product owner, scrum master, or senior management in Daily Scrum? The answer is strengthened symbol, they are not participants. It is a time box to vent to 15 minutes. Unlike other events, this will not change based on sprint length. There will be questions on the timebox for Daily Scrum based on sprint length, team size, et cetera. The answer remains the same. 15 minutes. It is recommended that daily should happen at the same place, same time. This reduces complexity and makes it more predictive. This formula event reduces the need for many other meetings. Please note, it reduces, not removed. There can be meetings other than those prescribed in the Scrum guide, tm. A widely used format is of three questions. Every team member answers the same three questions. What did I do yesterday that 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 the team from meeting the sprint goal. Remember, this format is not mandatory. The team can decide what best works for them. Developers assess their progress towards the Sprint Goal. Daily Scrum makes sure this happens at least once a day. This means this is not the only occasion where the progress is assessed. The main points to remember are this is an inspect and adapt event. Developers track their progress in this. This improves communications. The focus is on the progress 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 purpose of the sprint review is to inspect the outcome of the sprint and determined future adaptations. A sprint review is held at the end of the sprint to inspect the 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 the Scrum Guide TM. Every sentence is important and usually fingers as part of a question or answer options. Timebox is four hours for one month, sprint can be less of a shorter sprints. Participants or the scrum team and stakeholders as invited by the theme. 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 makes predictions on the 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 of functionality or capability of the product. The result of the sprint review is a revised product backlog. Remember, while answering the questions, this is an inspect and adapt event. This allows getting 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 of this event are equally important. Decisions from Sprint Review will impact next sprint planning. This may uncover some areas that need to be discussed as part of sprint retrospective. So the sprint review should happen at the end of the sprint before the sprint retrospective. Next is the Sprint Retrospective. The purpose of the Sprint Retrospective is to plan 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 difference itself can be a direct question. Timebox is three hours for a one-month Sprint and can be less or for shorter sprints. The entire scrum team participates. The product owner participates in the responsibilities as part of the scrum team. The scrum master ensures that the meeting is positive and productive. Scrum master teachers, all they keep it within the time box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum, the above statements or important as the roles of product owner and scrum master and retrospectives is frequently visited areas. This is another inspect and adapt opportunity. The format for this meeting is decided by the Scrum team. Teams may discuss what went well was not and areas to improve. They may inspect and adjust the definition of done. The scrum team in Spanx, how the last sprint went with regard to people, relationships, processes, and tools. They come out with a plan for identified improvements. Results of this event or action items from this have an impact on the next sprint planning and the way the team continues its work. So this has to be conducted in proper sequence. That is after the sprint review, before the next sprint planning. That is, the Sprint Retrospective concludes the sprint. Remember, this is not the only occasion for inspection and adaptation, 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 as the longest event in Scrum. So we can say that there are five events defined in Scrum. Sprint is a maximum of one month duration where potentially shippable increment is produced. This is an important point and every sprint intends to produce a done increment of products which is ready to deploy when to release it is a decision that depends on many factors. There are many considerations in deciding the sprint length, the direction that the requirements can remain unchanged, short enough to reduce risk, long enough to create a usable increment. Whatever be the considerations, it will be one month or less. I always prefer a short duration. What can we do during the time between two sprints? The answer is, there is no time or gap between the two sprints. A newsprint 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 when the timebox expires. There will be many options that sound logical but don't get carried away. Sprint ends when the timebox expires. There is only one type of Sprint, the one to produce a dumb, shippable increments. There are no special types of sprints. There's nothing called hardening sprint, design sprint, or released sprint. A few of these may be existing in our organization, but forget it for the time being. In short, honest sprints with these fancy names. Is the increment only output from sprint? It depends on the definition of done. If mandated by the definition of done, there can be other items like reveal records, legal documents, training materials, et cetera. A sprint can be canceled. Only the product owner has the authority to cancel the sprints. This can happen when the Sprint Goal 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, the rest of the items will be re-estimated and put back in the product backlog. The same actions apply when the developers 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, the 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. Reduce the need for another meeting, but don't eliminate them. There can be other meetings. Scrum doesn't specify any time box for such meetings or activities. This 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. 7. Lecture: 07 Addressing questions on Scrum Basics and Other Topics of Interest: Welcome to this module. Here we will discuss Scrum basics and a few other topics. Scrum is founded on empiricism and lean thinking. There can be direct questions on this. Remember the three pillars of empirical process control, transparency, inspection, and adaptation. Another point to remember is as per empiricism, knowledge comes from experience and decisions are made based on what is observed. Lean thinking reduces waste and focuses on the essential Scrum maintains high levels of transparency. Scrum events, artifacts, and roles enable this. Inspection can be at any time throughout the lifecycle. Scrum teams inspect frequently, but this should not be too frequent to create blockages in their work. Once a deviation is found, corrective measures must be put into place at the earliest moment to avoid further deviation. Definition of Scrum as given by Scrum Guide, is a good point to remember. Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems, scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value. Remember, while answering, scrum is a framework, not a process or 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. There can be questions on changing the core of Scrum, removing some events, not following the rules of Scrum. As Scrum Guide says, changing the current design or ideas of Scrum, leaving out elements or not following the rules of Scrum covers up problems and limits the benefits of Scrum, potentially even rendering it useless. Scrums, Roles, Events, artifacts, and rules are immutable and exists only in its entirety and functions well as a container for other techniques, methodologies, and practices. A few benefits of Scrum can be listed as follows. Accelerate time to market, increase project transparency, address evolving requirements, improve collaboration, and reduce risk in the product development. Scrum inherently reduces risk in the product development by short delivery cycles. Early testing, an early customer feedback, high visibility, early risk identification. How planning is done in Scrum is 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 JIT planning in iterations, we have a release plan, sprint plan, and daily planning happens as part of daily scrums. Planning in Scrum is adaptive. Plans are flexible enough to accommodate changes. Planning is participatory. The team is empowered and participates in planning. It is not commanded and control. It is not the project manager who makes the plan for the team. Remember, teams self-managing, Scrum Master doesn't assign work. Scrum guide has introduced five values of commitment, courage, focus, openness, and respect. There will be scenarios where we should find the value exhibited by the theme or that is missing in the theme. For that, first, we must remember these five values. Scrum guide states the scrum team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the sprint to make the best possible progress toward these goals. The scrum team and its stakeholders are open about the work and the challenges scrum team members respect to each other to be capable, independent people and are respected as such by the people with whom they work. The scrum team members have the courage to do the right thing, to work on tough problems. Let's review a few more topics. There is no row called Project Manager and Scrum, but it may exist at other levels in the organization. Support from management is very important in the success of Scrum. The role of management will be supporting and empowering the scrum team to be successful, self-managed entity. There will be questions 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 requirement design that is extensible and keeps improving. 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 to design and 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 assess if all work required is done on the Product Increment. Developers 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 items, sprint and release. This brings in more transparency, shared understanding of what is meant by the term done. This guides the team during sprint planning, helping them in evaluating the amount of work required. Two of the main subtopics or definition of done at the 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 project specific items to it. If not, the scrum team creates the definition of done. What if multiple teams working on the same product? The focus will be on the integration. And all the teams must collaborate and come up with a definition of done that makes their integrated increment ready to ship or done in all aspects. Another topic is nonfunctional requirements. Non-functional requirements are handled in many ways by Scrum teams. One method is to add it to the definition of done. This make sure that every increment satisfies these requirements. This ends our discussion on this topic. Please proceed to the quizzes and practice tests. Thanks for taking this journey with us. Let's sprint. 8. Outro Our Classes in SkillShare: Before we end, we would like to provide an overview of our courses. We have various courses on a variety of topics. As summary is given in the slides here. We have many causes on Agile Scrum, software testing, agile transformation, product ownership, scrum master ship, and so on. We have detailed as well, a quick starter training on Agile and Scrum. There is specific training for Agile coaches, Scrum Masters, and Scrum product owners. We have focused courses that enable you to answer questions that you may face as a Scrum master, product owner, and other roles in Scrum. We have detailed courses on software quality assurance. Please have a look at the file attached. Keep learning. Let's sprint.