User Stories: Managing User Stories in Scrum Framework | Jimmy Mathew | Skillshare

Playback Speed


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

User Stories: Managing User Stories in Scrum Framework

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

5 Lessons (40m)
    • 1. Lecture: 01 Course Introduction

      1:03
    • 2. Lecture: 02 User Story Basics

      12:52
    • 3. Lecture: 03 Managing User Stories

      12:43
    • 4. Lecture: 04 Scrum Framework

      12:26
    • 5. 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.

130

Students

--

Projects

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 discuss how user stories are handled in scrum framework. This course discuss topics including, User Story Mapping, Techniques foe Creating, Splitting/breaking down, Ordering, Estimating user stories, Acceptance Criteria, Definition of Ready, Definition of Done, etc.

A user story is a requirement written in an end-user perspective. A user story describes functionality that will be valuable to either a user or purchaser of a system or software. These are written in the perspective of customer. It reflects what customer expect from or want to do with the product.

This course has some common modules/sessions with our other courses "Agile Requirements: Managing Requirements in Scrum Framework" and "Scrum Product Owner: Agile Product Ownership with Scrum". Also a few topics from our scrum training.

***************************************************

 

Topics covered are listed below.

User Story Basics

          Introduction

          User Stories

          Acceptance Criteria

          Definition of Ready

          Definition of Done

          Estimation

Managing User Stories

          User Story mapping

          Splitting user stories

          Ordering Backlog Items

          Release Planning

We will start with the basics. Then there will be a details discussion on user stories, acceptance criteria, definition of ready for a user story, definition of done for a user story etc.

Then there will be a detailed discussion on different methods of maintaining the user stories. We will discuss, user story mapping, different approaches for breaking down the epics or user stories, different methods used for prioritizing etc.

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: Hello, welcome to this course on user stories. Here we will discuss how user stories are handled in the Scrum framework. A user story is a requirement written from an end-user perspective. A user story describes functionality that will be valuable to either a user, all purchaser of a system or software. These are written from the perspective of the customer. It reflects what customers expect from and one to do with the product. This slide shows the topics that we covered as part of this course. We will start with the basics. Then there will be a detailed discussion on user stories, acceptance criteria, the definition of ready for a user story, definition of done for a user story, et cetera. Then there will be a detailed discussion on different methods of maintaining the user stories. We will discuss user story mapping, different approaches for breaking down the epics or user stories, different methods used for prioritizing, et cetera. 2. Lecture: 02 User Story Basics: We will start our discussion on user stories. We will start with the basics. A user story is a requirement written from an end-user perspective. A user story describes functionality that will be valuable to either a user or purchase of a system or software. These are written from the perspective of the customer. It reflects what customers expect from all want to do with the product. Items in the product backlog, usually written in the form of user stories. It usually takes the form. As a user, I want to do something so that I get this benefit. For example, as a user, I want to see the list of all emails received so that I can select one for viewing the three Cs for a user story. Card conversation conformation. The card indicates that the user story should be small enough for a single card. The conversation talks about the detailing part. Detailing will be a result of further discussions and collaboration. More details will be attached or added to the user's story. As we go along. Confirmation indicates when we can confirm that the user story is successfully implemented. Usually, it may take the form of the acceptance criteria. Spike is a story or task aimed at answering a question or gathering information rather than producing a shippable product. The purpose is to gain knowledge necessary to reduce the risk of a technical approach, better understand the requirement or increase the reliability of a story estimate. Large user stories are typically referred to as epics. Epics generally take more than one or two sprints to develop and test. Usually broad in scope, short on details. It must be split into multiple, smaller stories before the team can work on them. In short, we can say it's a large user story. A theme is a group of user stories that share a common attribute. They are grouped together for convenience. For example, we can have a theme, communication, or stories related to customer communication can be grouped and tracked under these. Themes are often used to organize stories into releases or to organize them so that various some teams can work on them. A good user story should follow, invest. It stands for independent, negotiable, valuable, estimable, sized appropriately, and testable. Independent implies the user story should be self-contained in a way that there's no inherent dependency on another user story. It shouldn't be negotiable. Stories are not contracts. Leave room for discussions. More details will be added or changes as more knowledge is available. A user story should be valuable to users and customers, not developers. It should be written to reflect the user or client perspectives. A user story must have enough details to estimate and required levels. Predictions are based on these estimates. We should be able to estimate them. A user story must be small enough to complete in one sprint. Launch story should be split into smaller ones. A user story must be testable. The confirmation attribute that we have discussed earlier must be stated clearly. The user story should be small enough to be implemented within one sprint, but it is up to the scrum team to decide to what extent the story should be fine grained based on the nature of work. Acceptance criteria. Acceptance criteria is a set of pre-established conditions that the Product Increment should satisfy to be accepted by the user. This will be provided by the product owner. Acceptance criteria are written in simple language. It defines the conditions of success or conditions of satisfaction. It provides clear story boundaries. Acceptance criteria remove ambiguity by forcing the team to think through how a feature or piece of functionality we'll work from the user's perspective. It provides a checklist or template of things to consider for each story and establishes the basis for acceptance testing. Consider a simple user story. As an admin, I want to create users so that I can grant access to the system. Acceptance criteria for this user story can include items like an admin can create user accounts, and no other role is able to create users. And admin can create a user with a username, e-mail, ID, mobile number. The system displays a message if any of the above fields are missing and the user is not created. System sends an email to the user. Once the account is created, the list can go on. The definition of ready for a user story. How do we confirm that the user story is running in all aspects and can be taken up. The implementation definition of ready for a user story confirms that the user story is ready for implementation. This can include items like Story defined and the business value is clearly articulated. The story has been assigned with the right amount of story points. It is estimated. The story is clearly understood by the development team. Acceptance criteria are clear and testable. Dependencies are identified and no external dependencies would block the story from being completed. Business testdata required to test the story has been identified. Performance criteria, if any, are defined and measurable. The story is small enough to be comfortably completed in one sprint. The definition of done for a user story. Now, when can we say we have done all the work required for a user story? The definition of done is a formal description of the state of the increment on that means the quality measures required for the product. The moments of product backlog item meets the definition of done and increment is born. The definition of done creates transparency by providing everyone has shared understanding of what work was completed as part of the increment. Definition of done for a user story is a set of pre-established conditions for confirming the same as done. It is not the same as acceptance criteria, but meeting the acceptance criteria can be an automated selection to the less. It considers many aspects like organizational processes, standards, legal requirements, et cetera. The definition of done for an increment is part of the standards of the organization. All Scrum genes must follow it as a minimum. If it is not an organizational standard, the scrum team must create the definition of done appropriately for the product. It will be inspected in regular intervals and improve and it's not a frozen document. It can be defined for Sprint and release as well. Checklist confirming if the sprint or Elise is done in all aspects. Consider a simple user story. As an admin, I want to create users so that I can grant access to the system. Items in the definition of done can include user story meets the acceptance criteria and is reviewed by the product owner. All code changes are reviewed as prescribed by the quality manual and major findings are closed. Code changes are checked into the XYZ branch. The list can go on. And estimation techniques. There are different estimation techniques in US. Traditionally, we use techniques like lines of code, function points, use case points, et cetera. In Agile, we use techniques like storypoints, T-shirt sizing, ideal days, et cetera. Ideal days or ideal hours. Ideal days is an absolute estimation method. It estimates how long something would take if it's all you worked on and there are no interruptions for the work. You have everything you need to carry out the work. In Scrum, task level estimates are usually done in ideal hours. Relative estimation. Relative estimation consists of estimating something not separately and not in absolute units of time, but by comparison with one another. It is also done by grouping of items of equivalent size. In short, estimation is done in a relative way in comparison with one another. T-shirt sizing and story points or two examples of relative estimation. Story point estimation. Story point is an arbitrary measure used by Scrum teams. This is used to measure the effort required to implement a story. It is a relative measure. It is done by comparison. It estimates how long it will take considering many factors like complexity, uncertainty, risk, et cetera. It is a faster way of estimating the people who do the work. The development team are responsible for making this estimate. A frequently you scale is Fibonacci series. Story points are a unit of measure for expressing the overall size of a user story, feature or other pieces of work. The number of story points associated with the user story represents the overall size of the story. When estimating with story points, we assign a point value for each item in comparison with other items. The other characteristics are, the estimation scale should be non-linear. The frequently used scale is Fibonacci series, et cetera. We use a set of numbers that makes sense. We may use a modified Fibonacci series as well, like 01235813, then 2040, et cetera. Larger stories, epics can have ranges like one hundred, two hundred, cetera. Story pointing is a relative estimation method. It requires a referral point to do the estimates. Experienced teams may have a clear understanding of what a story point meant for them. This is from their previous story pointing. When we do it for the first time, we need to create a base. A story of a reasonably small size will be selected and assigned one or two points are the stories will be compared with this defined its size. Some companies advocate considering certain hours of effort as a story point. This is a controversial approach and against the sense of story pointing, Planning Poker. Planning poker is a method, tool or activity for estimating using story points. Usually it follows the below steps. First, the product owner provides a short overview of the story to be estimated. The team discusses the clarify assumptions and risks and the outcome of the discussion is updated in the user story, each individual is given a set of cards with the values that are used, usually the cons with Fibonacci numbers. Each individual selects a card representing the estimate and lays it down. Everyone shows that can't simultaneously by turning them over. If there is a difference, people with high estimates and low estimates are given a chance to clarify their estimate and then the process repeats. Participants with an estimate at extreme ends will explain the logic behind the estimation. Product owner clarifies if there are any points or wrong understanding. Once the story and expected work are clear, the team estimate again, this process can repeat, but can't go on indefinitely. If a team fails to get an estimate even after multiple rounds, that indicates there is no single shared understanding of the story or the work-related to it. The story should be parked for further grooming. T-shirt sizing. T-shirt sizing is a way of relative sizing. By comparing stories, you can put them in buckets of extra small, small, medium, large, and extra large. Estimating and relative buckets is easier than estimating absolute time or effort. Estimation is not a onetime activity. At early stages in epic or feature estimates will be at high level. Once requirements reached the level of user stories, we will do a relative estimation with story points. While doing the sprint planning, we will create tasks for each story which will be estimated using ideal days or ideal hours. 3. Lecture: 03 Managing User Stories: Welcome back. Here we will discuss a few topics on how user stories are managed or processed in Scrum. We will discuss some related topics as well. We will start with user story mapping. User story mapping is a visual representation that helps to define the work that is required in the product. It is a visual way of creating a product backlog. It can be used in finding out the user stories for the product in a structured way. We are approaching this activity from a user perspective. It helps in identifying the user stories and grouping them. The output from this exercise can be used in release planning. Let's discuss this using an example. Consider an application for making hotel reservations. One of the goals of the product will be a user should be able to book a hotel room online. If we further look into this, there are many activities involved in this process. Searching for hotels is one of them. There are many tasks that the user may perform as part of this activity, like search on date and location, sort based on price felt on user ratings. If we convert them to the user stories, there can be many stories. Like as a user, I want to search based on data and location so that I can see the availability. As a user, I want to sort the list on price so that I can select a room. As a user, I want to filter the list on rating so that I can select a room like this. We can analyze and map different features of the product. This brings in a shared understanding among all parties involved. This helps in breaking down important features of the application. As we have all main stories on the board, doing a relative estimation becomes easier. It helps him prioritization and release planning. There are different approaches used to break down epics or user stories. A few of them are listed below. Workflow steps, business rule variations, major effect, simple and complex, split using CR, UD, create, read, update, delete operations, variations in data, data entry methods. Spike first, split at basic or exception bars. Death of performance. In the coming slides, we will see examples of these approaches. Always remember the slicing the cake approach that we have discussed earlier. We should not split user stories based on architectural layers. It should be done based on functionality. Each slide should have a part of all the layers. Workflow steps. When a user story involves a workflow of some kind, the item can usually be broken down into individual steps. Consider the user story. As a customer, I want to shop online so that I receive my products at home. There are different steps involved in this process. We can split the story based on them too. Among the resulting stories can be, as a customer, I want to log into the online store so that I can shop. As a customer. I want to view my shopping cart so that I can do a checkout. Business rule variations. When a user story contains a process step with different business rules, we can split it based on those rules. Consider the user story. As a customer, I want to pay online so that I received my products at home. There are many concerns in this process too, among the resulting stories can be, as a customer, I want to pay using a credit card so that I can shop online. As a shop owner, I want to view the payment status so that I can process the order. Major effort. If the user story involves a major functionality and its variations, we will break out the variations and implement the major effort first, consider the user story. As a customer, I want to pay online with Visa or MasterCard so that I received my products at home. The major effort here we'll be using the payment infrastructure. Once it is in place, other cards can be added with less effort to among the resulting stories can be, as a customer, I want to pay using a Visa credit card so that I can shop online. Once it is implemented, we can extend it. As a customer, I want to pay using a MasterCard so that I can shop online. A simple or complex, start with a simple implementation and add more functionality later. Consider the user story. As a customer, I want to search for hotel so that I can make a booking to among the resulting stories can be, as a customer, I want to search with dates and location so that I can do a booking. Once this is in place, we can add more features. As a customer, I want to see options on adjacent date so that I can select the best one. Split using CR, UD, create, read, update, delete operations. A user story can be split using default operations such as create, read, update, or delete. Consider the user story. As a customer, I want to create my profile to among the resulting stories can be, as a customer, I want to create my profile with basic information, name, e-mail. As a customer, I want to update my profile so that I can add more details. Variations in data. A user story can be split based on the data that the operation uses. Consider the user story. As an online customer, I want to search for laptop so that I can buy them online too. Among the resulting stories can be, as an online customer, I want to search for laptops with make and price so that I can buy them online. As an online customer, I want to search for laptops with processor type and RAM so that I can buy them online. Data entry methods and input form can be filled and saved using different ways. The first manual is then automated. Consider the user story. As a customer, I want to search for hotels so that I can make a booking. Here we will start with a simple implementation and make a fancy user interface later. To among the resulting stories can be, as a customer, I want to search with dates and locations so that I can do a booking. Now we will enhance the experience. As a customer. I want to select the location using a map so that I can search for hotels. Spike first approach, when a user story has a complex functionality, challenging technology concerns that the team is unsure about. Do an experiment first, consider the user story. As a customer, I want to pay online so that I received my products at home. Create a spike for experimenting with online payment gateways. This will reduce the unknowns regarding the functionality, great user stories based on the results of this experiment, split at basic or exception path. Start with a simple implementation and go for exceptional cases. Consider the user story. As a customer, I want to search for hotels so that I can make a booking. We will start with a normal, simple flow. Among the resulting stories can be, as a customer, I don't want to search with dates and locations so that I can do a booking. Now, an advanced feature. As a customer, I want the system to identify my location if I leave it blank so that I can search for hotels in my location. Digital performance, make it work, then make it fast. Make the functionality work before going for optimization, consider the user story. As a customer, I want to search for hotels so that I can make a booking tool among the resulting stories can be, as a customer, I want to search with dates and locations so that I can do a booking. As a customer, I want to see the search result within two seconds so that I can book faster. There are many other methods used for breaking down user stories, including based on task scenarios or test cases, based on roles, based on acceptance criteria, based on external dependencies, et cetera. Now we will discuss different methods used for prioritizing the backlog items. Always remember the final decision on the order is from the product owner. However, other roles can influence these decisions. Product backlog items are ordered to provide maximum benefits to the business by delivering higher value items earlier than later. Factors that influence these decisions are business value, market demand, team capacity, risk, dependencies, et cetera. There are different methods that exist for the prioritization of product backlog, Moscow analysis. In this method, a list of requirements or user stories is categorized into the following four groups. Must have, describes a requirement that must be satisfied in the final solution or the solution to be considered a success should have represents a high priority item that should be included in the solution if it is possible. This is often an important requirement, but one which can be satisfied in other ways, if absolutely necessary. Code have describes a requirement that is considered desirable but not necessary. This will be included if time and resources permit, I won't have represents a requirement that stakeholders have agreed will not be implemented in a given release, but maybe considered in the future. Poker method. Another way to prioritize the requirements is poker method. This is similar to Planning Poker. It is a quick and easy method to group items as per their relative priorities. Categories used here can be a very high priority, high priority, medium priority, low-priority, very low priority. The steps are similar to that of Planning Poker. All participants are given cans representing these values. We can use another center values like high, medium, and low, which is prioritizing using only three categories. First, the moderator presents the backlog items to be prioritized. He clarifies the requirement and each participant selects that card. All participants show that selection at the same time. If there are any differences that will be discussed and the process continues. Bed or feature. This is a kind of cumulative bedding method. All participants are given the same amount of money, say a $100. The aim is to distribute this money among the backlog items under consideration. Moderator introduces all the backlog items to be prioritized. After that, each participant distributes the amount among these items based on his or her tank, on the priorities. Once this is done, the backlog items are prioritized based on the total amount each item received. There are many other methods used for prioritizing the backlog items. These include methods like Kano model, stack ranking, weighted shortlist job first, they'll be us j, f by a feature, et cetera, whatever be the model used. The final decision on the order is from the product owner. Now let's discuss a few points regarding planning. Planning is done at different levels in Scrum. It all starts with the product vision. We will have a high level plan at the release level, every sprint starts with the sprint planning meeting. Every day, developers collaborate and plan their activities for the next 24 hours during daily scrum. A few more points to note here are, planning is not a onetime activity. We inspect and adapt the plan as more knowledge is available. Agile and plans are adaptive, not predictive. We adapt the plants to the change in. Plans will change as more knowledge is available. There will be a high level planet release level based on what is known. But this is not a frozen contract. This gives an overall view how the product will evolve across iterations. It is a high-level plan for multiple sprints. This reflects expectations like which features will be implemented and when. Velocity helps us in refining the release plan, the current size of the product backlog, and the velocity will give the number of iterations required. I repeat, this is based on what is known so far. We have already seen this image. Let's have a look at the image again. Based on the predicted velocity, we can map the stories across different iteration output from the story mapping exercise, priorities and dependencies will play a crucial role in this mapping. This activity can be done as a continuation of the story mapping exercise. This ends our discussion on user stories. Before ending this course, Let's have a quick refresher on the Scrum framework in the next section. 4. Lecture: 04 Scrum Framework: Welcome to the next module. Scrum is founded on empiricism and lean thinking. Empiricism, a sense that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials the empirical model of process control provides and exercises control for processes that I'm perfectly defined and generate unpredictable and unrepeatable outputs. This is done through frequent inspection and adaptation. There are pillars of empirical control. They are transparency, inspection, adaptation, scrum values. There are values, commitment, focus, openness, respect, and courage. 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. What is Scrum? If we go for a definition from the Scrum Guide, it states, 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. Scrum is a lightweight framework which is simple to understand but difficult to master. Scrum works with iterations or sprints of max one month duration. As we stated before, scrum, emphasis on self-managed, cross-functional teams. It ensures the continuous flow of value to customers through iterative, incremental development and delivery. It follows adaptive rather than predictive planning. It promotes collaboration among all parties involved. We can summarize the basics of Scrum. Scrum is an iterative and incremental agile software development framework for making software projects and products or application development. Sprint is a timebox iteration during which a potentially releasable product increment is created. Design, build, and test activities are performed within sprint. Sprint duration is a maximum of one month. Well, 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 and explicitly communicate a clear product goal. The product owner may 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, a 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, make 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 timebox to eight hours for one month sprints for shorter 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 developer 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 on 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 to the next Daily Scrum? Do I see any threat for the sprint goal? At the end of the sprint, the 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 time-boxed 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 try 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 will keep on producing shippable increments. So we have discussed different roles, events, and artifacts in Scrum. Each Scrum Artifacts contains a commitment. This increases transparency and helps in creating focus. This helps in measuring the progress for the product backlog. It is the product goal for the sprint backlog. The sprint goal for the increment, it is the definition of done. The product goal describes a future state of the product which can serve as a target for the scrum team to plan against. It is parts of the product backlog and serves as a long-term objective for the scrum team. As we have seen early, the product owner creates and explicitly communicates the product goal. As we've mentioned before during the sprint planning, whole scrum team then collaborates to define a sprint goal that communicates why the sprint is valuable to stakeholders. It is a single objective for the sprint and Ponto sprint backlog. The definition of DOM is a formal description of the state of the increments when it meets the quality measures required for the product. It is either exist in the organization or created by the Scrum team. If it exists in the organization, the scrum team will follow it as a minimum. That is, they may enhance, not depreciated by adding products, specific items. Social contracts. In addition to all these formal ones, Scrum teams may define a sense of ground rules that will help them in delivering a self-organized, high performing team. These are called social contracts. An example of such a social contract is given in the next slide. This is an example of the social contract. There are items like no side conversations during stand-ups. Everyone pays attention to what's being discussed. This is not a complete list or a template. Each team will define its rules based on its requirements. This can be captured in any format as decided by the team. This is just an example. The Agile principles sense business people and developers must work together daily throughout the project. In Scrum, business is represented by the product owner. He coordinates with all stakeholders and represents their views. He gives the team business direction and maximizes the value of the work that the team performs. Close collaboration with the product owner is mandated for the success of Scrum. Scrum events are designed to enhance these interactions. Scaling frameworks. There are multiple scaling frameworks that exist for multiple team implementations. But in general, we can think of certain tools like Scrum of Scrum, common sprint reviews, combined retrospectives, multi team planning, common product backlog, dependency tracking, et cetera. Product increment in Scrum. And increment 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. This is termed as one of the scrum artifacts. This is fully tested, approved, and ready for deployment. Each sprint produces a shippable increment, but when does ship or deploy depends on many factors. We may decide to ship it all, wait for further increments. With things. We have reached the end of this module. Thanks again for joining us in this training. Keep learning. Let's sprint. 5. 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.