Agile Requirements: Managing Requirements in Scrum Framework | Jimmy Mathew | Skillshare

Playback Speed


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

Agile Requirements: Managing Requirements 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

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

      1:01
    • 2. Lecture: 02 Agile Software Development

      7:43
    • 3. Lecture: 03 Scrum Refresher

      6:55
    • 4. Lecture: 04 Requirement Basics

      19:53
    • 5. Lecture: 05 Managing Requirements

      15:14
    • 6. Lecture: 06 Scrum Events

      11:38
    • 7. Lecture: 07 Summary

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

81

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 discusses how requirements are handled in scrum framework.

This course covers all major aspects of managing requirements in agile software development using Scrum framework. Learn how to create and maintain user stories, user story mapping, breaking, ordering etc. How Prescribed events and activities in scrum  processes these requirements.

This course starts with discussions on agile software development and scrum framework. Then it moves to a detailed discussion on requirements.

This course is helpful for anyone who is associated with agile software development or anyone who wish to learn how requirements are managed in agile software development using Scrum framework.

A basic knowledge of software development is helpful in taking this course. This course, in the first session covers the basics of Agile software development and Scrum framework.

This course covers all major aspects of managing requirements in agile software development using Scrum framework. The course starts with product vision, then a detailed discussion on product backlog and user stories. It covers estimation methods used in agile.

Then there is a quick discussion on collecting requirements and a discussion with example on user story mapping. It covers with examples, many techniques for breaking down the user stories. It covers a few methods for ordering/prioritizing product backlog items.

In the final session discusses different prescribed events and activities in scrum, that processes these requirements.

The course ends with a summary of the discussion using a simple image of scrum framework.

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

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

These are the topics covered as part of this course.

  • Agile Software Development

  • Scrum Framework

  • Requirement Basics

          Introduction

         Product Vision

         Product Backlog

         User Stories

         Acceptance Criteria

         Definition of Ready

         Definition of Done

         Estimation

  • Managing Requirements

         Collecting Requirements

         User Story mapping

         Splitting user stories

         Ordering Backlog Items

         Release Planning

  • Scrum Events & Activities

         Backlog Refinement

         The Sprint

         Sprint Planning

         Daily Scrums

         Sprint Review

         Sprint Retrospective

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, and welcome to this course on Agile requirements. Here we will discuss how requirements are handled in the Scrum framework. This course starts with discussions on Agile software development and the Scrum framework. Then it moves to a detailed discussion on requirements. This slide shows the topics that we cover as part of this course. We will start with the discussion on Agile software development, then move on to a discussion on the Scrum framework. After that, we will start our discussion on the requirements. We will see how requirements are handled in Scrum. We will start with the basics. Then there will be a detailed discussion on different method for maintaining the product backlog. We will discuss different prescribed events and activities in Scrum that process these requirements. In the last module, we will summarize our discussion using a simple image of the Scrum framework. 2. Lecture: 02 Agile Software Development: Welcome back. In this module, we will have an introduction to Agile software development. In the traditional waterfall approach, the software development is done in a sequence of phases. First, there will be a detailed requirement phase. In this phase, but complete set of requirements are captured. Then we will move to a design phase. We will complete the high level design, low level design, et cetera. Then we will start with the development, followed by testing and then user acceptance and release. This looks fine as a solid framework, but here we are dealing with human beings, not machines. Mistakes can creep in. For example, requirements may keep changing as the development progresses. Development may take too long or at the end to keep schedule, we may have to skip some tests knowingly or by mistake. It is a long time period from the requirements to the delivery. We don't realize any value until the end of the project. And when we realize it that the customer's needs may not remain the same. This approach leads the testing until the end. Mistakes are detected length, and it will be costly at effects. We don't seek approval from the stake holders until late. There's no frequent interaction with the customer. And when we show them the product, it might not be the right product for them. The planning is done and thanks early in the project and we are managing the project to the plan. There's a heavy dependency on the plan. This traditional approach is heavily reliant upon a project manager driving the way. Now let's start with Agile software development. If we go for a simple definition, it says agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration and delivery. At timebox iterative approach and encourages rapid and flexible responses to change. It is a conceptual framework that promotes forcing interactions throughout the development cycle. There are a few key words highlighted here. We will discuss them one by one in the coming slides. Agile methods are based on an iterative and incremental development approach, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, and delivery, a time-boxed iterative approach, and encourages rapid and flexible responses to change. Agile is an umbrella term for different methods such as XP, Scrum, and ESDM. Agile is much more than a new process. It is a culturally different way of building products compared to the traditional methods. Now let's discuss two concepts, incremental and iterative development. In the integrative model, the entire development is split into a number of parts. Instead of having a long single phase, the development happens in different smaller iterations. Iteration development is a way of breaking down the software development of a large application into smaller chunks. In iterative development, the software is designed, developed, and tested in repeated cycles. As the name suggests, in the incremental model, with development happens in an incremental way. Instead of delivering all at once, we start with an initial one and keep adding increments to it. The increment bold model is a method of software development where the product is designed, implemented, and tested incrementally. That is a little more as added each time until the product is finished. The next topic is self-organizing and cross-functional teams. Self-organizing teams plan and manage their work on their own, not directed by someone outside the team. Self-organizing teams choose how best to accomplish their work rather than being directed by others outside the team. Teams are structured and empowered by the organization to organize and manage their own work. A cross-functional team has the right mix of capabilities. They all have the required skills to successfully complete their work. A cross-functional team is a group of people with different functional expertise working toward a common goal. In other words, the team will have all the capabilities to accomplish the task assigned to them. Now, let's discuss a few points on planning. In traditional software development, planning is predictive. The plan is defined at the beginning of a project and then managing the project to the plan. In adaptive planning, we define an overall plan at the start, but it is not frozen. Once work starts, the blend may change to adapt to the new learnings and changes around us. Lands for an Agile team will be adapted based on the delivery and changes in the requirement for each iteration. Benefits of agile include not limited to accelerate time to market. Agile delivers the right scope at the right time, not all at once. The most important features on delivered earlier than later. It increases project transparency and visibility by having multiple iterations of the end-to-end development cycle rather than one iteration. Agile methods welcome changing requirements. It addresses evolving requirements and re-prioritize is as needed. Reduce risk and overall cost was short delivery cycles and testing early and often to identify potential issues early in the project. Business and developers work together throughout the project. It improves collaboration and alignment with business organizations. In the traditional approach, the plan is a onetime activity. But in Agile, planning is done at different levels. We will have initial upfront planning at the start and just in time planning in iterations. In the traditional approach, the project manager plans for the team, but an agile team is empowered and participates in planning. In the traditional approach, detailed requirements are captured and frozen upfront. But an agile we have high-level requirements to start with and requirements evolve as the project progresses. In the traditional approach, we have huge requirements documentation, a lot of taxed at different levels. But an agile requirements are captured in the form of user stories or user cases in a simple way. In the traditional approach, limited client collaboration of the requirements definition. But in Agile, we collaborate with the client throughout the project life cycle. Now let's see some of the key drivers for adopting Agile. A recent survey lists down many benefits as listed here. You can visit the website given below for more details. A few of the drivers, our ability to manage changing requirements, more visibility, more productivity, better time to market, better business alignment, et cetera. Je, IT planning. Jit stands for just in time. In this approach, we have a high level plan for a long duration. Detailed plan for a short duration. Detailed plans are created at the time they are needed, not months in advance. Decisions are made at the last responsible moment. This reduces rework and re-plan. With this, we have reached the end of this module. 3. Lecture: 03 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 an 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 have 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, the glossary, 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 threats 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. 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. 4. Lecture: 04 Requirement Basics: Welcome back. We will start our discussion on the requirements. We will see how requirements are handled in Scrum. We will start with the basics. In the traditional approach, the scope is fixed. Requirements are somewhat fixed at the beginning of the project, and we are planning the project based on these requirements. The questions asked will be, how long will it take to complete these requirements? How much will it cost to complete these requirements? But in Agile, scope varies. Other concerns, cost, time and quality of fixed. Here the question will be, given this priority, budget and time, what scope can be completed? You can't gather all the requirements upfront. Requirements evolve as development progresses. We will start with an initial set of requirements. As the project progresses, more will be known and the requirements evolve with the product being bolt. Product backlog exists and gets updated as long as the product exists. This is a live artifact. This is true regarding the estimates as well. As more knowledge is available. We revisit our estimates and make corrections to the plan. We can't do everything first. We deliver in an iterative and incremental way. Proper ordering of the product backlog items, make sure that the most valuable items are delivered earlier. Prioritization is a key aspect of backlog management. We deliver in short, time-boxed cycles. A new high priority item has to wait only for a short period before development starts on it. The product vision describes the purpose of a product, the intention with which the product is being created, and what it aims to achieve for customers or users. It describes the purpose of your product, why it is being bolt. Ones are the expected benefits. It gives a bigger picture of what we are working on and why the product vision is aligned with the business goals of the organization. It creates a common understanding among all parties involved. It guides us in making decisions throughout the project. It helps in keeping the focus of the business goals. We must express it in a simple language. Everyone should understand the purpose. We won't be able to cover all aspects of the product, but it represents, in clear words, the vision of the product. It keeps everyone motivated to work towards achieving the goals. Or product vision statement must be expressed in a proper format, which is suitable for the product and the industry, whereas it's placed, a commonly used format is given here. For a target customer who has a need or an opportunity. The product is a product in this category that gives these benefits. Unlike competitive product, our product gives an edge or make a key difference. An example can be, for Agile enthusiasts who want to be successful product owners. The product owner training is an online course that teaches the art of product ownership. Unlike other courses, are product owner gets to the point training with less duration, more value. Product backlog. The product backlog is an ordered list of everything that is known to be needed in the product. Usually the items take the form of epics and user stories. Product owner owns and prioritizes the product backlog. This is a live document. The product backlog exists as long as the product exists, items can be added to the product backlog at anytime during the project. It is a prioritized list of requirements that provide business value for the customer. The product owner is responsible for creating and maintaining requirements, but the team can contribute to this activity. The final decision on the order of items in the product backlog is from the product owner. However, other roles can influence these decisions. One of the commonly used models in Moscow, what backlog items or categorized as must house is a minimum usable subset. Should have, could have or won't have, but would like. And future. Other approaches for ordering include those based on business value, risk-based, Kano model, et cetera. A product backlog contains different types of items like story-based work, task-based work, et cetera. In short, everything that is required for the product, higher ordered product backlog items are usually smaller, clearer, and more detail than lower ordered ones. The product owner is responsible for maintaining the product backlog, but the estimates must come from the people who do the work. Deep talks about the characteristics of a healthy product backlog and stands for detailed, appropriately emergent, estimated, prioritized. We have discussed all these aspects. Product backlog items must have enough details based on what is known so far. It is a live document. It gets updated throughout the life of the product. It is a prioritized list with an estimate based on what is known. A healthy product backlog will be respecting the deep criteria. Items will exist at different levels of detail. There will be items that are ready for implementation and items which need further refinement. The list should be prioritized and estimated based on the availability of information. As good practice teams making sure there are enough ready user stories for the upcoming n number of sprints. This number will be agreed upon by the Scrum team. 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 01 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 sometimes 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 should 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 it meets the quality measures required for the product. The moment 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 list. 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 teams 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 x, y, and z branch. The list can go on a definition of done for a sprint. There are organizations that define the definition of done at the sprint and release level as well. At some places it may take other names as well. Definition of done for a sprint confirms that all required tasks and other activities for the sprint are completed. It can include, but not limited to definition of done of each single user story included in the sprint are met. All unit tests are passing and product backlog is updated. Product Increment is deployed on the test environment identical to the production platform. The performance tests passed. All Category 1 bugs are fixed. Completed user stories are accepted by the product owner. These are a few examples. There can be more or fewer items depends on the nature of the project. Definition of done for a release. Definition of done BOD for a lease confirms that all required tasks and other activities for the release or completed, it can include, but not limited to and code complete reached environments are ready for release. All test results are green. All acceptance criteria are met, QA is done and all issues resolved. Green baseline. No open issue in bold and Integration. Release Documents are ready. These are a few examples. There can be more or fewer items depends on the nature of the project. 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 an 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 on 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 to each item in comparison with other items. The other characteristics are, the estimation scale should be non-linear. The frequently use 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, et cetera. Story pointing is a relative estimation method. It requires a referral point to do the estimates. Experienced teams, Many 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 to 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 the account 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. 5. Lecture: 05 Managing Requirements: Welcome back. Here we will start with a few approaches for gathering requirements. A few points to note are requirements evolve as development progresses, we will start with high level requirements and improve and expand them throughout the lifetime. This process should be participatory. Remember the three Cs that we have discussed as part of user stories. The conversation is the key element in detailing the requirements. Throughout this process, we focus on the business and product goals. Some of the methods used for gathering requirements are briefly discussed here. This is not a comprehensive list. The selection of methods depends on the product owner and the environment in which he or she operates. User interviews. This is a traditional and common approach for gathering information to find the right set of questions and interview the stakeholders on a one-to-one basis. The selection of the right interviewee is important. We must identify the persons with the right knowledge of the product. He or she should be able to clearly describe the expectations, identify different user roles, interacting with the system, propellers that of questions. For each role, we must define the right set of questions. The question should facilitate the thought process of the interviewee. Go for an open-ended, context-free questions in the beginning to get a wide perspective of the system. Based on the answers, go deep into various areas. Prototyping, create a representation of the expected system along with the stakeholders. This will have a visual impact. This can be done using wireframes, sticky notes on a whiteboard, some physical modelling, et cetera, something in front of their eyes. The participants will be able to come up with more details. They will add more expectations or even remove or deprioritize of view. Story writing workshops. A story writing workshop is one of the best techniques for writing user stories. This is a participatory approach where the right group of people discusses and identifies as many user stories as possible. We should keep the focus on identifying the user stories. Avoid this meeting from turning into a design or architecture workshop. This technique is very effective and helps in release planning. There are many other methods that we can use. Selection of the methods depends on the nature of the product, kind of stakeholders, their availability, et cetera. A few other methods that we can consider can be brainstorming, document analysis, focus group, interface analysis, observation, requirements workshop survey. Now let's discuss 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. 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 writing 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 in 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 path. The 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. A customer, I want to login to 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 receive 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. 20 among the resulting stories can be, as a customer, I want to search with date 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 a 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 bars. Start with a simple implementation and go for exceptional cases. Consider the user story. As a customer, I want to search for hotel 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 want to search with dates and locations 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. Differ 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 talk faster. There are many other methods used for breaking down user stories, including based on test 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 products 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 may be 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 the icon. All partners when 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 you ask 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 changes. 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 this module. Next, we will see how requirements are considered all processed across different events in Scrum. 6. Lecture: 06 Scrum Events: Welcome back. We will discuss different prescribed events and activities in Scrum that process these requirements. Product backlog refinement is the act of adding detail, estimates and orders to the items in the product backlog. It is an ongoing activity. The product owner owns this meeting and the Scrum Master helps him in organizing it. No timebox is specified for this activity, but it should not block sprint activities. This activity can be used for to write user stories. That is, expand, add more details, et cetera. Breakdown user stories that are too big. Improved user stories that are poorly written. Estimate backlog items. Add acceptance criteria. If not already done, look deeper into the backlog to do longer-range technical planning. A typical product backlog grooming or backlog refinement activity can have two parts. In the first part, we will concentrate on requirement clarification and adding more details to the product backlog. In the second part, developers will do the estimation for the user stories. During the sprint, the selected requirements, that is, backlog items, will be converted to a working product Increment. Throughout this process, the product owner will be available to answer the questions and clarifying the requirements. Paas may renegotiate the requirements with the product owner to enhance the possibility of achieving the sprint goal. We can consider the sprint itself. The longest event in Scrum. Sprint contains am concerned zone sprint planning, daily scrums, the development work, the sprint review and the Sprint Retrospective. Sprint is timebox to one month or less. During the sprint, team converts the requirements to a done, usable, and potentially releasable product increment. There is no gap between sprints. A newsprint starts immediately after the conclusion of the previous sprint. Sprint goal is finalized during sprint planning. During the sprint, no changes are allowed that would endanger the sprint goal. The scope may be clarified and renegotiated between the product owner and developers. As more is learned, a sprint can be cancelled before the sprint timebox is over. It is the decision from the product owner. Only the product owner has the authority to cancel the sprint. Sprint will be canceled if the Sprint Goal becomes obsolete. This will be a rare case as the sprint duration is shorter. Sprint planning is a formal entry point for the requirements to the actual development. Based on the priorities, the team select the requirements that will be converted to a shippable increment during the sprint. Let's see how sprint planning is done. The work to be performed in the sprint is planned at the sprint planning. The plan is created by the collaborative work of the entire scrum team. The scrum master ensures that the event takes place and that the attendance understand its purpose. Sprint planning is timebox to a maximum of eight hours for one month sprint. For shorter sprints, the event is usually shorter. Sprint planning is the first activity of the sprint. The scrum team may also invite other people to attend sprint planning to provide advice. The inputs to sprint planning or the Product Backlog where we have the ordered estimated list of requirements, the latest product increment. We should know what we have done so far. The projected capacity of the development team during the sprint assesses the availability of the team. We will consider leaving blends, holidays, et cetera, past performance of the development team, the current speed performance. Or in other words, the velocity of the team. Sprint planning answers the following questions. Why is this sprint valuable? What can be delivered in the increment resulting from the upcoming sprint? How will the work needed to deliver the increment be achieved? In simple words, sprint planning the sides, why we spend what can be delivered and how it can be delivered the Y wants, and how aspects of the sprint. In the first part of Sprint Planning, the product owner proposes how the product could increase its value and utility in the current sprint, the whole Scrum team then collaborates to define a sprint goal that communicates why the sprint is valuable to stake holders. The sprint goal must be finalized prior to the end of sprint planning. The Sprint Goal is the single objective for the sprint. The sprint goal is an objective for this sprint that can be met through the implementation of selected product backlog items. It provides guidance to the development team on why it is Bolding the increment. By the end of the sprint planning, the development team should have an idea of how it intends to work as a self-organizing team to accomplish the sprint goal and create the anticipated increment. In the second advantage Sprint Planning, the scrum team decides what can be done the sprint. The usual process includes the product own, explains the objective that the sprint should achieve and discusses the product backlog items that if completed in this sprint, what achieve this objective? Discussion with the product owner, the developer select items from the product backlog to include in the current sprint. The scrum team may refine these items during this process, which increases understanding and confidence. The team decides how will the chosen work get done. Developers decide how it will bolt this functionality into a done Product Increment during the sprint, the developers usually start by designing the work needed to convert the product backlog into a working product increment. How this is done is that the sole discretion of the developers work plan for the first days of the sprint by the development team is decomposed by the end of this meeting, often to units of one day or less. The product owner can help this process by clarifying the selected product backlog items and make trade-offs. If required, development team renegotiates the selected product backlog items with the product owner. Is sprint backlog. The sprint goal. The product backlog items selected for this sprint plus the plan for delivering them is called the sprint backlog. Developers are responsible for creating and maintaining the sprint backlog. The blind usually takes the form of engineering tasks and other work items for meeting the definition of done for the selected Teams. These tasks are usually estimated in hours or days. Team start with known task at the time of sprint planning. As development progresses, tasks may get added and sprint backlog can grow in size. It is a live document. Developers keep updating it throughout the sprint duration. As a good practice team, make sure that sprint backlog is updated before or during daily Scrum. At any point in time, the total estimated effort for unfinished tasks in the sprint backlog gives the amount of identified work that remains in the sprint. Sprint progresses, new tasks may get added, resulting in a temporary increase in remaining effort. During the daily scrum, the developers inspect the progress of converting the selected requirements into tested shippable increments and make necessary adjustments. Let's see how this happens. The daily scrum is a 15 minutes time-boxed event for the developers to inspect progress toward the sprint goal and adapt the sprint backlog as necessary, adjusting the upcoming plant work. Daily scrums conducted by developers and Scrum Master, make sure this event happens effectively. If the product owner, scrum master, actively working on items in the sprint backlog, they participate as developers. Usually, it takes the format of three questions. Team member answers 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 impediments that prevent the team or me from meeting the sprint goal. The team can decide the format of this meeting, the intention, the expected value of the meeting is important. Three questions format is not mandatory, but it wants successfully followed by many teams. There are many benefits of daily scrum, including but not limited to, improve communications, reduces the need for other meetings. Identify impediments to development for removal, highlight changes, and promote quick decision-making, improve the level of knowledge. And moreover, it is an inspect and adapt meeting. During the sprint review, the Product Increment is presented to elicit feedback and foster collaboration. The product is reviewed and the participants discuss future actions. This may result in new requirements or improving the existing ones. Let's discuss this event in detail. The sprint review is held at the end of the sprint to inspect the increment and adapt the product backlog if needed. This meeting concentrates on the outcome of the sprint. This discuss what was done in the sprint and one of the next things that could be done to optimize value. This is an informal meeting. This is not a status meeting. The Scrum team will present the increment to the participants. The increments is presented to elicit feedback and foster collaboration. Attendees include the scrum team and stakeholders invited. This is a four hour time box meeting for one month, sprints. For shorter sprints, it will be shorter. In other words, it is timebox to four hours. The Product Owner explains what product backlog items have been done and what has not been done. The scrum team demonstrates the work that it has done and answers questions about the increment. The product owner discusses the product backlog as it stands and projects likely completion dates, the entire group collaborates on what to do next. The result of the sprint review is a revised product backlog. The product backlog may be adjusted to meet new opportunities. Sprint retrospectives. How a sprint retrospectives relevant in requirement management. Items like Definition of Done and definition of ready are inspected and improved. As part of this event, there will be concerns or areas of improvement to the requirement management process coming out of this meeting. Let's discuss this event. 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. The sprint retrospective occurs after the sprint review and prior to the next sprint planning. The Sprint Retrospective concludes the sprint action items coming out of the retrospective will have an impact on the next planning. This is a three hour time boxed meeting for one month sprints. This meeting and Spanx how the last sprint went with regard to people, relationships, process and tools, and identify and order the major items that went well and potential improvements. Sprint retrospective provides a formal opportunity to focus on inspection and adaptation. There are different techniques used for conducting sprint retrospectives. A widely used method uses three categories. Think of a structure for the discussions. What went well, what didn't go well? What are the points to improve? The team discusses these points and comes out with an action plan. Instead of attacking or items, the scrum team identifies the most healthful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the sprint backlog for the next sprint. This was a quick recap of how requirements flow through different events in Scrum. 7. Lecture: 07 Summary: Welcome back. As summary of our discussion is shown here. Product backlog captures all the requirements required for the product. They are detailed, groomed, ordered, and maintained in the product backlog. During the sprint planning, a subset of requirements is selected for the sprint. The selected items and a plan for implementing them are available in the sprint backlog. During the sprint, the developers convert the selected backlog items to test it shippable product increment. During this process, they clarify the requirements and may renegotiate them with the product owner. Developers conduct a daily scrum. During the daily scrum, the progress toward creating the increment is inspected. The Product Increment is reviewed during sprint review. Discussions may result in changes to the product backlog. Sprint retrospective inspects the process as well as the definition of done, ready and so on, and finds out the areas of improvement. This ends our discussion on this topic. Thanks for taking this journey with us. 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.