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

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 27m)
    • 1. Intro: Course Introduction

      1:31
    • 2. Agile Software Development

      12:30
    • 3. Scrum Framework

      11:08
    • 4. Requirement Basics

      23:58
    • 5. Managing Requirements

      20:03
    • 6. Scrum Events Handling Requirements

      15:01
    • 7. Course Summary

      1:34
    • 8. Outro: Our Courses Skillshare

      1:12

About This Class

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

Transcripts

1. Intro: Course Introduction: hello and welcome to this course and a jar requirements. He We will discuss how requirements are handled in scrum framework. This course starts with discussions and agile software development and 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 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 summarise our discussion using a simple image of scrum framework. 2. Agile Software Development: Hello. 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. First, there 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 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, 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 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. This traditional approach is heavily reliant upon a project manager driving the way if we go for a definition from Wikipedia, It say's agile software development is a group of software development methods based on iterated, an 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 boxed iterative approach and encourages rapid and flexible responses to change. It is 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 iterated and incremental development approach. We're requirements and solutions evolve through collaboration between self organizing cross functional teams. It promotes adaptive planning, evolutionary development and delivery, a time box literate of approach and encourages rapid and flexible response to change. Nigel is an umbrella term for different methods such as XP Scrum and D S. D M. Agile is much more than a new process. It is a culturally different way of building products compared toe the traditional methods . In nutritive model, the entire development is split into a number of parts. Instead of having a long single phase, the development happens in different, smaller interational. It's a writ of development is a way of breaking down the software development off a large application into smaller chunks. An intuitive development software is designed, developed and tested in repeated cycles. As the name suggests. In the incremental model, the development happens in incremental way. Instead of delivering all at once, we start with an initial one and keep adding increments to it. The incremental build model is a method off software development where the product is designed, implemented and tested incrementally. That is, a little more 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 organisation toe organize and manage their own work. A cross 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 . In adaptive planning, we define an overall plan the start, but this 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 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 air delivered earlier than later. It's increases project transparency and visibility by having multiple iterations off the end to end development cycle rather than one interational I. John methods welcome changing requirements. It addresses evolving requirements and re prioritizes as needed. Reduced risk and overall cost with short delivery cycles and testing early and often toe identify potential issues early in the project. Business and developers work together throughout the project. It improves collaboration and alignment with business organization In traditional approach plan is a one time activity, but in agile planning is done at different levels. You will have an initial up front planning at the start and just in time planning in it. Orations. In traditional approach, the project manager plans for the team, but in an Angel team is empowered and participates in planning in traditional approach, detailed requirements. A captured and frozen up front. 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, but in agile requirements are captured in the form of user stories or use cases in a simple way in traditional approach, limited client collaboration After requirements definition. What an agile we collaborate with client throughout the Project Life cycle a recent survey list down many benefits has listed here. You can visit the website given below for more details. A few of the drivers are ability to manage changing requirements, more visibility, more productivity at a time to market. That's a business alignment, etcetera. These are mainly due to the issues with the understanding off a job, and issues with its implementations may not be problems with agile. There are situations where documentation is ignored completely. A job demands more time and energy from everyone because developers and customers must constantly interact with each other. At times, it is difficult to ensure this involvement as agile welcomes change in new requirements. The project can become ever lasting because there's no clear end and scope creep may happen at times. An overall plan in the beginning may not be enough for the clients who work on a specific budget or schedule. They can't predict how much the project will actually cost. Teams can get focused into delivering new functionality at the expense of tico debt, which increases the amount of, um, plan work. When should we use waterfall over scrum? You might not have come across this so far, but we can try answering from our understanding, this could be an imaginary answer. For an ideal situation, you may prefer waterfall. If the requirements are very clear and frozen, the customer won't demand any changes. The customer is not ready for frequent interactions. The project is small. Time to market is not important. These can be a fusion. Oreos ajar reduces time to market by delivering the right scope at the right time. Not all at once. It is better aligned with business priorities. It follows short delivery cycles, an incremental way of delivery, and John methodology is inherently reduced risk in product development. They do it by using many approaches, including short delivery cycles, early testing, an early customer feedback, continuous delivery prioritization influenced by risk and value. High visibility risk identification. J R T stands were just in time. In this approach, we have a high level plan for a long duration, a detailed plan for a short duration. Detailed plans are created at the time there 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. He will start our detailed discussion on scrum. Scram is founded. Um, empirical process Control theory Empiricism asserts that knowledge comes from experience and making decisions based on what is known. The empirical model of process control provides an exercises control for processes that I am perfectly defined and generate unpredictable on unrepeatable outputs. This is done through frequent inspection and adaptation. There are pillars of empirical control. They are transparency inspection on adoption. We do inspect and adapt throughout the duration of the project. Formal events defined them scrum sets the minimum frequency for this scrum guide stays scrum Users must frequently inspect scrum artifacts and progress towards a sprint goal to detect undesirable variance sees their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work. If we go for a definition from the scrum guide, it states Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value. Scrum is a lightweight framework which is simple to understand but difficult to master scrum works with its orations or sprints of 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 iterated, incremental development and delivery. It follows adaptive rather than predictive planning. It promotes collaboration among all parties involved. We can sell arise basics of scrum scrum is it? It's narrative An incremental, agile software development framework for managing software projects and product or application development. Sprint is a time boxed 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. There are values, commitment, courage, focus, openness and respect. People personally commit to achieving the goals of the scrum team. The scrum team members have courage to do the right thing on Dworkin Tough problems. Everyone focuses on the work of the sprint and the goals of the scrum team. The scrum team and its stakeholders agreed to be open about all the work and the challenges with performing the work. Scrum team members respect each other to be capable independent people. Let's start with scrum processes every software project is intended to convert a number of requirements in tow. Working software, an increment or change strong, follows an attractive and incremental approach. The work is carried out in multiple iterations called Sprints Sprinted a time box to a maximum of one month. The purpose of the Sprint is to create a potentially separable increment of working software before getting into the details of this process. Let's discuss different roles defined and scrum. The development team consists of professionals who do the work of delivering A potentially releasable increments off done product at the end of each sprint. Only members off the development team create. The England Development Teams are self organizing. They decide how they're going to create a ship herbal increment at the end of the Sprint Development teams across functional. They have all the skills required to convert the selective requirements into the done ship herbal increment. The product owner is responsible of maximizing the value of the product resulting from work of the development team. He owns the requirements. This activity consists off detail ING backlog items, ordering or 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 ensures that the scrum is understood on enacted by the team. He or she facilitates the scrum events as required. Scrum Master. Make sure the impediments for the development are removed. The product owner, the development Team and the scrum master together referred as the scrum team. Product backlog captures all the requirements needed to be included in the product. This is created and maintained by the product owner. The product backlog is an order list of everything that is known to be needed in the product. Sprint Start with a Sprink planning meeting. This is time books toe 88 hours for one month sprints for shorter sprints. It a usually shorter product own, explains the product backlog items and sets the Priorities Development Team. Select items were upcoming Sprint based on their capacity team velocity the size of the work that they have successfully deliver. Sprint helps as a guideline while deciding their capacity for the next sprint. Together, the scrum team agree upon the sprint gold. In the second part of the planning meeting, the team create an initial plan for converting the selected items to a ship herbal increment. This may be in the form of technical task for each elected item or may only be for items to start with the selected backlog items with a plan for achieving it. Make the sprint back look, the development team owns a sprint back up and keep it updated. Throughout the sprint. The development team start working on the selected backlog items towards creating the increment To achieve the sprint gold. They do design, development and testing all in the same sprint. They will do whatever required to achieve the sprint gold. Every day The development team does a daily scrum meeting. These are 50 minutes duration. This takes the form of a stand up meeting where the development team collaborate on decide on actions to be done before the next daily scrum. It is kind of a quick daily planning. Normally it takes a former every member answers three questions. What I have done since last daily scrum for achieving the sprint goal. What I'm going to do till next daily scrum a My seeing any threats for the sprint goal at the end of the sprint. The scrum team and other stakeholders is invited by the product owner. Conduct a Sprint Review. This is time books two 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 battle during a sprint, attendees collaborate on the next things that could be done. This is an informal meeting, not a status meeting and the presentation of the increment is intended to elicit feedback and foster collaboration. The Sprint retrospective is an opportunity for the scrum team to inspect itself and create 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 did 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 a nutritive and incremental way. As mentioned before the development team create tested and ship herbal increment at the end of each rent, it may get deployed as it is or wait for further increments. However, the development team will keep on producing ship herbal increments. So we have discussed different rose events and artifacts in scrum. This is a quick visit. We will discuss these in details incoming modules as we have already seen. There are three rows, three artifacts and four ceremonies and scrum. The Rose, our product owner development team and the scrum master. The ceremonies are Sprint Planning Daily Scrum spent review Sprint retrospectives, the artifacts or product backlog, Spring 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, on were 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 visa requirements In 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 or the requirements up front 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 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. Re you revisit our estimates and make corrections to the plan. We can't do everything. First we deliver in a nutritive, an incremental way proper ordering off the backlog items make sure that most valuable items are delivered earlier. Prioritization is a key aspect in the back. Drug 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 purpose of a product, the intention with which the product is being created on what it aims to achieve for customers or users. It describes the purpose of your product, why it is being built. What are the expected benefits? It gives a bigger picture of what we're 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 goes. 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. This keeps ever unmotivated toe work towards achieving the goals. Ah, product vision statement must be expressed in the proper format which is suitable for the products 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 competitive product, all product gives an edge or makes a key difference. An example can be for a jar enthusiasts who want to be a successful product owner. The product owner training is an online course that teaches the art of product ownership. Unlike other courses are product gives the to the point training with less duration and more value. The product of 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 for its 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 background any time during the project. It is a prioritized list of requirements that provide business value for the customer for its own, is responsible for creating and maintaining requirements. The team can contribute in this activity team can get involved in this activity with maximum off 10% of their capacity. The final decision on the order of items in the product back drug is from the product owner . However, other roles can influence these decisions. One of the commonly used models is Moscow, where back love items are categorized as must have, which is a minimum usable subset. Should have. Could have or won't have. We would like in future. Other approaches for ordering include those based on business value. Risk based que no model, etcetera. A product backlog contains different times of iTunes, like story based work, task based work, etcetera. In short, everything that is required for the product. Higher ordered product back Loeb items are usually smaller, clearer and more detail than lower ordered ones. Proud owner is responsible for maintaining pull it back drug, but the estimates must come from the people who do the work. The development team is responsible for all estimates, De e P stands for detailed, appropriately emergent, estimated prioritized. We have discussed all these aspects for up to 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 list with an estimate based on what is known a healthy product. Back drug 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. Alicia be prioritized an estimated based on the availability off information. As good practice teams make sure there is enough ready user stories for upcoming and number of Sprint's. This number will be agreed upon by the scrum team. A user story is a requirement written in an end user perspective. A user story describes functionality that will be valuable to either a user or a purchaser of a system or software. These air 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 USIA. I want to do something so that I get this benefit, for example, as a user, I want to see the less of all emails received so that I can select one for viewing the three C's for use a story. Ah cod conversation Confirmation card indicates that they use the story should be smaller. Love for a single card conversation talks about the detail ing part detail ING will be a result of further discussions in collaboration or details will be attached or added to the user 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 acceptable criteria. Slug is a story or task aimed at answering a question or gathering information rather than at producing ship herbal product. The purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understanding of a requirement or increased the reliability of a story. Estimate larger user stories a typically refer to as epics. Epics generally take more than one or two sprints to develop and test. They're usually broad in scope. Short on details. It must be submitted to 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 users stories that share a common attribute. They're group together for convenience. For example, we can have a theme communication. All stories related to customer communication can be grouped and tracked. Under this, Things are often used to organize stories into releases or to organize them so that various sub teams can welcome them. A good users 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 is 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 it changes. As more knowledge is available, a user story should be valuable to customers and users, not developers. It should be written to reflect user or client perspective. They use a 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, large stories should be split into smaller ones. A user story must be testable. The confirmation attributes that we have discussed earlier must be stated. Clearly. The users story 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 to smaller user stories. Scrum teams will decide to what extent the story should be fine grained based on the nature of work. Maybe we can consider an epic as ready when all user stories derived from it. Already. Acceptance criteria is a set of pre established conditions that the product increments just satisfy to be accepted by the user. It was also known as Conditions of satisfaction on will be provided by product owner. It can include functional and nonfunctional elements. It should be expressed in simple language without leaving room for any ambiguity. Acceptance criteria is written in simple language defies the conditions of success or conditions or 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 template of 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 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. No other role is able to create users, and admin can create user with user name email. I d mobile number system displays a message of any of the above. Fields are missing and user is not created. System sends an email to the user. Once the account is created, the list can go on definition of ready for use. A 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 right amount of story points. It is estimated. Story is clearly understood by the development team. Accepted criteria, a clear and testable dependencies identified and no external dependencies were broke. The story from being completed is this. Test dates are required to test the story has been identified. Performance criteria if any are defined immeasurable. The story is small enough to be comfortably completed in one sprint definition of dumb for users stories, a set of pre established conditions for confirming the same as done. It is not the same as acceptance criteria. Meeting the acceptance criteria will be an automatic selection to the list because it has many aspects like organisational processes, standards, legal requirements, etcetera. It is agreed upon the development team and the product owner. It will be inspected in regular intervals and improved. It is not a frozen document. It can be defined for Sprint and release as well, checklists confirming if the sprinter releases done in all aspects instead, a simple user story as an admin. I want to great users, so that's a homegrown access to the system. Items in the definition of Duncan include Use a story, meet acceptance criteria and reviewed by the product owner. All co changes are reviewed as prescribed. The quality manual and major findings are closed. Co changes are checked. Two X y Zed brunch. The list can go on definition of dumb for a spring. Confirms that will require 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 springtime met. All unit tests start passing. Product backlog is updated. Increment is deployed on the test environment identical to production platform. The performance tests past OH, category one Bugs are fixed. Completed user stories are accepted by the product owner. These are a few examples. There can be more or less items, depending on the nature of the project. Definition of done. D o d for release confirms that all require task and other activities for the release are completed. It can include but not limited to code. Complete reached environments are ready for release. Old test results are green. All the acceptance criteria are met. Huet is done. A new issues resolved Green baseline, no open issue and build an integration released documents already. These are a few examples that can be more or less items. Depending on the nature of the project. There are different estimation techniques in use. Traditionally, we use techniques like Luns of code function. Points use case points, etcetera. In agile, we used techniques like story points, tee shot sizing, ideal days, etcetera, 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 absolutely units of time, but in comprising 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 story points are two examples of relative estimation. Story point is an arbitrary measure used for scrum teams. Issues 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 you take? Considering many factors like complexity, uncertainty and risk, etcetera, it is a faster way of estimating people who do the work. The development team is responsible for making this estimate. A frequently use scale is the Fibonacci. Siri's story Points are a unit of measure for expressing the overall size of the users 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 nonlinear. Frequently used scale is Fibonacci, Siri's etcetera. We use a set of numbers that makes sense. We may use a modified Fibonacci Syriza's well like 01 2358 13 and 2040 etcetera. Larger stories epics can have a range like 102 100 etcetera. 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 smooth 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 it follows the below steps. First, the product only provides a short overview of the story, to be estimated, the team discusses to clarify assumptions and risks on the outcome. Off the discussion is updated in the user's story. Each individual is given a set of cards with the values that are used. Usually the cards are with Fibonacci numbers. Each individual selects a card representing their estimate and lays it down. Everyone shows that card Simula Tennis Lee 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. 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 expected 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 shed understanding on the story or the work related to it . The story should be parts for further grooming. 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 one time activity at earliest stages at epic or feature level. Estimates will be it a high level. Once requirements reached the level of users stories, we will do a relative estimation with story points while doing this Sprint planning. We will create task for each story, which will be estimated using ideal days or ideal hours. 5. Managing Requirements: Hello. Welcome back. We will discuss a few approaches for gathering requirements. A few points to note are requirements of O's. 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 C's that we have discussed as part of user stories? Conversation is the key element in detail ing the requirements. Throughout this process, we focus on the business on 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. Define right set of questions and interview the stakeholders on a 1 to 1 basis selection off. The right interviewee is important. We must identify the persons with right nor knowledge on the product. He or she should be able to clearly described the expectations identified different user roles, interacting with the system, prepare sets of questions. For each role, we must define the right set of questions. The questions should facilitate the four. Process off the interviewee over an open ended context. Free questions in the beginning to get a why. Perspective 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 visual impact. This could be done using wire frames, sticky notes on white board, a simple physical modelling, etcetera something in front of their eyes. The 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 architecture 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 etcetera. A few other methods that we can consider can be brainstorming document analysis, Focus Group interface analysis, observation requirements, workshop survey Use a 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 Does 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. 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 sorts based on price filter on user ratings. If we convert them to use the stories, there can be many stories like as a user, I want to search based on the date and location so that I see the availability. As a user, I want to sort the list on price so that I can select a room as a user. I want to filter the list on rating so that I can select a room like this. We can analyze a map different features off the product. This brings in a shared understanding among all parties evolved. This helps in breaking down important features of the application. As we have all main stories on the board during a relative estimation becomes easier. It helps him prior to presentation and release planning. We split the stories based on functionality, not based on technical layers. All stories will cover all technical layers required for its implementation. This approach is called Slicing the cake. In other words, we should not spit user stories based on architectural layers. It should be done based on functionality. Each slice should have a part of all the layers. 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 effort, simple or complex, split to using crowd, which is create read, update, delete operations, variations in data data entry methods spike First split at basic or exception path differ performance in the coming slides. We will see examples with 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 slice should have a part of all the layers. Workflow steps. When I use a story involves workflow of some kind. The item can be usually broken down into individual steps. Consider the users story. As a customer, I want to shop online so that I received my products at home. There are different steps involved in this process. We can split the story based on them. Two. Among the resulting stories can be as a customer. I want to log in to the online stores that I can shop as a customer. I want to view my shopping cart so that I can do a check out 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'll receive 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 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 it's variations, we will break out the variations and implement the major effort. First, consider the users story As a customer, I want to pay online with Visa, Amex or MasterCard's. So that's our received my products at home. The major effort here will be using the payment infrastructure once it is in place. Other cards can be added with less effort. Two. Among the resulting stories can be as a customer. I want to pay using 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 MasterCard so that I can shop online, simple or complex. Start with a simple implementation and adds more functionality later. Consider the users story as customer. I want to search for hotels so that I can make a booking two. 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 crowd. 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. Two. 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 I can buy them online. Two. 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 process A type and RAM so that I can buy them online Data entry methods on input form can be filled and saved using different ways. The first manual, 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 fancy user interface later. Two. 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 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. Traitor Spike for experimenting with online payment gateways. This will reduce the unknowns regarding the functionality trade user stories based on the results of this experiment split a basic or exception path start with a simple implementation and go for exceptional cases. Consider the user story. As a customer, I want to search for hotels so that I can make a booking. We will start with a normal, simple flow. Two. 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. 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, differ performance, make it work, then make it fast. Make the functionality work before going for optimization. Consider the users story. As a customer, I want to search for hotels so that I can make a booking. Two. 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 second book faster. There are many other methods used for breaking down user stories, including based on test scenarios or test cases based on rose based on acceptance criteria . and based on external dependencies, etcetera. 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 the business value. Market demand, teen capability, risk dependencies, etcetera. 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. Full 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 if time and resource is permit. 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 hoca 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 very high priority. High priority, medium priority, low priority, very low priority. This steps are similar to that of planning poker. All participants are giving cards representing these values. We can use another set of values, like high, medium and low, that is prioritizing using only three categories. First, the moderator presents the backlog item to be prioritized. He clarifies a requirement in each participant selects his or her card. All participants show their selection at the same time. If there are any differences that will be discussed on the process, continues bidder feature. This is kind of a cumulative bidding method. All participants are given the same amount of money, say $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 or her 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 que no model stack ranking waited shortest job first, which is WSJ F by a feature. Etcetera. Whatever be the model used in the final decision on the order 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 the Sprint planning meeting Every day, Development team collaborates and plan their activities for the next 24 hours during daily scrum. A few more points to note here are planning is not a one time activity. We inspect and add up the plan. As more knowledge is available, agile plans a reductive no predictive. We adopt 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 it orations. 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. Our 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 the predictive velocity, we can map the stories across different alteration output from the story. Mapping exercise priorities in dependencies will play a crucial role in this mapping. This activity can be done as a continuation of the story mapping exercise. 6. Scrum Events Handling Requirements: Hello Welcome back. We will discuss different prescribed events and activities in scrum that processes these requirements. Promotes backlog. Refinement is the act of adding detail estimates in orderto items in the product back look , it is an ongoing activity for its owner owns this meeting. Scrum Master helps him in organizing it. No time box is specified for this activity, but it should not book sprint activities. Teams can spend a maximum of 10% off their time in backlog grooming activities. This activity can be useful to write user stories expand. Add more details, etcetera, breakdown user stories That's a too big improve user stories at a poorly written estimate backlog. Items at 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. The first part. We will concentrate on requirement clarification and adding more details to the product backlog. In the second part, development team will do an estimation for the user stories during the sprint. The selective requirements that is backlog items will be converted to a working product increment. Throughout this process, the product owner will be available for answering the questions and clarifying the requirements. Development Team may re negotiate the requirements with the product owner to enhance the possibility of achieving the sprint goal. We can consider the sprint itself as the longest event in scrum sprints contain and consists of Sprint planning, daily scrums, the development work, the Spirit Review and the Sprint retrospective. Sprint is Time books toe one month or less during the Sprint Development Team creates a done usable and potentially releasable product increment. There is no gap between sprints. A new sprint starts immediately after the conclusion of the previous sprint. Sprint Gold is finalized during spring planning. During the sprint, no changes are allowed that would endanger the sprint gold scope may be clarified and re negotiated between the product owner and development team. As more is learned, a spring can be council before the sprint time boxes over. It is a decision from the product owner. Only the product owner has the authority to cancel the sprint. A sprint would be cancelled of the shrink goal becomes obsolete. This will be a rare case as a sprint duration is shorter. Sprint planning is a formal entry point for the record, The work to be performed in sprinters planned at this spring. Planning this plan is created by the collaborative work of the entire scrum Teen. The scrum master ensures that the event takes place on the attendants. Understand it's purpose. Sprint planning is time books to a maximum of eight hours for a one month sprint. A shorter sprints. The event is usually shorter. Spring planning is the first activity off the sprint. The imports 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 development team during the sprint. This assesses the availability of the team we will consider leave plans, holidays, etcetera past performance off the development team, the current speed performance or, in other words, the velocity of the team. Sprint Planning answers the following questions 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 decides what can be delivered and how it can be delivered. The what and how aspects of the sprint In the first part of spring planning, the scrum team decides what can be done. This sprint, the usual process includes the product owner explains the objective that the strength should achieve and discusses the product backlog items that, if completed in the sprint, would achieve this objective. The development team decides in the number of items that can be selected from the product backlog for the sprint in the scrum Team Crofts, a Sprint Bowl that gives guidance for the team during this sprint. It is an injected that will be met within the sprint through the implementation off the product backlog. In the second part of Sprint planning, the development team decides how will the chosen work get done? Development Team decides how it will build this functionality into a done product increment during the sprint. The development team usually starts by designing the work needed to convert at the product backlog into a working product. Increment Work plan for the first days of the sprint by the development 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 selective product backlog items on make trade offs if required. Development Team can re negotiate the selective product backlog items with the product owner as we have seen in the previous slides. The Sprint Gold is an objective set for the sprint that can be met through the implementation of selective product backlog items. It provides guidance the development team on why it is building the increment. The scrum guide say's By the end of the script planning, the development team should be able to explain the owner and scrum master how it intends toe work as a self organizing team to accomplish the sprint goal and create the anticipated increments. The product backlog items selected for this spring plus the plan for delivering them is called the Sprint Backlog. Development Team is responsible for creating and maintaining the Sprint backlog plan usually takes form of engineering tasks. On other work items were meeting the definition of done for the selected users story. These tasks are usually estimated in hours or days. Development team starts have known tasks at the time of Sprint planning. As development progresses, Tark's Maiga added. Sprint backlog can grow in size It is a Live Document development team 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 effort for unfinished tasks in Sprint backlog gives the amount of identified work remains in the sprint. As sprint progresses, new tasks may get added, resulting in a temporary increase in remaining effort. During the daily scrum, the development team inspects the progress off, converting the selective requirements into tested ship herbal increments and make necessary adjustments. The daily scrum is a 15 minutes time boxed event for the development team to synchronize activities and create a plan for the next 24 hours. Daily Scrum is conducted by Development Team and Scrum Master. Make sure this event happens effectively. Usually it takes the format of three questions. Every team member answers three questions. What did I do yesterday that helps the development team meet the shrink Go? What will I do today to help the development team meet the sprint? Go Do I see any impediment that prevents me or the development team from meeting the spring ? Go Remember, the development team can decide the former off 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 improved communications, reduces the need for other meetings, identifies impediments to development for removal, highlight challenges and promote quick decision making improves the development teams level of knowledge. Moreover, it is an inspect and adapt meeting during the Sprint review. The product increment is a sprint review is how did 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 discussed what was done in the sprint and what are the next things that could be done to optimize value. This is an informal meeting. This is not a status meeting. The development 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 a full hour time books and meeting for one month sprints for shorter sprints. It will be shorter. In other words, it is time books to four hours. The product only explains what product backlog items have been done on what has not being done. The development team demonstrates the work that has been done on 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 results of the Sprint Review is a revised product back look 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 on requirements? Management items like definition of done and definition already 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 Scream retrospective is an opportunity for the scrum team to inspect itself and create a plan for improvements to be an active during the next sprint. The Sprint retrospective. Because after the spring review and pride to the next spring planning. This is a three hour time. Books to meeting for one month sprints. This meeting inspects how the last moment with regards to people, relationships, process and tools, and identify and order the major items that went well on 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 to give a structure for the discussions. What words? 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 oil items, it recommends to concentrate on a few top items, which can be tracked and achieved incoming sprints. 7. Course Summary: Hello Welcome back. A summary of our discussion is shown here. Product backlog captures all the requirements required for the product. They are detailed Grunde ordered and maintained in the product backlog. During the sprint planning, a subset of requirements are selected for the sprint. The selected items and a plan for implementing them are available in the sprint backlog. During the sprint, the development team convert the selected backlog items to tested ship herbal product increment. During this process, they clarify the requirements and may re negotiate them with the product owner. The development team conducted daily scrum during the daily scrum. The progress towards creating the increment is inspected. Their product increment is reviewed during the Sprint Review Discussions. MARY result in changes to the product backlog Sprint retrospective, inspect the process and finds out areas of improvement. 8. Outro: Our Courses Skillshare: we would like to provide an overview of our courses on agile and scrum.