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

Agile Requirements: Managing Requirements in Scrum Framework

Jimmy Mathew, Agile Consultant

Agile Requirements: Managing Requirements in Scrum Framework

Jimmy Mathew, Agile Consultant

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

      1:17
    • 2. Agile Software Development

      8:43
    • 3. Scrum Framework

      9:42
    • 4. Requirement Basics

      23:35
    • 5. Managing Requirements

      20:01
    • 6. Requirements During Scrum Events

      13:38
    • 7. Course Summary

      1:22
    • 8. Outro Our Courses in SkillShare

      0:55
  • --
  • 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.

70

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.

Your creative journey starts here.

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

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

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

phone

Transcripts

1. Course Introduction: Hello and welcome to this course and Agile requirements. He will discuss how requirements are handled in Scrum framework. This cool starts with discussions on Agile software development and Scrum framework. Then it moves to a detailed discussion on requirements. This slide shows the topics that we cover as parts of this course. We will start with a discussion on Agile software development. Then move on to a discussion on 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 methods for maintaining the product backlog. We will discuss different prescribed events and activities in Scrum that processes these requirements. In the last module, we will summarize our discussion using a simple image of Scrum framework. 2. Agile Software Development: Welcome back. This module we will have an introduction to the agile software development. In the traditional waterfall approach, the software development is done in a sequence of phases. Bust, that will be a detailed requirement phase. In this phase, the complete set of requirements are captured. Then we will move to a design phase. We will complete the high level design, low level design, etcetera. 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 the schedule, we may have to skip some tests knowingly. Oh, 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, the customer needs may not remain the same. This approach leave the testing until the end. Mistakes are detected late and it will be costlier to fix. We don't seek approval from the stakeholders until late. There is 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 fixed early in the project, and we are managing the project to the plan. There is a heavy dependency on the plan. There's traditional approach is heavily reliant upon a project manager driving the way. If we go for a definition from Wikipedia, 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 between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, and delivery. A time books iterative approach and encourages rapid and flexible responses to change. It's as a conceptual framework that promotes foreseen 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-organized and in cross-functional teams. It promotes adaptive planning, evolutionary development, and delivery. A time books iterative approach and encourages rapid and flexible response to change. Agile is an umbrella term for different methods such as XP. Scrum and D SDM. Agile is much more than a new process. It is a culturally different way of building products compared to the traditional methods. In interests and muddle. The entire development is split into a number of pots. Instead of having a long single phase, the development happens in different smaller iterations. Iterative development is a way of breaking down the Software development of a large application into smaller chunks. An interative development software is designed, developed, and tested, and repeated cycles. As the name suggests. In the incremental model, the 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 incremental build module is a method of software development where the product is designed, implemented, and tested incrementally as it is. And it's a mole is added each time until the product is finished. Self-organizing teams plan and manage their own work on their own. They're 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. Across functional team has the right mix of capabilities. They have all the required skills to successfully complete their work. A cross-functional team is a group of people with different functional expertise working towards a common goal. In other words, the team will have all capabilities to accomplish the task assigned to them. 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. And adaptive planning, we define an overall plan, the start, but it is not frozen. Once work starts, the plan may change to adapt to the new learnings and changes around us. Plans for an Agile team will be adapted based on the delivery and changes in the requirements. Each iteration benefits. So Vijay, I'll include not limited to accelerate time to market. I jowl delivers the right scope at the right time, not all at once. The most important features are delivered earlier than later. Its increases project transparency and visibility by having multiple iterations of the end to end development cycle rather than one iteration. I jaw methods welcome changing requirements. It addresses evolving requirements and read prioritizes as needed, reduce risk and overall cost, which showed that every cycles and testing early and often to identify potential issues early in the project, Business and develop as work together throughout the project. It's improved collaboration and alignment with business organization. In traditional approach, plan is a onetime activity, but an agile planning is done at different levels. You will have an initial upfront planning at the start and just-in-time planning in iterations. In traditional approach, the project manager plans for the team. But an agile team is empowered and participate in planning. In traditional approach, detailed requirements are captured and frozen upfront. But in Agile, we have high-level requirements to start with. And requirements evolves as project progresses. In traditional approach, we have huge requirements documentation, a lot of text, and different levels. What's an Agile requirements are captured in the form of user stories or use cases in a simple way. In traditional approach, limited client collaboration often requirements definition. What's an agile? We collaborate reclined throughout the project lifecycle. A recent survey list down many benefits as listed here. You can visit the website given below for more details. A few of the drive is our ability to manage changing requirements, more visibility, more productivity at a time to market, better business alignment, etcetera. Jit stands with just in time. In this approach, we have a high level plan for long duration. A 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. 3. Scrum Framework: Welcome to the next module. Scrum is founded on empiricism. Empiricism asserts 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 an exercises control for processes that are imperfectly 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, and adoption. There are values, commitment, focus, openness, respect, and courage. The scrum team commits to achieving its goals into supporting each other. Their primary focuses on the work of the sprint to make the best possible progress toward these goals. The scrum team and its stake holders are open about the work and the challenges Scrum team members respect to each other to be capable, independent people in our respective as such, by the people with whom they work. Scrum team members have the courage to do the right thing to work on tough problems. If we go for a definition from the Scrum Guide, it states, Scrum is a lightweight framework. It 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 walks with iteration or sprint. So max, one month duration. As we stated before, scrum, emphasis on self-managed, cross-functional teams. It's ensures 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 basics of Scrum. Scrum as an iterative and incremental agile software development framework for managing software projects and product 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 maximum of one month. Let's start with Scrum processes. Every software project is intended to convert a number of requirements into working software. An increment or change. Scrum follows and iterative and incremental approach. The walk is carried out in multiple iterations called sprints. Spring to the time books to a maximum of one month. The purpose of the Sprint is to create a potentially shippable increments of working software. Before getting into the details of this process, let's discuss different rows defined in scrum. Developers consists of professionals who do the work of delivering a potentially releasable increment of done product. At the end of each sprint, owning developers create the increment, self-organizing. They decide how they're going to create a shippable increment at the ends of the sprint, cross-functional, they have all the skills required to convert the selected requirements into the done shippable increment. The Product Owner is responsible of maximizing the value of the product aim. He owns the requirements. This activity consists of detailing backlog items all during o prioritizing it to maximize the value and clearly communicating them to the to the team. He also reviews and accepts or rejects the increment produced by the team. The Scrum Master is a servant leader, a facilitator, and a coach. The Scrum Master is responsible for promoting and supporting Scrum. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. He or she insures that the Scrum is understood and enacted by the team. He or she facilitates the scrum events has required Scrum Master make sure the impediments for the development or remove the product owner, developers and the Scrum Master, together referred as the Scrum Team. Scrum team is small enough to remain nimble, large enough to complete significant work within a script. Typically ten or fewer people. Product Backlog captures all the requirements needed to be included in the product. This is created and maintained by the product owner. The product backlog is an ordered list of everything that is known to be needed in the product. Sprint. Start with a sprint planning meeting. This is time books to eight hours for one month sprints for shorter sprints, it's usually shorter. Product. One explains the Product Backlog Items and sets the priorities. Developers select items for upcoming sprint based on that capacity. Team velocity, the size of the what they have successfully delinked sprint helps as a guideline while deciding that capacity for the next sprint. Together, The Scrum Team agree upon the spring go. The team Drayton initial plan for converting the selected items to a shippable increment. This may be in the form of technical tasks for each selected item will may only be for items to start with. The selected backlog items. Sprint goal with a plan for achieving it. Make the sprint backlog. Developers owns a sprint backlog and keep it updated throughout the sprint. They would start working on the selected backlog items towards creating the increment to achieve the sprint goal. They do design, development and testing all in the same Sprint. They will do whatever required to achieve the Sprint goal. Every day, beam does a daily scrum meeting. There's all 50 minutes duration. This takes the form of a stand-up meeting. They collaborate and decide on actions to be done before the next Daily Scrum. It is kind of a quick daily planning. Normally, it takes a full where every member answers three questions. What I have done since last Daily Scrum for achieving the Sprint goal? What's I'm going to do till next Daily Scrum. Am I seeing any threats for the sprint goal? At the end of the sprint, the scrum team and other stakeholders has invited by the product owner conduct a sprint review. This is time books to e-books to a 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 a sprint, attendees collaborate and the next things that can be done. This is an informal meeting, not a status meeting. And the presentation of the increment is intended to elicit feedback and foster collaboration. The sprint retrospective is an opportunity for the scrum team to inspect itself and creates a plan for improvements to be enacted. Sprint. This is time books to three hours for one month sprints. For shorter sprints, it is usually shorter. There are different methods used for retrospectives. For example, the team may try to find out what went well, what didn't go well, what are the areas of improvement? Both Sprint Review and Sprint Retrospective may have outcome that impact the next sprint planning. A new sprint starts immediately after the previous sprint ends. There is no gap in-between. Scrum. Teams conduct sprints one after the other, creating software increments in an iterative and incremental way. As mentioned before, teem create, tested and shippable increment. At the end of each sprint. It may get deployed as it is or wait for father increments. However, team will keep on producing shippable increments. So we have discussed different rows, Events and Artifacts in Scrum. This is a quick visit. We will discuss these in details in coming modules. As we have already seen, there are three rows, three artifacts, and for ceremonies in Scrum, the Rosa product owner, developers and a scrum master. The ceremonies of Sprint Planning. The ceremony is a Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospectives, the artifacts or product backlog, sprint backlog and the increment. 4. Requirement Basics: Hello, 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 traditional approach, the scope is fixed. Requirements are somewhat fixed in the beginning of the project. And we are planning the project based on these requirements. The questions are asked will be, how long will it take to complete these requirements? How much will it cost to complete these requirements? Agile scope varies. Other concerns, cost, time and quality are fixed. The question will be, given this priority, budget and time, what scope can be completed? You can't gather all the requirements upfront. Requirements evolves as development progresses. We will start with an initial set of requirements. As the project progresses, more will be known and the requirements evolves with the product being built. Product backlog exist and can gets updated as long as the product exists. This is alive 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 backlog items, make sure that most valuable items are delivered earlier. Prioritization is a key aspect and the backlog management will deliver in short time-boxed cycles. A new high priority item has to wait only for a short period before development to start on it. The Product Vision describes the Pappus of our product, the intention with which the product is being created, and what's it aims to achieve for customers or uses. It describes the pop is of your product, why it is being built. What do they expect to benefits? It gives a bigger picture of what we are working on and why the product vision is aligned to the business goals of the organization. It creates a common understanding among all parties involved. It guides us and making decisions throughout the project. It helps us in keeping the focus on 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 to representing clear words, the vision of the product. This keeps ever motivated to work towards achieving the goals. A product vision statement must be expressed in a proper format, which is suitable for the product and the industry, whether it is placed. A commonly used format is given here. For a target customer who has a need or opportunity. The product is a product in this category that gives these benefits, unlike competitor product. All product gives an edge or makes a key difference. An example can be for Agile enthusiasts to want to be a successful product owner. The product owner training is an online course that teaches the odds are product ownership. Unlike other courses, our product gives the to-the-point training with less duration and move value. 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 exist as long as the product exist, 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. For our own is responsible for creating and maintaining requirements. But team can contribute in this activity. Team can get involved in this activity with maximum of 10% of their capacity. The final decision on the order of items in their products backdrop is from the Product Owner. However, other rows can influence these decisions. One of the commonly used modals is Moscow. Web BackRub items are categorized as must have, which is a minimum usable subset. Should have, could have or won't have what we would like in the future. Other approaches for ordering include those based on business value, risk-based, Taino, and modal, et cetera. A Product Backlog contains different types of iTunes and like story-based work, tossed based work, et cetera. In short, everything that is required for the product, higher ordered product backlog items are usually smaller. Clara, a more detailed and ordered ones. Product Owner is responsible for maintaining product backlog. But the estimates must come from the people who do the walk. Dep stands for detailed appropriately. Imagine 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's a prioritized lists 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. That will be items that are ready for implementation and items which need further refinement. And this should be prioritized and estimated based on the availability of information. As good practice teams make sure there is enough ready uses stories for upcoming n number of sprints. This number will be agreed upon by the scrum team. A user story is a requirement written in end-user perspective. A user story describes functionality that will be valuable to either a user or a purchaser of a system or software. These are written in the perspective of the customer. It reflects what the customer expects from or wants to do with the product. Items in the product backlog, usually written in the form of user stories. It usually takes this 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. Cod, conversation. Confirmation. Cod indicates that they use a story should be smaller law for a single cod. Conversation talks about the detailing pot. Detaching will be a result of feather discussions and collaboration. Or details will be attached to add it to the user story. As we go along. Confirmation indicates when we can confirm that the user's story is successfully implemented. Usually it may take the form of the acceptable criteria. Spike is a story or task aimed at answering a question or gathering information, rather than at producing shippable product. The pop is, is the gain, the knowledge necessary to reduce the risk of a technical approach to understanding of a requirement or increase the reliability of a story estimate. Larger uses. Stories are typically referred to as Epics. Epics generally take more than one or two sprints to develop and test. They usually brought in scope, short-term details, split into multiple smaller stories before the team then welcome them. In short, we can say it's allowed user story. A theme is a group of users stories that share a common attribute. They are grouped together for convenience. For example, we can have a theme, communication. All stories related to customer communication can be grouped and tracked under this, themes are often used to organize stories into releases, or to organize them so that various sub teams can welcome them. A good user story should follow, invest. It stands for independent, negotiable, valuable, estimatable, sized, appropriately, and testable. Independent implies the user story should be self-contained in a way that there is no inherent dependency on another user story. It should be negotiable. Stories are not contracts. Leave Ruth with discussions. More details will be added. O a changes as more knowledge is available. A user story should be valuable to customers and uses, not developers. It should be written to reflect to user o client perspective. A user story must have enough details to estimate the required levels. Predictions are based on these estimates, so we should be able to estimate them. A user story must be smaller, love to complete in one sprint. Lodge stories 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 stories should be small enough to be implemented within one sprint. But it is up to the scrum team to decide what extent the story should be fine grained. Based on the nature of work. An epic in general can be considered as a large user story that needs to be broken down into smaller User Stories. Scrum teams, it will decide to what extent the story should be fine grained. Based on an H0 of work. Maybe we can consider an epic as ready when ooh uses stories derived from it to already. Acceptance criteria as sets of pre-established conditions that the Product increment to satisfy to be accepted by the user. It was also known as conditions of satisfaction and will be provided by product owner. It can include functional and non-functional elements. A should be expressed in simple language without leaving room for any ambiguity. Acceptance criteria is written in simple language, defines the conditions of success, all conditions of satisfaction. It provides clear story boundaries. Acceptance criteria removes ambiguity by forcing the team to think through how a feature or a piece of functionality will walk from the user's perspective. It provides a checklist or templates are things to consider for each story and establishes the basis for acceptance testing. Instead of a simple user story, as an admin, I want to create uses. So that's I can grant access to the system. Acceptance criteria for this user story can include items like an admin can create user accounts. No other road is able to create uses. An ad domain can create user with user name, email, id, mobile number. System displays a message or any of the above fields are missing and use it as an ultra created system sends an email to the user wants the account is created, the list can go on. 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. Story has been assigned with the right amount of story points. It is estimated. Story is clearly understood by the team. Acceptance criteria and testable dependencies. Identified a no external dependencies. We're broke the story from being completed. Is this test dates are required to test the story has been identified. Performance criteria, if any, I'll define a measurable the story is small enough to be comfortably completed in one sprint. Definition of dumb for a user story is as sets of pre-established conditions for confirming the same as done. It is not the same as acceptance criteria. But meeting the acceptance criteria will be an automatic selection to the list. It consisted as many aspects like organizational processes, standards, legal requirements, etcetera. It is agreed upon the team and the product owner. It will be inspected in regular intervals and improved. It is not a frozen document. A can be defined for Sprint him release as well. Checklists confirming if the sprint or release is done in all aspects. Consider the simple user story. As an admin, I want to great uses. So that's I can grant access to the system. Items in a definition of done can include user stories, acceptance criteria, and reviewed by the product owner. Oh, code changes are reviewed as prescribed, a quantity manual and major findings are closed. Code changes. A check to XYZ brunch. The list can go on. Definition of done for a sprint confounds that all required tasks and other activities T's for the sprint a completed it coming include but not limited to definition of done of H single user story included in the springtime met or unit tests, deposing product backlog is updated. For that increment is deployed on a test environment identical to production platform. The performance tests passed o category one, bugs of fixed, completed user stories are accepted by the product owner. These are a few examples that can be more or less items depending on the nature of the project. Definition of done. Dod for release confirms that all require Tosca and other activities for the release are completed. It can include, but not limited to code complete reached environments are ready for release. Oh, test results at Green. Oh, the acceptance criteria are met, QA is done and o issues resolved. Green baseline. No open issue and build an integration for at least documents already. These are a few examples that can be more or less items depending on the nature of the project. The different estimation techniques in use. Traditionally we use techniques like lungs 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 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 for carrying out the work. In Scrum, Task level estimates are usually done in ideal hours. Relative estimation consists of estimating something not separately and not in absolute units of time butts in comparison with one another. It is also done by grouping of items of equivalent size. In short, estimation is done in relative way in comparison with one another. T-shirt sizing and storypoints are two examples of relative estimation. Story point is an arbitrary measure used for Scrum teams. These use used to measure the effort required to implement a story. It is a relative measure. It is done by comparison. It estimates how long will it take considering many factors like complexity, uncertainty, and risk, et cetera. It is a faster way of estimating people who do the walk that is responsible for making this estimate are frequently used scale is the Fibonacci series. Story Points are a unit of measure for expressing the overall size of the user story, feature or other piece 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 of them. The other characteristics are, the estimation scale should be non-linear. Frequently used scale is Fibonacci series, etcetera. We use a set of numbers that makes sense. We may use a modified Fibonacci series as well, like 012358132040, etc. Largest stories. Epics can have a range like one hundred, two hundred, etc. Story pointing is a relative estimation method. It requires a referral point to do the estimates. Experience teams may have a clear understanding as to what story point is meant for them. This is from their previous story pointing. When we do it for the first time, we need to create the base. A story of a reasonably small size will be selected and assigned one or two points. Other stories will be compared with this to find 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 is a method, tool or an activity for estimating using story points. Usually follows the below steps. Bus. The product owner provides a short overview of the story to be estimated. The team discusses to clarify some machines and risks. I'm the outcome of the discussion is updated in a user story, each individual is given a set of cards with the values that are used. Usually the cards with Fibonacci numbers. Each individual selects a cod representing the estimate and lays it down. Everyone shows their cards simultaneously by turning them over. If there is a difference, people with high estimates and low estimates, I'll give him a chance to clarify their estimate. And then the process repeats. What should we do if there is no consensus and planning poker? Participants with 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 expect to work is clear, team will estimate again. This process can repeat, but can't go on indefinitely. If the team fails to get an estimate that indicates there is no single shared understanding on the story or the work related to it. The story should be pots for father grooming. Pisa 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 or relative buckets is easier than estimating absolute time or effort. Estimation is not a one time activity. At the earliest stages at Epic or feature level estimates will be a 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. Managing Requirements: Welcome back. We will discuss a few approaches for gathering, bring requirements. A few points to note. Requirements evolves at 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 parts of user stories. Conversation is the key element in detailing the requirements. Throughout this process, we focus on the business and product goes. Some of the methods used for gathering requirements are briefly discussed in hey, 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 in gathering information, defined right set of questions and interview the stakeholders on a one-to-one basis. Selection of the right interviewee is important. We must identify the persons who have right no knowledge on the product. He or she should be able to clearly describe the expectations, identify different user roles, interacting with the system. For press sets of questions. For each role, we must define the right sets of questions. The question should facilitate the full process of the interviewee over an open-ended, context-free questions in the beginning to get to why prospective of the system, based on the answers, go deep into various areas. Prototyping creates a representation of the expected system along with the stakeholders. This will have a Zhu impact. This can be done using wireframes, sticky notes on whiteboard, as simple physical modelling, et cetera. Something in front of their eyes that participants will be able to come up with more details. They will add more expectation or even remove or d prioritize a few. Story writing workshops. Story writing workshop is one of the best techniques of writing user stories. This is a participatory approach where the right group of people discuss and identify as many user stories as possible. We should keep the focus on identifying the user stories. Avoid this meeting turning into a design or architectural workshop. This technique is very effective and helps him 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 and their availability, etc. A few other methods that we can consider can be Brainstorming, Document analysis, focus group, Interface analysis, observation, requirements workshop survey. Uses 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 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 this 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. Ginkgo hotels is one of them. There are many tasks so that the user may perform as part of this activity, like search on date and location, a sort based on price, a filter on user ratings. If we convert them to user stories, there can be many stories like as a user, I want to search based on the date and location. So that's, I see the availability. As a user, I want to sort the list on price. So that's I can select a room. As a user, I want to filter the list on rating. So that's I can select a room like this. We can analyze a map different features of the product. This brings in a shared understanding among all parties involved. This helps him 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. We split the stories based on functionality, not based on technical layers. Or stories will cover all technical layers required for its implementation. This approach is called slicing their cake. In other words, we should not split user stories based on architectural layers. It should be done based on functionality. Each slice that have a part of all the layers. There are different approaches used to break down epic. So user stories, a few of them are listed below. Workflow steps, business rule variations, major effort, simple or complex, split to using crud, which is create, read, update, delete operations. Variations in data, data entry methods, spike fast, split at basic or exception path differ performance. In the coming slides we will see examples with these approaches. Always remember this 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 slice should have a part of all the layers. Workflow steps. When a user story involves work flow some kind, the item can be usually broken down into individual steps. Consider the user story. As a customer, I want to shop online. So that's our received my products at home. There are different steps involved in this process. We can split the story based on them to among the resulting stories can be, as a customer, I want to login to the online stores 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's our received my products at home. There are many concerns in this process. Two among the resulting stories can be, as a customer, I want to pay using credit card. So that's I can shop online. As a shop owner, I want to view the payment status so that I can process the older major effort. If the user story involves a major functionality and its variations, we will break up the variations and implement the major effort first, consider the user story. As a customer, I want to pay online with visa and makes or MasterCard's. So that's our received my products at home. The major effort, hey, 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 Visa credit card. So that's I can shop online. Once it is implemented, we can extend it. As a customer, I want to pay using MasterCard. So that's I can shop online. Simple or complex. Start with a simple implementation and add more functionality later. Consider the user story. As customer, I want to search for hotels, so that's I can make a booking to among the resulting stories can be, as a customer, I want to search with the 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 in adjacent dates so that I can see and select the best one. Split using crud, create, read, update, delete operations. A user story can be split using different 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, and email. 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 laptops, so that's I can buy them online. To among the resulting stories can be, as an online customer, I want to search for laptops with make and price, so that's I can buy them online. As an online customer, I want to search for laptops were processor type and RAM. So that's I can buy them online. Data entry methods and input form can be filled and saved using different ways. The first manual than automated, consider the user story. As a customer, I want to search for hotels, so that's I can make a booking. Here we will start with a simple implementation and make fancy user interface later. To among the resulting stories can be, as a customer, I want to search with date and location so that I can do a booking. Now we will enhance the experience. As a customer, I want to select location using map. 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 doing experiment first, consider the user story. As a customer, I want to pay online. So that's our received my products at home. Traitor spike for experimenting with online payment gateways. This will reduce the unknowns regarding the functionality to read user stories based on the result 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's I can make a booking. We will start with a normal simple flow to among the resulting stories can be, as a customer, I want to search with dates and location. So that's I can do a booking. Now, an advanced feature. As a customer, I want the system to identify my current location. If I leave it blank so that I can search for hotels in my location. Defer 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's I can make a booking to among the resulting stories can be, as a customer, I want to search with date and location so that I can do a booking. As a customer, I want to see the search results within two seconds. So that's I can book foster. There are many other methods used for breaking down user stories, including. Based on test scenarios or test cases, based on rows, based on acceptance criteria, and based on external dependencies, et cetera. 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 high value items earlier than later. Factors that influence these decisions are the business value, market demand, teen capability, risk, dependencies, etc. There are different methods that exist for the prioritization or product backlog. Moscow analysis. In this method, a list of requirements or user stories are categorized into the following four groups. Must have describes a requirement that must be satisfied in the final solution. For the solution to be considered a success. It 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, could have, describes a requirement which is considered desirable but not necessary. This will be included at time and resources permit won't have represents a requirement that stakeholders have agreed will not be implemented in a given release, but maybe considered in the future. Poka method. This is similar to planning poker. It is a quick and easy method to group items as per their relative priorities. Category is used here can be very high priority, high priority, medium priority, low-priority, very low priority. The steps are similar to that of planning poker. Oh, participants are giving cards representing these values. We can use another sets of values like high, medium, and low. That's his prioritizing using only three categories. Fast. The moderator presents the backlog item to be prioritized. He clarifies a requirement and each participant selects his or her COD. Oh, participants show that selection at the same time. If there are any differences that will be discussed and the process continues. Video feature. This is kind of a cumulative bidding 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. The moderator introduces all the backlog items to be prioritized. After that, each participant distributes the amount among these items based on his take 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. They include methods like Canaan modal, stack ranking, weighted shortest job first, which is ws j, f by a feature, etcetera. Whatever be the modal used in the final decision on the odour is from the Product. Owner. Planning is done at different levels in the Scrum. It all starts with a product division. We will have a high level plan at the release level. Every sprint starts with a sprint planning meeting. Every day, developed, collaborates and plan their activities for the next 24 hours during daily Scrum. A few more points to note here. Ah, planning is not a onetime activity. We inspect and adapt the plan has more knowledge is available. Agile plans or adaptive? No predictive. We adapt the plans to the changes. Plans will change as more knowledge is available. There will be a high-level plan at the release level based on what is known. But this is not a frozen contract. This gives an overall view of 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 as the number of iterations required are repeat. This is based on what is known so far. We have already seen this image. We will add it again for the completion of our discussion. Based on their predictive velocity, we can map the stories across different iteration output from the story mapping exercise parties and dependencies will play a crucial role in this mapping. This activity can be done as a continuation of the story mapping exercise. 6. Requirements During Scrum Events: Hello, welcome back. We will discuss different prescribed events and activities in Scrum processes, these requirements, products backlog refinement is the act of adding detail, estimates and order to items in their product backlog. It is an ongoing activity for our owner owns this meeting. Scrum Master helps him in organizing it. No time books is specified for this activity, but it should not block sprint activities. This activity can be useful to write user stories, expand at more details, et cetera. Breakdown user stories that are too big. Improve user stories that are poorly written. Estimate backlog items at acceptance criteria. If not already done. Look deeper into the backlog to do longer range technical planning. It typical product backlog grooming, old back local refinement activity can have two parts. The first part we will concentrate on requirement clarification and adding more detail to the Product Backlog. In the second part, we'll do an estimation for the user stories. During the sprint deselected requirements, that is, backlog, items will be converted to a walking Product Increment. Throughout this process, the product owner will be available for answering the questions and clarifying the requirements. 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. Sprints containing consists of Sprint Planning, Daily scrums, that development work, The Sprint Review and Sprint Retrospective. Sprint is time books to one month or less. During the sprint team creates a done, usable, and potentially releasable product increment. There is no gap between sprints and you. Sprint starts immediately after the conclusion of the previous sprint. Sprint goal is finalized during sprint planning. During the sprint, no changes or loud that would endanger the Sprint goal. Scope may be clarified and renegotiated between the product owner and developer as more as Lund. A spring can be cancelled before the sprint time box is over. It is a decision from the Product Owner. Only the product owner has the authority to counsel the Sprint. A Sprint would be canceled at the Sprint goal becomes obsolete. This will be a rare case as a sprint duration is shorter. Sprint planning is a formal entry point for the requirements to the actual development. Based on the priorities that team selects, 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 sprint is planned at this sprint planning. This plan is created by the collaborative work of the entire Scrum Team. The Scrum Master ensures that the event takes place and the attendance understand its purpose. Sprint planning is time books to a maximum eight hours or one month sprint, but shorter sprints, the event is usually shorter. Sprint planning is the first activity of the Sprint. The inputs to sprint planning. The Product Backlog where we have the ordered estimated list of requirements, the Latest Product increment. We should be knowing what we have done so far. Projected capacity for the team during the sprint. This assesses the availability of the team. We will consider leave plans, holidays, etc. Past performance of the team, the current speed performance, or in other words, the velocity of the team. Sprint planning answers the following questions. What can be done in this sprint? How are we going to get done? In simple words, sprint planning decides what can be delivered and how it can be delivered. The what and how aspects of the sprint Brahman team decide what can be done this sprint, the usual process includes the Product Owner explains the objective that the sprint should achieve, and discusses the Product Backlog Items that if completed in this sprint. To achieve this objective, decides in the number of items that can be selected from the product backlog for the Sprint. Then the scrum team crops a sprint bowl that gives guidance for the team during this sprint. It is an injective that is will be met within the sprint through the implementation of the product backlog. Besides how will the chosen work get done? Developer decides how it will build this functionality into a done Product Increment during this sprint. Usually starts by designing the work needed to convey the product backlog into a walking Product Increment. Work plan for the first days of the sprint by the team is decomposed by the end of this meeting. Often two 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, team can renegotiate the selected Product Backlog Items with the product owner. As we have seen in the previous slides, the sprint goal is an objective set for the sprint that can be met through the implementation of selective Product Backlog Items. It provides guidance to the team on why it is building the increment. By the end of the sprint planning team should be able to explain how it intends to work as a self-organizing team to accomplish the sprint goal and create the anticipated increment. The Sprint goal, the Product Backlog Items selective for this spring plus the plan for delivering them is cooled. The sprint backlog is responsible for creating and maintaining the sprint backlog. Plan usually takes form of engineering tasks and other work items were meeting the definition of done for the selected uses story. These tasks are usually estimated in hours or days. Teams start to have known tasks at the time of Sprint Planning. As development progresses, tox may get added. Sprint backlog can grow in size. It is a live document. Keeps updating it throughout the sprint duration. As a good practice team, make sure that sprint backlog is updated before all during daily scrum. At any point of time, the total estimated f four unfinished tasks and sprint backlog gives the amount of Identify what remains in the sprint. As sprint progresses, new tasks may get added, resulting in a temporary increase in remaining effort. During the daily scrum develop, inspects the progress of converting the selected requirements into tested, shippable increments and make necessary adjustments. The Daily Scrum is a 15 minutes time-boxed event for the developer to synchronize activities and creates a plan for the next 24 hours. Daily Scrum is conducted by developing and Scrum Master. Make sure this event happens effectively. Usually takes to format of three questions. Every team member ANSYS three questions. What did I do yesterday that helped him meet the sprint go? What will I do today to help team meet the sprint go? Do I see any impediment that prevents me or the team from meeting the spring go. Remember, can decide the format of this meeting. The intention, the expected value of the meeting is important. The three questions format is not mandatory, but it is 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, Identifies impediments to development for removal, highlight challenges and promote quick decision-making. Improves the themes level of knowledge. 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 discussed the future actions. This may result in new requirements. We're improving the existing ones. Let's discuss this advent in participant in detail. But it goes up the sprint review is to inspect the outcome and to remain foods of adaptations. A sprint review is housed at the end of the sprint to inspect the increment and adapt the product backlog if needed. This meeting concentrates on the outcome from the sprint. They discuss what was done in this sprint and what are the next things that can be done to optimize value? This is an informal meeting. This is not a status meeting. Team will present the increment to the participants. The increment is presented to elicit feedback and foster collaboration. Attendees include the scrum team and key stakeholders invited by the product owner. This is our time books and maintained for one month sprints. For shorter sprints, It will be shorter. In other words, it is time books to four hours. The Product Owner explains what product backlog items have been done and what has not been done. Team demonstrates the work that has been done and answers questions about the increment. The product owner discusses the backlog as it stands and projects likely completion dates. The entire group collaborates on what to do next. The results of the sprint review is a Revised product backlog that defines the probable product backlog items for the next sprint. The product backlog may also be adjusted to meet new opportunities. Sprint Retrospective is an inspect and adapt event for the scrum team. Why is it relevant and requirements 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 book was all splinter prospect TVs do land-based to increase quality and effectiveness. The sprint retrospective is an opportunity for the scrum team to inspect itself and creates a plan for improvements to be an active during the next sprint. The Sprint Retrospective occurs after the sprint review and prior to the next sprint planning. This is a three hour time books to meeting for one month sprints. There's a meeting inspects how the last sprint with regards to people, relationships, process and tools, and identify and order the major items that went well and potential improvements. Sprint retrospectives 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 to give a structure for the discussions. What went well, what didn't go well? What are the points to improve? Team discusses around these points and comes out with an action plan. Instead of attacking all items at recommends to concentrate on a few items which can be tracked and achieve the incoming sprints. 7. Course Summary: Hello, welcome back. A summary of our discussion is shown, hey, 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 subsets of requirements are selected for the Sprint. This elected items and a plan for implementing them are available in the sprint backlog. During the sprint. And convert this electric backlog items to test it shippable product increment. During this process, they clarify the requirements and may renegotiate them with the product owner. Conducted daily scrum. During the daily scrum, the progress towards creating the increment is inspected. The Product Increment is reviewed during the sprint review. Discussions may result in changes to the Product Backlog. Sprint Retrospective, inspect the process and finds out areas of improvement. 8. Outro Our Courses in SkillShare: We would like to provide an overview of our course is on the the the the the the, the opinions.