Product Owner Training: Agile Product Ownership with Scrum | Jimmy Mathew | Skillshare

Playback Speed


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

Product Owner Training: Agile Product Ownership with Scrum

teacher avatar Jimmy Mathew, Agile Consultant

Watch this class and thousands more

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

Watch this class and thousands more

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

Lessons in This Class

16 Lessons (2h 2m)
    • 1. Course Introduction

      1:15
    • 2. Agile Software Development

      8:48
    • 3. Agile Manifesto and Principles

      10:49
    • 4. Agile Methodologies

      9:05
    • 5. Scrum Framework

      12:09
    • 6. Requirements

      15:03
    • 7. Estimation

      6:39
    • 8. Planning

      8:05
    • 9. Scrum Events

      5:44
    • 10. Scrum Roles

      2:42
    • 11. Monitoring

      4:45
    • 12. Product Owner Role

      7:52
    • 13. Managing Requirements

      23:49
    • 14. Product Owner Role In Scrum Events

      3:34
    • 15. Summary

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

170

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)

Detailed training for Product Owner Role in Agile software development with Scrum. This course discusses different responsibilities and activities performed by product Owners, a quick discussion on Product Owner skills and a detailed discussion on different techniques used by Product Owners in managing requirements during Agile software development using Scrum.

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 is for anyone who wish to learn about “Product Ownership” in Agile software development. This course is helpful for anyone who is playing the role of product owner in agile software development or anyone who wish to become a product owner in agile software development using Scrum framework.

A basic knowledge of software development is helpful in taking this course. This course, in the first sessions has a detailed discussion on Agile software development and Scrum framework.

The course starts with topics on Agile software development and Scrum framework. Then it discusses the Product Owner role, activities and skills.

Then there is a detailed discussion on managing requirements, which is one of the main responsibilities of a Product Owner. This includes topics like, writing User Stories, User Story Mapping, Methods for splitting and ordering User Stories, Release planning, etc.

In the last module there is a discussion on Product Owner role during prescribed events in Scrum.

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 "Agile Requirements: Managing Requirements in Scrum Framework". Also a few topics from our scrum training.

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

These are the topics covered as part of this course.

  • Agile Software Development

  • Scrum Framework

  • Product Owner Role

           The Product Owner

           Product Owner Activities

           Product Owner Skills

           Scaling

  • PO: Managing Requirements

           Introduction

           Product Vision

           User Stories

           Product backlog

           Writing user stories

           User Story mapping

           Splitting user stories

           Ordering Backlog Items

           Acceptance Criteria, DoR, DoD

           Release Planning

  • PO Role in Scrum Events

  • Summary

============================================

*Professional Scrum™, Professional Scrum Master™, PSM, PSM I, PSM 1, etc. is the protected brand of Scrum org.

This course is neither endorsed by nor affiliated with Scrum org. This course uses content from the Scrum Guide. All the content related to Scrum Guide is taken from scrumguides org and is under the Attribution ShareAlike license of Creative Commons. Further information is accessible at http://creativecommons org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons org/licenses/by-sa/4.0/. 

======================================

Meet Your Teacher

Teacher Profile Image

Jimmy Mathew

Agile Consultant

Teacher

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

Publications  

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

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

Certifications

 

.      ICP-ACC - ICP Agile Coaching   

·      CSP – Certified Scrum Professional  

·      CSM – Certified Scrum Master  

·      SAFe - Scaled Agile Framework-Agilist  

·      PSM1 – Professional Scrum Master  

... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

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

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

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

Transcripts

1. Course Introduction: Hello and welcome to this course for product owners or for those who aspire to be a successful product owner. This core starts with discussions on Agile software development and Scrum framework. Then we move on to a role-based training for product owners. This slide shows the topics that we ought to cover as parts of this course. We will start with a discussion on agile software development. Then move on to a detailed discussion on Scrum framework. After that, we will start our discussion on the product owner role. We will see how requirements are handled in Scrum. Here we will discuss different methods for maintaining the product backlog. We will discuss different prescribed events in Scrum with a focus on the product owner role. 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 requirements 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 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 of both 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. In 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 model is a method of software development where the product is designed, implemented, and tested incrementally. Thats is, 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. 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. And adaptive planning, we define an overall plan, the start, but it does not frozen. Once work stops, 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. Jar 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. With this, we have reached the end of this module. In the next video, we will discuss Agile Manifesto and principles. 3. Agile Manifesto and Principles: Welcome to this module. Here we discuss Agile Manifesto and principles. In 2001, a group of 17 lightweight methodologist met in the Salt Lake Valley. The meeting included representatives of different methodologies existing at that time, like extreme programming, Scrum, D, SDM, adaptive software development, et cetera. They have come up with something cool, Agile Manifesto, which was written in the format a over b. It says, we are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration, over contract negotiation, responding to change over following a plan. Now the last sentence is very important. This is a point that will clear many of our questions. That is, while there is value in items on the right, we value the items on the left. More. Agile is not against process, documents, contracts, or plan, but there are other items that we value more. Let us discuss these items in detail. Individuals and interactions over processes and tools. Processes are good, but we should not underestimate the power of interactions and face-to-face conversations. We are not doing any factory work where a machine can produce n items in a given time. We are in a knowledge industry. Hey, the focus should be on empowered, self-managing, cross-functional teams. This doesn't mean that Agile is against a process and tools. They are required, but they should support these interactions. They are not for replacing the interactions. Working software over comprehensive documentation. Traditionally, we rely on a lot of documentation. We have a requirement phase where we created and sign off the requirements. Then a high-level, low-level design which create a detailed design document. All these are part of our project execution and have weightages associated. So we say that percentage of work is done, but we have not actually delivered anything that can be used by end-user. Our aim is to deliver value to the customer, not a big load of documents, working software, that should be our primary output and the measurement of our progress. It doesn't mean that we shouldn't know document. We should have the minimum required documents. Another issue is maintaining this huge set of documents. We have a detailed design specs and many times towards the end of the project, we need it to be obsolete because we don't maintain it. So go for minimum documentation, which is properly maintained. .net code talk for itself as much as possible. Customer collaboration over contract negotiation. What do we do? Traditionally? Customer gives as the requirements and we give them the product. In other words, customer throws the requirements over the wall and we throw the product back. In Agile, customers become part of a development process. Customer and vendor together tried to serve the end user. Agile never say that we should not have a contract. It is very important in facilitating everything. It gives us the authority to work and it guides us. But it shouldn't be flexible enough to, to support collaboration among all parties. Responding to change over following a plan. What we do traditionally, we have a big project. We plan it through completion. We have sequence of tags. We have the critical path, leads and lags, early start date, late finish dates, and so on. We start analyzing variants, may consider changes as an exception, but not in Agile. In Agile, changes are expected. We don't create such long detailed plans. We have a roadmap, an overall plan for a long time, and detailed plan for short future. We don't create a detailed plan on suddenly that we are not sure about. It is like we walked from a small distance, stop, look around and cover another distance. We plan. And the last responsible moment, we do plan but follow kind of a rolling wave planning. So we have covered the core of the Agile Manifesto. Let's have a relook individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration, over contract negotiation, responding to change over following a plan. Now let's review principles behind the Agile Manifesto. Agile principles says, Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. We have discussed the manifesto items, working software over comprehensive documentation. What customer needs this value? The working software. Notice set of documents. We proceed and a series of iterations and deliver increments frequently. Agile principle says, welcome changing requirements even late in development. Agile processes harness change for the customer's competitive advantage. We have discussed manifesto items, responding to change over following a plan. Agile approach strives to accommodate changes as efficiently as possible while maintaining an awareness of its consequences. Everyone agrees that constant feedback is great. But often ignores that the result of accepted feedback is change. Agile beliefs facilitating change is more effective than attempting to prevent it. Our job principle says, deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter timescale. This is read along with the first principle. We deliver frequent in shorter periods. This helps us to accommodate changes. As part of the changing values and customer feedback. Agile principles says, business people and developers must work together daily throughout the project. The key word over here is daily. It is no more throwing the requirements over the wall. We worked together with business and deliver the value to the end customer. Business gives us the direction and teams deliver the value. Agile principle says, build projects around motivated individuals, give them the environment and the support they need and trust them to get the job done. Great processes with state of the tools don't guarantee success. It is motivated self-organizing teams that defines success. We should provide them the support and trust them. Agile principle says the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. There is a famous statement. Knowledge cannot be transferred by getting it out of people's heads and putting it on paper. The best and most effective way of communication is face to face conversation. People interacting with each other comes out with more valuable results. A job principle says, working software is the primary measure of progress. We had discussed this point in detail. It is a value we deliver, not the documentation that define success. Agile Principle says, agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. The key word here is constant pace indefinitely. It is not working 24 hours. Seven from beginning and tired out towards the middle. It is not keeping all the work to a one month before release. It is all about maintaining a constant pace which can be sustained over a long period of time. Agile principle states, continuous attention to technical excellence and good design enhances agility. Design cannot be a purely up-front activity to be completed before construction. Instead, design is a continuous activity as performed throughout the project. Each and every iteration will have design work. Without design must be flexible and efficient to accommodate the changes. Agile principle says, simplicity, the art of maximizing the amount of work not done is essential. We make it simple. We tried to achieve maximum value with minimum work. We avoid unnecessary complexity both in process and in value. We concentrate on delivering value. We will try to avoid or postpone activities with lesser value and concentrate on the core activities. Agile principle says, the best architectures, requirements, and designs emerge from self-organizing teams. It is multiple brains that work in synergy. They organize themselves for the better results with the visibility that they have. And the results emerge from this self-organizing group. Agile principle says at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. This talk about the inspect and adapt aspects. Teams evaluate their performance in retrospect and comes out with ideas to improve. With this, we have reached the end of this module and the next video we will have a very short overview of different agile methodologies. 4. Agile Methodologies: Welcome to this module. Here we discussed different agile methodologies. This image is taken from the 12th edition of annual State of Agile report by version one, it shows Scrum still remains as the most used agile methodology. Also Scrum, Scrumban and Scrum XP hybrid together makes 70% of agile methodologies used. Let's start with a simple answer in our own words before going into the definition of the next slide. For example, Scrum as focusing on iterative, incremental development. Iterations are called Sprints. It depends on self-organizing cross-functional teams, delivering a potentially shippable increment at the end of every sprint. If we go for a definition from the Scrum Guide, it states, Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products or the highest possible value. Scrum is a lightweight framework which is simple to understand but difficult to Monster. Scrum works with iterations or sprints of max1 month duration. As we stated before, it focuses on self-managed, cross-functional teams. It ensures the continuous flow of value to customers through iterative, incremental development and delivery. It follows adaptive rather than predictive planning. It promotes collaboration among all parties involved. Scrum is one of the agile methodologies. It is the most used agile methodology. Agile is an umbrella term for several iterative and incremental software development methodologies, including Scrum. This training is concentrating on Scrum. We will have a detailed discussion on Scrum in the coming modules. Here, in this module we will have a quick overview of other agile methodologies. Now, let's discuss Kanban. Kanban for managing the creation of products with an emphasis on continuous delivery. While not over but during the development team. Each what I to move, pause through a series of process steps, will walk flow stages before it is done. Kanban means sign board or signal. It was initially developed as a scheduling system that is used in manufacturing to help companies improve their production process. In the late 19 forties, Toyota came up with Kanban system to implement just-in-time process to standardize the row of plots and net production lines. One of the main benefits of Kanban is to establish an upper limit to the walk and progress. Involuntary avoiding, overloading of the manufacturing system. Wip limits or work in progress limits is the maximum number of work items that can be in a particular stage of processing. This will avoid overloading of the production chain. This has been evolved into kanban system for software development and which most people now simply referred to as kanban. Kanban is a lean approach to agile software development. It has principles and core practices. The principles are, starting with existing process, agree to pursue incremental and evolutionary change. Respect the current process roles, responsibilities and titles, and leadership at all levels. The cool practices I'll visualize the flow, limit Work in Progress, managed flow, make policies explicit, implement feedback loops, improved collaboratively, and evolve experimentally. Lead time is the period between a new toss guppies and you'll work flow and its final departure from the system. This can be considered as the lifetime for an item in the system. So-called time begins at the moment when the new arrival enters in progress stage and somebody is actually working on it till it finishes. This will show the processing time took for an item. Response time is the period between a new Tosca pays in your workflow and enters the in-progress stage. This shows how much time an item has waited in the system before the walk has started on it. Throughput the amount of what items delivered in a given period of time. It shows the number of items processed by the system. We will discuss the differences based on various aspects like cadence, release methodology, rose, key metrics, scope of work, and response to change. In Scrum, we follow regular fixed length sprints of maximum one month duration. In Kanban, it is a continuous flow. In Scrum. We released at the end of each sprint if approved by the product owner or as decided by the product owner. In Kanban, it is a continuous delivery. Scrum defines roles, product owner, Scrum Master, and there are no Kanban specific rows defined. Scrum teams uses velocity to measure the amount of work done by the team in a sprint. In Kanban, key metrics are cycled, time, throughput, et cetera. In Scrum, sprint goal is defined during the sprint planning, whereas Kanban uses a pull system in Scrum, no change to the sprint goal is recommended within the sprint, but Kanban accommodates changes with more flexibility. Scrumban is a hybrid of Scrum and Kanban. It uses the prospective nature of Scrum and the process improvement of Kanban. It meets the needs of teams 1and to minimize the batch size of what and adopt a pool based system. Now we will have a quick look at the Extreme Programming or XP. Extreme Programming, which is intended to improve software quality and responsiveness to changing customer requirements. Xp is the most specific of the Agile frameworks regarding appropriate engineering practices for software development. Extreme programming has cold values of Communication, Simplicity, Feedback, courage, and respect. Different roles defined an XB, XB coach, Customer, Programmer, truck, and test the practices of extreme programming. Planning, gang, test-driven development, onsite customer pair programming, continuous integration, refactoring, small releases, simple design, collective code, ownership, system metaphor, coding standards, and sustainable pace. We will discuss a few of them in the coming slides. Code refactoring is the process of improving code, making it easier to understand and extend its improves readability, maintainability, extensibility, and reduces complexity. This is dumb. There is scope. A need is can happen in many occasions, including not limited to while fixing bugs. Parts of code review. When we found a duplicate. When we found the code is complex or unreadable, et cetera. Test-driven development is an approach where I develop a first rights test case, which describes new function or improvement and then create small codes to pause that test and later refactor is the new code to meet the acceptable standards. The steps involved at the test when new functionality running and fail. At minimum code for passing the test, run them POS refactor to improve code and repeat the steps. There are many of the methodologies under the Agile umbrella. There are many scaling frameworks as well, but we are limiting our discussion here. In the next video, we will start our discussion on Scrum. 5. Scrum Framework: Welcome to the next module. We will start our detailed discussion on Scrum. 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 each other to be capable, independent people and are respected 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 iterations 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 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 an 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 end 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 in 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 and 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 is 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 form 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 did the areas of improvement, both Sprint Review and Sprint Retrospective may have outcome that impact the next sprint planning. A new spring 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 further 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 are 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. In addition to these formal ones, Scrum teams may define a set of ground rules that will help them in delivering a self-organized, high-performing team. They are cooled social contracts. And example for such a social contract as given in the next slide. This is an example of social contract. There are items like no side conversations during stand-ups. Everyone pays attention to what's being discussed. This is not a complete list or template. Each team will define their rules based on their requirements. This can be captured in any format as decided by the team. This is just an example. I've jaw principle say's business people and developers must work together daily throughout the project. In Scrum, the business is represented by product owner. He coordinates with all stakeholders and represents the views. He gives the team business direction and maximize the value of what the team performs. A close collaboration were Product Owner is mandated for the success of Scrum. Scrum events are designed to enhance these interactions. Different skating frameworks exist for multiple team implementations. But in general, we can think of certain tools like Scrum off thrum, common Sprint Reviews, combined retrospectives, multiple team planning, common products, backlog, dependency tracking, et cetera. And increment is a concrete stepping stone toward the product goal. Each increment is additive to all prior increments in thoroughly verified, ensuring that all increments work together. This is termed as one of the Scrum Artifacts. This is the cumulative results of the increment developed in the sprint plus the increments from all previous sprints. This is fully tested, approved, and ready for deployment. Each sprint produces a shippable increment, but went to ship will deploy as product owners decision. Owner may decide to ship it or wait for further increments. With this, we have reached the end of this module. And the next video we will discuss requirements, user stories, product backlog, etc. 6. Requirements: Welcome to the next module in our SCRUM training. Here we would discuss requirements, uses stories, products, backlog, and so on. 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 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. Detailing will be a result of Father 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 story is successfully implemented. Usually it may take the form of the acceptable criteria. Spike is a story or toss 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. There are different approaches used to break up epics or user stories split using crud boundaries. Crud stands for create, read, update, or delete. A. We concentrate on these basic operations, user stories. Another approach can be split at the system boundaries. Whether you will define the subsystem boundaries and tried to split the stories. Other approaches can be spit up basic exception pot spits out workflow steps or split based on the business rule variations, etc. We split the stories based on functionality, 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 split user stories based on architectural relay is it should be done based on functionality. Each slice that have a pot of older layers. Let's see a few samples. As a user, I want to see the list of emails received so that I can select one for viewing. As a user, I want to put an ebook screen with mail list composed button. So that's I can view mail list and create new messages. As a user, I want to sort the email list on date and sender. As a user, I want to see the list of all emails received with field's date, sender, and subject so that I can select one for viewing. These are some of the examples for user stories. Larger user stories should be split into smaller ones. Now, let see an example of splitting the user stories. Consider the story. As a customer, I want to create my profile. It's a simple story. We may tend to split it across the technical boundaries, but this is not the right way. We should approach it from a functional angle. We can go for a simple, basic implementation. And another story for adding more details. Hey, what we are doing is to split the functionality to create an update operations. Then you stories can be, as a customer, I want to create my profile with basic information name, email. As a customer, I went to update my profile. So that's I can add more details. Larger user 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. It must be 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 the themes are often used to organize stories into releases or to organize them so that barrier 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 and in a way that there is no inherent dependency. And another user story, it should be negotiable. Stories are not contracts, leave room with discussions. More details will be added or 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. Large 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. Acceptance criteria, as I said, it's a pre-established condition is that the product increments are satisfied 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. It 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 we want from the user's perspective. It provides a checklist or template or 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 a hidden 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 admin can create user with username, email, id, mobile number. System displays a message or any of the above fields are missing and use it as an OC created. System sends an email to the user. Once 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 development team. Acceptance criteria, a clear and testable dependencies. I identified a no external dependencies. We'll broke the story from being completed. Isn't this test dates are required to test the story has been identified. Performance criteria, if any, are defined and measurable. The story is small enough to be comfortably completed in one sprint. Definition of done is a formal description of the state of the increments when it meets the quality measures required for the product. But moment to product backlog item meets the definition of Doug and increments. The definition of John creates transparency by providing everyone a shared understanding of what work was completed as part of the definition of done for a user stories as sets of pre-established conditions for confirming the same as done. It is not the same as acceptance criteria. At meeting the acceptance criteria will be an automatic selection to the list. It because it's, it has many aspects like organizational 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. A can be defined for Sprint and release as well. Checklists confirming if the sprinter releases done in all aspects. Consider this simple user story. As an admin, I went to great uses. So that's I can grant access to the system. Items in a definition of done can include user story meets acceptance criteria and reviewed by the product owner. O code changes are reviewed as prescribed by quantity menu and major findings are closed. Code changes. A check to X, Y Zed brunch. The list can go on. Definition of done for a sprint confounds that all required tasks and other activities for the sprint are completed. It can include, but not limited to definition of done of each single user story included in the springtime met or unit tests, deposing. Product Backlog is updated. Product Increment is deployed on a test environment identical to production platform. The performance tests passed. O category one bugs, 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 compounds that all require task and other activities for the release, all 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 UX 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. 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 for 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 not O1 is responsible for creating and maintaining requirements. But team can contribute in this activity. The final decision on the order of items and 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. We would like in the future. Other approaches for ordering include those based on business value, risk-based, k2, 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. Hi ordered product backlog items are usually smaller, Claire, more detail than lower ordered ones. Product owners are 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 if 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. Product backlog refinement is the act of adding detail, estimates and order to items in a product backlog. It is an ongoing activity. Brought 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's 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 back local refinement activity can have two parts. The first part we will concentrate from requirement clarification and adding more detail to the product backlog. In the second pod team will do an estimation for the user stories. With this, we have reached the end of this module and the next video we will discuss some of the estimation techniques used by Agile teams. 7. Estimation: Hello, welcome to the next module in our SCRUM training. A, we will discuss some of the estimation techniques to use by Agile teams. If we go for a definition, estimation is an approximate judgment or prediction that is most likely to be true. As usual. Let's start the discussion with our first question. The Cone of Uncertainty is a graphic depiction of the increasing accuracy that his possible for the estimates as the details over projects become more known over time, initial estimate will be less accurate. It becomes better as we acquire more knowledge throughout the project duration. There are different estimation techniques in use. Traditionally we use techniques like lines of code, function points, use case points, etc. In Agile, we use techniques like story points, 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 ours. Relative estimation consists of estimating something not separately and not in absolute units of time, but 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 Story Points 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 work. The development team 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 a 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. Thus, the product owner provides a short overview of the story to be estimated. The team discusses to clarify assumptions and risks, and the outcome of the discussion is updated in the user story, each individual is given a set of cards with the values that are used. Usually the cards are with Fibonacci numbers. Each individual selects a card representing their estimate and lays it down. Everyone shows their card simultaneously by turning them over. If there is a difference, people with high estimates and low estimates are given a chance to clarify their estimate and then the process repeats. 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 shed understanding on the story or the work related to it. The story should be parts for further grooming. T-shirt sizing is aware of relative sizing. By comparing stories, you can put them in buckets of extra small, small, medium, large, and extra large. Estimating and relative buckets is easier than estimating absolute time or effort. Estimation is not a onetime activity. At 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 this sprint planning, we will create tasks for each story which will be estimated using ideal days or ideal hours. This ends our short discussion on estimates. In the next video, we will discuss sprint planning. 8. Planning: Welcome to the next module allows Scrum draining. You will discuss sprint planning. In Scrum, planning takes place at various levels. There'll be high level plan, the release level based on what is known. Scrum team does a detailed planning while starting a new Sprint. The work to be done in this sprint is planned as a result of collaborative effort of the Scrum team. Every day the development team conducted daily scrum where they synchronize activities and creates a plan for the next 24 hours. Velocity is the total number of story points completed iteration. This is the sum of story points for all stories done in an iteration. Only stories or features that are complete counted. This should not be used to compare velocity or different project teams. We can use it to compare across iterations were given team to understand the trends and take correct actions. It helps us in refining in the release plan. We have the velocity and we know the total estimated size of the product backlog. So a simple division will give the number of iterations required. We should understand that these are predictions based on what is known till now. These are not frozen plans and will change as more information is available. Assemble calculation can be as follows. Assume we have a total size of 400 story points in the product backlog and a velocity of 20 story points. This means we need 20 sprints to complete the identified items in the Product Backlog. Important point to note here is this is a prediction based on what is known and not a frozen plan. The data on the screen shows another example. At present, we have stories amounting to 98 story points in the product backlog. We can tentatively tag them to different sprints based on the velocity. 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 of eight hours. Rwa month sprint. For shorter sprints, B event is usually shorter. Sprint planning is the first activity of the Sprint. The scrum team may also invite other people to which am sprint planning to provide 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 development team during the sprint. This assesses the availability of the team. We will consider leave plans, holidays, etc. Past performance of the Development Team, the current speed performance, or in other words, the velocity of the team. Sprint planning answers the following questions. Why is this sprint valuable? What can be delivered in increments resulting from the upcoming sprint? How will the what needed to deliver the increment be achieved? In the fast pots of Sprint Planning, the student proposes how the product could increase its value and utility in the current sprint. The Whole Scrum team then collaborates to define a sprint goal that communicates why this branch is valuable to stakeholders. Goal must be finalized prior to the end of sprint planning. Sprint goal is for single objective. For the sprint. To 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 development team on why it is building the increment. In the second part of Sprint Planning, Scrum 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, would achieve this objective. The development team decides and the number of items that can be selected from the product backlog for the sprint team decides how will the chosen work get done. Developers decides how it will build this functionality into a done Product Increment during the sprint, developers usually starts by designing the work needed to convert 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 selected Product Backlog Items, make trade-offs. If required, development team can renegotiate the selected Product Backlog Items with the product owner. The sprint gold plus the product backlog items selective for this spring plus the plan for delivering them is called the sprint backlog Developers Team is responsible for creating and maintaining the sprint backlog. Plan usually takes form of engineering tasks and other work items for meeting the definition of done for the selected user 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, tasks may get added. Sprint backlog can grow in size. It is a live document. Developers keeps updating it throughout the sprint duration. As a good practice team, make sure that sprint backlog is updated before or during daily scrum. At any point of time, the total estimated effort for unfinished tasks and sprint backlog gives the amount of identify work remains in the sprint. As sprint progresses, new tasks may get added, resulting in a temporary increase in remaining effort. The Daily Scrum is a 15 minutes time-boxed event for the developers to synchronize activities and creates a plan for the next 24 hours. Daily Scrum is conducted by developers and Scrum Master and make sure that this event happens effectively. Usually takes to format of three questions. Every team member ANSYS three questions. What did I do yesterday that helps the team meet the sprint go? What will I do today to help team meet the sprint go? Do I see any impediment that prevents me orbit team for meeting the spring go. Team can decide the full map 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, improved level of knowledge. And moreover, it is an inspect and adapt meeting. Here we have discussed Sprint Planning and Daily Scrum. In the next video, we will discuss other events in Scrum. 9. Scrum Events: Welcome to the next module in our SCRUM training. In this video, we will discuss events in Scrum. In the previous module, we have seen two of the Scrum events, ceremonies, Sprint Planning, and daily scrum. Within the Sprint, which is the longest event Scrum. There are four other Events. Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Ascribed events creates regularity and minimize the need for meetings not defined in Scrum. All events that time boxed. Every event has a maximum duration. Once a sprint begins, its maximum duration is fixed. Each event in Scrum is a formal opportunity to inspect and adapt. These events enabled transparency and inspection. Exclusion of any of these events will have an impact on transparency and reduces opportunity to inspect and adapt. We can consider the sprint itself as the longest event in Scrum. Sprints contain and consist of Sprint Planning Daily scrums. Though development work, The Sprint Review and Sprint Retrospective. Sprint is timebox till one month or less. During the sprint 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 goal is finalized during sprint planning. During the sprint, no changes are allowed that would endanger the Sprint Goal. Scope may be clarified and renegotiated between the product owner and development team. As more as learned. 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 cancel 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. A sprint review is how 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, a motto, the next things that can 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 our time books and meeting for one month sprints. For shorter sprints, it'll 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 disgusted that 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. 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 boxed 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, it recommends to concentrate on a few items which can be tracked and achieved incoming sprints. A Scrum of Scrum's is an event going housing coordination among Scrum teams when many teams are working for the same product. This is not a formal embed. Frequency and time books is fixed at the beginning of the project. Scrum master or representatives from o teams participate. Few points discussed in the meeting. The progress of the team of the last meeting, the task to be done before the next meeting. Impediments which the team is facing. The focus will be on cross team dependencies and common issues. This module, we have discussed different events in Scrum. In the next video, we will discuss roles defined by Scrum. 10. Scrum Roles: Welcome to the next module and not SCRUM training. In this video, we will discuss rose defined by Scrum. The Rose defined by Scrum, The Product Owner, developers and the Scrum Master. In the coming slides we will see what are the major responsibilities of these rows. Product owner represents the business and is responsible for the requirements, is the single source of requirements for the developers. Product owner owns the product backlog, he or she creates and maintains it. Product owner gives the business direction for the team. We can summarize the responsibilities. That list includes not limited to owes the requirements, the Product Backlog. Define the features of the product, responsible for the content, be responsible for the profitability of the product. Prioritize features according to market value, adjust features and priority every iteration or as needed, accept or reject work results. Developers create the Product Increment. They are self-organizing, cross-functional team doing the work towards the Sprint go. They have oldest skill is to convert this selective backlog items today and instead it ready to ship increment. They are responsible to develop the features of the product. They are cross-functional. All skills required to produce the increment. Members should be full time, may be with minor exceptions. Development team is self organizing. There are no titles. There are development team members. Membership can change between sprints, but with an impact on the productivity. The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Master is a servant leader for the team. He or she facilitates the scrum events and make sure the impediments are handled. Scrum master responsibilities include but not limited to. The Scrum Master is a severed leader for the scrum team. Removing impediments team's progress, enable close cooperation across all roles and functions. Shield the team from external interferences. Facilitating scrum events has requested or needed coaching the development team and self-organization and cross functionality. In this module, we have discussed different roles defined by Scrum. In the next video, we will discuss a few monitoring and tracking tools used by Scrum teams. 11. Monitoring: Welcome to the next module in our SCRUM training. In this video, we will discuss a few monitoring and tracking tools used by Scrum teams. We should go only for the minimum number of metrics that will provide all information necessary to meet business goals. We should not measure just for the sake of doing it, should be a value of benefits from it. Metric should measure outcomes not outputs. They must measure results, not activity. Agile focuses on the value created. So the focus will be on measuring what items completed, not time spent on net. Metrics should assess the trends, not snapshots. They should provide feedback at frequent and regular enzyme moves. I met metric should be easy to collect. Velocity is sum of story points completed in an iteration. Only points from completed stories or features that are counted. It helps during planning. It serves as an indicator for the size of work that a team can take. We should not compare velocity of different project teams. We can compare across iterations for given team. The velocities of a team across iterations can be plotted in a velocity chart. It helps in analyzing the trends within the team across iterations. A sprint burn down chart shows the total identified work remaining in a iteration. It has days as x-axis and remaining identified effort from sprint backlog as y-axis. Sprints burndown chart tracks the ongoing integration. Development team update sprint backlog with remaining effort for all ongoing tasks. Sprint backlog is a live document. A new task can be added at anytime during the sprint so that it can be temporary burn up in the burndown chart. We should always remember that we have a high level plan at the release level. This is based on what is known that the time of creating this plan, this may change as more knowledge is available. A burndown chart can be used at the release level to track number of story points remaining to be done in the release. The vertical axis shows the number of story points remaining in the release and iterations are shown across the horizontal axis. It shows the amount of work remaining at the start of each iteration. It's a may show a burn up because what has been added, a new backlog item has been added to the release. Scrum Master makes sure that this is updated at the end of each sprint. Again, the number of story points subtract here. But in a burn up chart, we track the number of points done, not remaining. The vertical axis shows the number of story points done so far in the release. Iterations are shown across the horizontal axis. It shows the amount of work done, story points completed so far at each iteration. Reference line as given in blue color in the figure, shows the total size of product backlog and can go up if news stories are added or estimation changes. An impediment is anything that reduces the chances of achieving the Sprint goal. It can also be defined as anything that creates a broker in this sprint work. These should be identified, tracked, unresolved. Teams use various methods to record and track impediments. As a good practice, the team should discuss this as part of daily Scrum. This sludge shows a template for the impediment list. These are few of the metrics used by Agile teams. There are many other methods to track the progress and effectiveness. Don't forget the events that are built in, which helps in tracking their progress. Each team decides their metrics based on what they want to measure and why might trick should help the scrum team in delivering and self-managed unit and should not become an impediment on their way. We have reached the end of this module. 12. Product Owner Role: Hello, welcome back. We are starting with our row specific modules here. In this video we will discuss the product owner role, different activities involved, and the skills required to be a successful product owner. The Product Owner is responsible for maximizing the value of product resulting from work of the product. Owner is the sole person responsible for managing the Product Backlog. A backlog management includes CALEA expressing Product Backlog Items, or during the items in the Product Backlog to best achieve goals and missions. Optimizing the value of the one team performs. Ensuring that the product backlog is visible, transparent, and clear to all, and shows what the Scrum team will work on next and ensuring that the team understands items in the product backlog to the level needed. The product alone is responsible for managing three aspects, money in value and time. What needs to be developed is the key area of focus for the product owner. He or she is responsible to make sure that the right product is being developed. It is being developed right, and is delivered at the right time. To achieve this, he or she should first understand the customer needs that business and we'll adds value for their business. Product. Owner is responsible for maximizing value of work done by the team. For this, the product owner estimates the business value that's a possible feature carries and should be able to prioritize the items to maximize the return on investment. Business needs and priorities might not remain constant. There are many factors impacting them and they keep changing. A product owner must be well aware of these changes and respond dynamically to these changes. These responses will be reflected in his or her decisions. This gives an edge for the business, increasing N customer specification and in turn, attracting more customers and revenue. As discussed before, the product owner is the single source of requirements for team. He or she clearly communicates the customer needs and be available for any clarification is throughout the development period. We have seen different activities performed by the product's own and previous modules. Hey, we will try to summarize the product owner activities. The product owner clearly expresses the product vision and communicates it to o stake holders. He defines the goals that the product tries to achieve. A clear vision and smart goals creates a common understanding among all parties involved. The product owner takes the lead in creating a high-level plan, a roadmap for the product. This gives a high-level picture of how the product will be growing towards achieving the goals and fulfilling the vision. This serves as a long-term, long-term forecasts are aligned with the business priorities of the company. The product owner gathers the requirements for the product and captures them in form of a product backlog. We can divide this activity into three parts. Spend time with the stakeholders to understand their needs clearly and precisely express them in product backlog and communicate these requirements to the team. The product owner prioritizes the requirements in the Product Backlog based on the business priorities and the expected return on investments. There will be many factors influencing this order. The product owner decides what is best for the business. Communication is an ongoing process and coal or the product owner activities. He or she represents the business and be available for any clarifications. Products backlog is a live document. It's exists and gets updated throughout the lifecycle of the product. So maintaining the product backlog or in other words, backlog grooming or backlog refinement is an ongoing activity Lab by the product owner. He or she is responsible for maintaining a healthy product backlog with enough ready items. In a scaled environment element, the product backlog needs to be synchronized among multiple teams working on the product. The product owner creates high-level, long-term estimates for the product. These are predictions based on what is known so far and helps in coming up with a release plan. The product owner clearly sets his or her expectations about the Done criteria for the work items. He or she verifies and accepts or rejects the work done by the team. What are the skills required for successful product owner? This is a huge topic. It is nearly impossible to create a comprehensive list of all skill is required. We may need a different sets of skills based on the project, the team we work with, the environment we operate, etc. Here we are trying to let out a few common areas of focus. The product owners and knowledgeable person in the area of business. He or she must have a strong business focus. He or she should be able to understand what business needs and empowered to take decisions to maximize the value that is provided to the business. Communication is one of the main skills that defines success for a product owner. Effective Communication define successful product owner. He or she must communicate clearly and effectively the right information at the right time to the right people or product owner faces and resolves many clicks in their day to day activities. There will be many stakeholders were conflicting ideas. Conflicts may arise from many areas including but not limited to requirements, priorities, development plans, etc. The product owner should be decisive and handle these to the benefit of the bit of the business. A product, as committed towards the product goes, their decisions will reflect this commitment. Trust is an essential quality for a product owner. A product owner must uphold and live by the scrum values of commitment, courage, focus, openness, and respect. Scrum Team consists of the product owner and the Scrum Master. A product has a single products back. Una, what's if they are multiple teams working on the same product? In a scaled environment, the product backlog needs to be synchronized among multiple teams working on the product. This can be done by proper tagging and distribution among different teams. As the number of teams and their velocity increases, it will be difficult for a single product owner to perform his activities effectively. In such situations, you may have to go for an arrangement with the Chief Product Owner leading a team of product owners. We can think about different feature lines and purpose synchronization within the team of the product owners. 13. Managing Requirements: Hello, welcome back. The Product Owner is the single source of requirements for the scrum team. Capturing the requirements, clearly expressing them in the Product Backlog, and effectively communicating them to the Scrum Team is the primary responsibilities of the product owner. In this video, we will discuss how requirements are handled in Scrum. We have already discussed the parts of these topics in our requirements video. Here we will approach it from the product owner's perspective. We will refresh a few of these topics that we have already covered. The main focus in this video is on maintaining the product backlog. 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 would it take to complete these requirements? How much would 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 purpose of a product, the intention with which the product is being created, and what it aims to achieve for customers or uses. It describes the purpose of your product, why it is being built. What do they expected benefits? It gives a bigger picture of what we are working on and why the product division is aligned to the business goals of the organization. It creates a common understanding among all parties involved. It guides us in making decisions throughout the project. It helps 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 it represents in clay words, the vision of the product. This keeps ever and motivated to work towards achieving the goals. A product vision statement must be expressed in the proper format, which is suitable for the product and the industry, whether it is placed. A commonly used format is given hey, 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 who 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 more value. This video, the focus is on creating user stories. Methods are breaking them down to proper size and techniques for prioritizing them before getting into it, let's quickly refresh a few basics. A product backlog is an ordered list of everything needed in the product. It is a single source of requirements on the product. When there are multiple teams working on the same product, the product backlog is shared across the teams working on the same product. There is only one product owner or a Chief Product owner who owns the product backlog. The Product Backlog is never complete. It exists as long as the product exists. It usually consists of epics and uses stories. The Product Owner is responsible for creating and maintaining the product backlog. A good product backlog will be deep. That's as detailed, appropriately emergent, estimated, prioritized. User stories are usually written in the format. As a user, I want this functionality so that I get this benefit. Here is an example. As a user, I want to see the list of all emails received so that I can select one for viewing. Most users stories or Product Backlog Items as originally written epics. Later these are broken down into smaller user stories so that the team can work on them. It is written by passes with knowledge of the product. Product Owner is responsible for this activity. Product Backlog Refinement meeting can be used for writing user stories that is, expand at more details, et cetera. Breakdown user stories that are too big like epics, improve user stories that are poorly written. Estimate backlog items at acceptance criteria, if not already done by the product owner. User Story Mapping is a visual representation that helps to define the work that is required in the product. It is a visual way of creating 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 and 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 on line. 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, assault 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 how 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 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. Here we will discuss different methods for splitting user stories. There are different approaches used to break down epochs or 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 first, 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 workflow of 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 that 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 order. Major effort. If the user story involves a major functionality and its variations, we will break out the variations and implement the major effort first, consider the user story. As a customer, I want to pay online with Visa, amex or MasterCard's. So that's our received my products at home. The major effort here we'll be using the payment infrastructure. Once it is in place, other cards can be added with less effort to among the resulting stories can be, as a customer, I want to pay using 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 data 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 menu then 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's I can do a booking. Now we will enhance the experience. As a customer. I want to select location using map, so that's 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 traits a spike for experimenting with online payment gateways. This will reduce the unknowns regarding the functionality. Great 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 start 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 myLocation. Differ performance, make it work, then make it fast. Make the functionality work before going for optimization. Consider the user story. As a customer, I want to search for hotels. So that's I can make a booking to among the resulting stories can be, as a customer, I want to search with dates and location so that I can do a booking. 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. Now we will discuss different methods used for prioritizing backlog items. Always remember the final decision on the odour 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. Uh, factors that influence these decisions are the business value, market demand, teen capability, risk, dependencies, et cetera. 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, XXS 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. Categories 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 set 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's election 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 model, 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. Acceptance criteria, definition of ready, definition of done. In the previous modules, we have already discuss these items with examples. This is just a refresher. These items set the expectations or reflect the agreements between product owner and the acceptance criteria is it sets a pre-established conditions, but the Product Increment just satisfy to be accepted by the user. This will be provided by the product owner. Definitions are ready, confirms that the user story is ready for implementation. This is agreed upon by the scrum team. Definition of done is a sets of pre-established conditions for confirming the item has done. It is agreed upon by the developers and the product owner. Definition of done can be defined for user story, sprint or release. 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, 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 the predictive velocity, we can map the stories across different iteration output from the story mapping exercise priorities and dependencies will play a crucial role in this mapping. This activity can be done as a continuation of the story mapping exercise. 14. Product Owner Role In Scrum Events: Hello, welcome back. This short video we'll summarize the role of the product owner and prescribed Events. Sprint Planning. The one to be performed in this sprint is planned that the sprint planning, this plan is created by the collaborative work of the entire scrum team. The product owner discusses the objective that the sprint should achieve and The Product Backlog Items that if completed in this sprint, would achieve the Sprint goal. The product owner can help to clarify the selected Product Backlog Items and make trade-offs. A developer determines it has too much or too little work. It may renegotiate the selected product backlog items with the product owner. The product owner responsibilities in sprint planning include, maintain a healthy product backlog. Make sure there is enough items in the Product Backlog satisfying a definition of ready. Clearly defining, communicate acceptance criteria. Present the user stories and the priorities. Clarify any questions from the team on the requirements. Helped the team and selecting items for the sprint. Understand the rule. Team knows best its capacity. Daily Scrum. The Daily Scrum is a 15-minute time-boxed event for the Product. Owner is not a participant in this event, but he or she can be present in this event. Observe, listen and watch how the team is progressing in this sprint. Or product owner must clearly understand that this is not a status meeting for him. Don't try to hijack this meeting. Talk only if you are requested, shall only as appropriate Sprint Review. The Scrum Guide says a sprint review is housed at the end of the sprint to inspect the increment and adapt their product backlog if needed. During the sprint review, the scrum team and stakeholders collaborate about what is done in this sprint. A good sprint review is an essential part of the Inspect and app cycle. While the Scrum Master is facilitating this meeting, this is a crucial meeting for the Product Owner. The product owner responsibilities in Sprint review include invite the right people for this meeting, discussed the product backlog as it stands, explained what is done and accepted and what is not. Li and energetic discussion. Get, filter and prioritize feedback, adjust product backlog as needed, and make predictions on likely target and delivery dates based on progress to date. Sprint Retrospective. Scrum Guide says The Sprint Retrospective is an opportunity for the scrum team to inspect itself and creates a plan for improvements to be enacted during the next sprint. This is an inspect and adapt meeting for the Scrum Team. The Scrum Master will facilitate this meeting. Product Owner is a member in the scrum team. He or she participates as a Scrum team member. 15. Summary: Hello, welcome back. This is the last module in this training. He, we will summarize the product owner role on a process view. A summary of our discussion is shown here. The product owner owns the product backlog. He or she guides the team with a healthy product backlog and guides the team on priorities during the planning, he or she is not a participant but an observer during the daily scrum. Throughout the process, the product owner onto teams questions and gives clarifications and the requirements. In Sprint Review, the Product Owner invites the right participants and leaves the discussion on the current state of the product. He or she participates as a Scrum team member in the retrospective, the Product Owner accepts or rejects the work done by the team. 16. 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.