Agile & Scrum - From Beginner to Expert (includes practical project) | Aakriti E-Learning | Skillshare

Agile & Scrum - From Beginner to Expert (includes practical project)

Aakriti E-Learning, Passion to learn and teach

Agile & Scrum - From Beginner to Expert (includes practical project)

Aakriti E-Learning, Passion to learn and teach

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
43 Lessons (3h 49m)
    • 1. Introduction & Course Overview

      7:00
    • 2. Why Agile? (Problems with traditional approach)

      5:14
    • 3. The Agile Manifesto

      5:23
    • 4. Definition of Agile

      3:28
    • 5. Definition of Scrum and its difference from Agile

      4:48
    • 6. Scrum Life Cycle

      3:45
    • 7. MVP & Incremental Approach

      4:20
    • 8. Introduction to Scrum Roles & Scrum Stakeholders

      3:47
    • 9. Product Owner - roles & responsibilities

      4:22
    • 10. Development Team - roles & responsibilities

      3:37
    • 11. Scrum Master - roles & responsibilities

      3:55
    • 12. Scrum Team Dynamics

      3:27
    • 13. Backlog Grooming & Introduction to Scrum Ceremonies

      8:03
    • 14. Sprint Planning

      5:35
    • 15. Sprint Daily Stand Up

      4:14
    • 16. Sprint Review or Demo

      4:03
    • 17. Retrospective

      3:46
    • 18. Release Planning

      4:33
    • 19. Epics & Introduction to Artifacts

      7:56
    • 20. User Stories

      5:23
    • 21. How to write great user stories

      0:19
    • 22. Artifact 1 - Product Backlog

      3:10
    • 23. Artifact 2 - Sprint Backlog

      4:32
    • 24. Artifact 3 - Increments

      3:45
    • 25. Definition of Done

      4:05
    • 26. Sprint Planning in full detail and its importance

      4:39
    • 27. Estimation in Scrum

      5:37
    • 28. Story Points

      6:34
    • 29. How to decide story points with common examples

      10:51
    • 30. Planning Poker

      4:16
    • 31. Team Capacity

      5:58
    • 32. Team Velocity

      5:06
    • 33. The Scrum Board & Introduction to Scrum Metrics

      5:31
    • 34. Burn Down Chart

      4:32
    • 35. Burn Up Chart

      2:33
    • 36. Velocity Chart

      3:57
    • 37. Keeping an eye on the Backlog

      5:26
    • 38. Practical Project - Implementing Agile - Part 1

      15:06
    • 39. Practical Project - Implementing Agile - Part 2

      12:55
    • 40. Practical Project - Implementing Agile - Part 3

      5:33
    • 41. Practical Project - Implementing Agile - Part 4

      4:24
    • 42. Certification Exams with Tips to crack them

      8:13
    • 43. Interview Tips

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

48

Students

--

Projects

About This Class

Most detailed Agile and Scrum Learning course on Skillshare. We will start on this journey with the most basic concepts and then progress to each & every aspect related to Agile & Scrum.

6 great reasons that make this the best Agile & Scrum course:
#1: This course is designed to teach you everything about Agile & Scrum and in an interactive way.
#2: We will talk about the core concepts, terminologies and best practices as used in companies.
#3: All learning will be supplemented with practical examples, as we will do a 40 minutes session to setup a project in Scrum from scratch.
#4: Agile Quiz questions (in the project section) to test your knowledge.
#5: Tips for the CSM exam.
#6: Common Interview Questions and tips to get your dream job.


What you will learn in this course?
- Traditional approach and its drawback
- Agile Manifesto - values & principles
- Agile & Scrum and their difference
- Scrum Life Cycle
- MVP and Incremental Approach
- Scrum Roles - product owner, scrum master, development team
- Backlog Grooming
- Sprint Planning
- Estimation
- Story Points
- How to accurately estimate user stories
- Planning Poker
- Epics
- User Stories
- How to write great user stories
- Sprint Demo
- Retrospective
- Team Capacity
- Velocity
- Scrum Board
- Burn-Down Chart
- Burn-Up Chart
- JIRA
& Practical Learning to supplement all this

Thank you and wish you all the best on this learning journey!!

Meet Your Teacher

Teacher Profile Image

Aakriti E-Learning

Passion to learn and teach

Teacher

Hi, I've 10+ years of experience in Software industry, primarily in Project Management and QA. I've also worked as part-time trainer and corporate instructor. 

I believe its very important for all of us to keep learning new topics, keep upskilling ourselves, and improve on things. This spirit and desire to learn is important and you will see it reflected in my courses where I touch on real life examples (as practiced in organizations) and the learning from them that will actually help in our day to day work.

I try to explain each topic in the simplest possible manner, so it caters to beginner audiences, and from there we move on to cover advanced concepts.

Last thing, all my courses come with life time query support, so if you ever have any questions, conc... See full profile

Class Ratings

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

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

Your creative journey starts here.

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

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

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

phone

Transcripts

1. Introduction & Course Overview: Hello everyone and welcome to this course that is titled mastering age aisle and Scrum from beginner to expert. You have made a very smart decision in choosing to learn h l and is crumb. Because you know, HL is such an important concept in today's world, irrespective of whichever industry domain or technology you are working on. And its uses rapidly growing. Almost 71% of organizations use a GI and that number is growing every day. So that's why it's very important to know about it. And you are definitely in the right course for Dad. This is a master class for Agile and Scrum, and you will learn every tiny detail about them. You can use this Learning to Improve Your assuming or work in a Scrum team or get certified as a scrum master, whatever your end goal is. So I'm very excited guys to get on board this learning journey. And I thank you for choosing this course. Let's get started and see what all we will cover in this introduction chapter. So here is the agenda for this chapter. And as you can see, we are just getting to know the things which is very important to set the momentum. We will mainly see what this course covers and how you can get the best out of it. We will talk about me, your instructor, the course content, and the immense carrier options that follow once you get the knowledge of AGI. So what can you expect from this course? Well, this course is a full package. We will of course, learn everything about Agile and Scrum and away This course is designed. We will start from the most basic concepts and then move on to the advanced one. So if you are entirely new to HR, you will feel totally comfortable in this journey. Or if you are someone who has experience in a gel, I still suggest you watch all the chapters in sequence because there could be something new for you or you will get a recap. We will learn about the HL and Scrum core concepts, the Scrum roles, ceremonies, how do we estimate things? What are the artifacts that report we create? And lots, lots more. And we are going to keep this learnings interactive. So there is a small quiz at the end of each chapter to refresh what we have learned. Another point and very useful, it's not just sufficient to know the theory. We need to apply our learning in practical also because that's when we get the real knowledge of things. And that's why we have an entire chapter dedicated to setting up a project in Scrum from scratch. Next, we will also talk about certifications and interviews in this course. So if your goal is to get certified as a scrum master, you will surely benefit from the course because we have an entire chapter dedicated to certifications and tips to clear the exam. And likewise, if your goal is to excel in an interview, we have a chapter dedicated to interview tips and 30 plus most common interview questions. Next, if you are a member of this course or any of my other courses, you get lifetime query supports. So use the Q and a option on the website or drop me an email and you will get a quick response. And this is the lifetime support guys. So you can send me something even a year after taking this course and expect back a response. And lastly, this course is designed for all kinds of audience in mind. Whether you are a fresh college pass out or an IT entrant or an experienced folk. The contents of this course covers all levels and by the end of it, you would have the full expertise of Agile and Scrum. So before moving on guys, I just wanted to give a brief introduction about myself. I have ten plus years of experience in project management and quality assurance. I have worked on and led several AGL products projects in India and also for several years in us. My email address is on the screen, so like I mentioned earlier, also, if you have any question, please feel free to drop me an email and I will proactively reply within 24 to 48 hours. You can also post your questions via the Q and a option on the website. Now, before moving forward, one of the things I wanted to mention was that in all these years of my work experience, the most important thing I have found that we need in the work life is to have the Art of up-skilling ourselves to keep on learning new things. So keep a desire to learn, take on any new topic that interests you and keep building up be a learner. All right, so we are ready to jump in. Let's walk through the course content now so you know what's in store for you. So guys, here's the course content and as we go through it, you will notice I have called each chapter as a sprint. By sprint is the heart of Scrum and all the work happens in it and we will know about it later. So each chapter is a sprint to learn something new. Within 80 sprints, we'll learn all about Agile and Scrum. We will start with the core concepts of hL and Scrum. Then we will talk about the Scrum roles, the people who are in the scrum team, followed by Scrum ceremonies, that is the meetings. And then the Scrum Artifacts. We will then learn about sprint planning and estimation, followed by Scrum reports that we create. And then the chapter eight is a full practice exercise where we will set up a project from scratch in a scrum and see its implementation all the way from initial requirement gathering to releasing to the end-user. Finally, we have chapter nine to learn about the certifications, bit tips on how to clear the certified scrum master exam. And lastly, newsprint ten. I'm going to give you a bunch of interview questions to help you prepare for an interview and have kept the answer to these questions as simple as possible so you don't have to mug up things, your concepts or sound. So guys, as you can see, it's a pretty exhaustive list and we will follow this plan over the next ten chapters to make you an expert in agile and scrum. Now coming back to the last topic of this chapter, the carrier opportunities in AGI, It's very important to see the road ahead and be motivated. Remember, HIV started somewhere 20 year back. And in today's world, it is the most commonly used methodology. If we talk about big companies, Fortune 500s, or even smallest startups, everybody is using AGI. You can pick up any of their job listing for project management or development or testing, and it will require a child knowledge. Some jobs demand for a certification also like CSM or CSP Leo and I would suggest that you pursue these areas. Having a certification gives a recognition to your knowledge and it's a nicer add onto the resuming. If you're already in product management role, you can think of the product owner role or other management roles. If you're too passionate about h l, you can be an Agile coach. The opportunities and uses of HIV are endless guys. In LinkedIn surveys of the top ten most promising jobs is Scrum Master and Product Owner are one of the entries. So pretty impressive carrier path. And that's why I said in the beginning you have made a great choice in choosing to learn AGI. Okay, so we have talked about the course, it's content and opportunities in AGI. Let's begin our learning journey and start with the next chapter to know what is agile and scrum. Thank you. 2. Why Agile? (Problems with traditional approach): Hello everyone and welcome to the second chapter of the course. We are now going to start our journey into the starting concepts of Agile and Scrum. We will first see what was the traditional approach, the pre Agile way of doing things. Because this will help us understand the reason why a child was born and why it is so successful. Next, we will see the Agile Manifesto and principles that are the foundation of HL. We will then discuss the EGL methodology followed by Scrum. We use the terms each island is crammed together, but remember there is a difference between them and we will see what that is. Next, we will take a look at the scrum lifecycle. So until now we were at the what is it part. Now we will move to the how it is done part. And lastly, we will talk about MVP and incremental approach, which is an important concept. So let's begin. So let's jump right in and let's start with the Agile world of doing things, how we're thinks done before age Eyal came into picture. So the most common methodology that was followed before a child was known was the waterfall model. And this is how it looked like. So guys, this is the waterfall model and as you can see, there is a strict sequence of phases. We have the requirements phase, the design phase, implementation verification, and finally the maintenance phase. And the previous phases had to be completed before you can start on with the next one. So now it looks pretty straight forward, but there was a big problem here. And debt problem happened when we had to go back and change things. So let's understand this by an example. Let us consider a scenario where a company wants to develop a new product, let's say a mobile phone, they do the market research. They come out with the requirements of what they need and they decide to implement it using the waterfall approach. Now three months after starting, let's say the red dye verification and testing phase ender realized at the requirements have changed. Customers no longer need what they taught initially. And so everything that they have planned and done until now is gone. And now we have to start all over again from the very beginning, the first requirement phase. If you think about it, guys, this is the reality of today's world. If you see the customer mindset today, their needs are changing so fast is studies have shown that in large and complex projects, about 70% of the initial requirements will get changed during the project. What we are making today would be obsolete and replaced by something new in three to six months. And so waterfall could not cope up with this changing requirements world. So this is what the slide also says. If you think about it, even the client, So give us the requirements for their projects. They might not know all the requirements beforehand. In fact, it's tough for anybody to guess how markets and users will react to a product in the next three to six months because, you know, things are changing so fast. And to overcome this problem, things had to be course-correct in lot in-between and this increase the cost, time, effort, etc. Now, another problem with Baghdad in waterfall, the end user or client was not involved in the process and Dessau working software or product pretty late in the game and if any change was needed, well, let's go back again and you start implementing from the initial phase. Again, meaning more time costs, effort, etc. So guys, this traditional waterfall approach that we saw begin to develop cracks. And in fact, in the US where the Department of Defense was the biggest user of waterfall, they found out that 75% of their project never completed because of delays and escalated costs due to frequent changes. So once again, to summarize the problem with traditional approach, number one, no one can get requirement in one single shot because things are changing so fast. Number two, End-user was not involved in the process. There was no feedback mechanism. And number three, the working software or prototype came pretty late into the picture. So by the time changes could be factored in, it was pretty late. So in short, this traditional approach was not good for continuously changing requirements. And so in the late nineties, the industry wanted to move towards an iterative model which was open to the evolving changes. And it took into consideration the real problems. First, no one can know all the requirements. Second, making changes is a big deal. It is not manageable to keep on changing things every time there is a new requirement. And most important of all, we needed something that can be number one, done in small increments. Number two, debt could be iterative. And number three, that involved continuous feedback. So if we ever had a modification, we can find it early on. And guys, this is the exact thought process that gave birth to a child, iterative and incremental development with continuous feedback. And you will hear these three words, iterative, incremental and continuous feedback a lot in this course, because the other necessities on which a child or a Scrum is built. All right, now the industry had somewhat is started adopting a few iterative models by the nineties. But the real thing came in 2001 when 17 software developers met at a resort in USA, USA. And they came up with something that's called the HL manifesto. So let's talk about what this h l manifesto is and how it forms the vision of a child in the next lecture. Thank you. 3. The Agile Manifesto: Hello everyone. Let us talk about the Agile Manifesto now. And it's important to understand this manifesto because it is the foundation and guiding principle behind HL implementation everywhere in the world. Now this manifesto has four core values and 12 supporting principles. So let's see what they are. And you know, there is a dedicated website to this manifesto, so let's check that out. So guys, they have a website called HL manifesto.org. And this is how it looks like. And you can see the four core values listed right here. And it says that the things on the right are what we have been doing. But instead we should value more than things on the left and we should follow them. So number one, we should value individuals and interactions over processes and tools. Processes are important, but they are not flexible to changing customer needs. So we should not stick blindly to processes. Rather, we should focus more on individuals and their interactions. When individuals will collaborate more, they will come up with better idea and not just follow the process. So this was point number one, but remember it does not say stop following all the process and do whatever you want. No, it just says that individuals should interact more, they should collaborate more and they should not go blindly to what process says. Number two, working software over comprehensive documentation. So back in the days of waterfall, There were a lot of documentation for each of these stages and age. I said let's keep documentation to minimum is streamline everything and focus more on getting a working software. So once again, do not understand that each aisle says is stopped making all kinds of documentation. No. Instead, it wants us to focus more on getting them working software rather than just getting documents. And number three, customer collaboration over contract negotiation, meaning involved customer in the entire journey. Think about what they want rather than just trying to work as a onetime written contract. And last number for responding to change over following a plan. And this one is the most important in my, my viewpoint because most of the people think of agendas just to methodology. But always remember that a child is more of a thought process. We have to be HI in our thinking only then we can follow a jail methodology accurately. And HIV test tells us don't follow the plan blindly. Instead be flexible, be responsive to changes so we can adapt quickly to the changing market conditions. So these are the four core, core values. And as it says, there is value on the items on the right. The things that we have done in the traditional approach. But now we're going to value things on the left more. So in a nutshell, this was the what part of a gel. And right here it lists the name of those 17 people who got together to form the Agile manifesto and came up with these four core values. Now if you scroll further down, you will see a link to the 12 principles. So this is the page that it takes to, and you can read through them. There are some key points here. First, we have to provide the customer with a early and continuous delivery. So if I give you a product after 12 months and let's say it's not good. There would be a lot of effort, cost, and time in trying to go back and correct it again. So do not let it happen, delivered to the customer continuously in increments. And again, there are 12 different principles. I do not want to go through all of them. You can read them. Let's try to understand the key concepts here. The first one was early and continuous delivery. And then if you go down, it talks about working together. So business people and developers must work together. Remember individuals and interactions that we saw in the first core principle. Second, trust people, remember again from the core values do not follow process and contract by blindly trust on people and have them come up with the best product or software. Next is face-to-face interactions. So again, phi, sorry, face-to-face conversation. So again individuals and interactions. Then if you scroll down, we have working software. So like we talked about in the core values earlier, less documentation, more of working software. We are seeing software here, but you can think of products also. It basically means that the measurement criteria is of working something not just tons and tons of documentation. So again, you can read this thoroughly line by line, but the idea of a GYE, including these principals, comes from these four core values, which are individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration, over contract negotiation, and lastly, response, responding to change over following a plan. So remember these four core values. You can save it somewhere. You can write it down on your desk. In fact, in our early days when we started implementing a GI long back in our project, we used to have these big posters on the wall debt listed out these core values. And you can also do the same. You can hang them up in a place where, you know, you do do regular meetings that teams it together. And it is important because it helps us reminder of the importance of collaboration, incremental development, etc. And if you get these concepts, you will get the full idea of wattage Alice. So, alright guys, so that was all about the Agile Manifesto. Now let's go into the next lecture and see the formal definition of a gel. So I'll see you in the next lecture till then. Thank you. 4. Definition of Agile: Hello everyone. So in the past lectures we talked about the traditional approach of doing things. We took at look at the HL manifesto. Now let us really see what this angel is. So on your screen you will see the official definition of AGI and it says, HI EL software development refers to software development methodologies centered around the idea of incremental and iterative delivery of small chunks of functionality. We're requirements and solutions evolved through collaboration between cross-functional self-organizing teams, enabling frequent customer feedback and course correction as needed. So that is the official definition of a gel, but too much Wurtz, Right? So let's leave out the bulk of it and let's focus on the most important terms. So the first one is incremental and iterative delivery. Remember we talked earlier about the old methods and the problem with them was that we delivered the product pretty late and then we had to make changes which was costly and delayed things. So age ILC is delivering increment. You don't have to make everything in one short. Make the first version or MVP of the product, and then improve it in increments and via frequent or iterative deliveries of a small chunks of functionality. So designing smallest small pieces, deliver the increments in its smallest small pieces, and then keep repeating this whole process. Next important concept is collaboration. So like we saw earlier, no single individual process or tool can guess all the requirements at once. We need a group of people to collaborate and come up with solutions. And that is why a child teams are cross-functional and self-organizing. There is no concept of development manager or testing manager within the Scrum team. They are all external to their team. The individuals in the team who sit together, who worked together, they interact with each other, they discuss with each other, they collaborate with each other. And the design useful products and services for the client. And the last aspect, feedback and course correction. So remember, changes will surely come. Corrections would be needed. So keep a continuous feedback with the client. We do not want to, you know, reach out to the client after three months or six months to gather their feedback. We want to do is smallest, small increments. We want to show the product to the client. We want to gather their feedback and make corrections as needed. So these five things that you see highlighted on the screen, that is what h l is. Now remember, I do not want you to remember this entire definition word by word. And in fact, I will not ask you to memorize things word-by-word anywhere in the course. Just remember the keywords that are highlighted on your screen in the definition. And if you go to any interview or any organization and somebody asks you what is a gel? You can tell your own version including these keywords. Once the other person hears these keywords, they will know for sure that you understand. Hi. So that is the approach we will follow throughout this course. I will make sure that you understand the key things and you do not have to memorize any stuff. So this was the definition of a gel guys. And basically it's a cycle of planning things, designing them, taking feedback, review from the customer and launching the thing and then redoing it again and again in iterations. So dat is all hl is the single diagram. Alright, so I'm sure you know, know what HFile is, its manifesto, its core concepts. So let's talk about the implementation part, and let's talk about a Scrum in the next lecture. Thank you. 5. Definition of Scrum and its difference from Agile: Hello everyone and welcome back. So let's talk about our next topic, which is a Scrum. So what exactly is this scrum? Now we talked about H L, and we often use Scrum and age IL together in the same context. But remember they are actually two different terms. Is Scrum is an Agile project management framework that teams used to develop and deliver complex products. So while a child is a set of values and principles, is Scrum is the way to implement it. Just remember this thing. H L is a set of values and principles and a Scrum is the way to implement it. And remember it. Scrum is an incremental and iterative approach. So let's recap on these two words. Incremental means that we are building and delivering the product in its smallest small pieces. And iteration means we are doing something and then refining it further. So like we talk about software, we make an initial product and then we iteratively refine them. We do cycles of length two weeks or four weeks. And in each of these cycles, we add increments of new features and details to the initial product. These cycles are actually called as a Sprints and we will talk about them in detail later. But for now, remember that the goal of Scrum is to develop products in each small cycles of two or four weeks called as Sprints. And in each sprint we add new features, we add new increments on top of existing ones. That's the output of each sprint. Now there are additional terms, people, process, et cetera, that also defined is Scrum. And don't worry, we'll learn about each of them in detail later. But in summary, this is what is Chrome is all about. It's an incremental and iterative H L framework to deliver and develop complex products. That's all Scrum is. Now one last point before we move ahead is Scrum is used most commonly in software development. And we talk about data reference mainly in this course. But remember is Scrum is equally usable in other industries like manufacturing or other businesses also. So if you are coming from that background discourse and discontent is equally meaningful for you. So I hope you are clear on the definition of a scrum. Now, moving on, let's see how HI AL and Scrum are different. As you go through this list, you will notice that there is not too big of a difference in meaning. That distinction is more of what and how sense. So what HIS talks about is crumb does that. Now we already know about the first and main difference and always remember that a child is the methodology for development and a Scrum is the framework to implement it. So hl is the core value, h l is the core principle of doing things of development and a Scrum is its implementation. Second, HL is suited for a small and expert teams, whereas the Scrum is suited for rapid changing requirements because of its process control aspect. Next point, leadership plays a key role in HDL, but any Scrum decisions are taken by team. So like I mentioned earlier, also, there is no manager, there is no team leader inside the Scrum team. There is a product owner, there's a Scrum Master, there is a development team. They all sit together, they collaborate, did discuss the interact, and that's how they solved problems. Fourth, along the same lines, HI EL promotes collaboration and interaction between teams. We saw this in the core value. Now is crumb does that via something called a daily stand up meetings. So it's a daily get-together of individuals working in the Scrum and it's an HL7 money, we will talk about it in the later chapter, but that is how collaboration happens in this crumb. Next, HL talks of delivery and updates on an iterative basis. Again, is crumb also does it why sprints? So these prints, like I mentioned earlier, is the heart of all activities in his Scrum. If you are working in any Scrum or if you will work in any Scrum going forward, you will hear things like, okay, we'll do it in this sprint, we'll do it in next sprint. We will take two sprints to do it. Because like I said, these sprints are where all the action, all the work happens in the Scrum. And last point, h l promotes continuous feedback. We saw it earlier. Is crumb also does debt via something called a sprint demo. At the end of each sprint. The demo is also a scrum ceremony and we'll talk about it in detail later. For now, just know that it is done after every sprint to show the product and gather feedback, that continuous feedback methodology. So guys, that's the key difference between each island is Scrum. And again, you don't need to remember all this, just remember number one, HI, and Scrum are different. Number two, h L is a methodology. It is guided by a set of core values and principles that we saw. And Scrum is an HL based approach. It's just an implementation of HAL. Alright, so in the next lecture, let's talk more about Scrum. So I'll see you in the next lecture till then. Thank you. 6. Scrum Life Cycle: Hello everyone. So now we know what is Scrum is. Let's see how things work in there. And what you see on the screen are the stages that together make up the Scrum lifecycle. Now we are only going to briefly talk about them here because we have a dedicated chapter on these later. So let's take a quick look on them. But before we pick these up, let's think about how we work in our daily life. And if you understand this, you will get the idea of Scrum also. So we want to do lot of things in our life, right? There is like a big list of things that we want to do or we have to do. From that big list, we pick out five things that we want to do this week. So we want to go to some place. We want to buy us something, we want to meet someone, etcetera. We are picking out at off five things, right? And then we do those five things over the week. At the end of the week, we recap on how we did, whether we could have done any better, etcetera. And then we again open our big list of things and pick the next five things that we have to do in the next week. That's how we work as an individual, and that's exactly how a scrum also works. So we have a big list of requirements that we call as the product backlog. It's just a big list of things that have to be done. We do a planning meeting and from dad big lists we pick like five or ten requirements depending upon the teams availability or capacity. And we call them as the sprint backlog. Now we work over them in the next two or four week cycle that is called as a sprint. While we are in this sprint, we do a daily meeting every morning to discuss the progress that is called as the stand-up meeting. And once this is sprint ends, we number one demo, whatever we did to the stakeholders to get their feedback. And number two, we retrospect as a team what was good and what could have been better in the last sprint. And then we repeat all this again in the form of a new sprint is starting with a new sprint planning meeting. So Dad said, this whole cycle is what all is Scrum is. There is no simpler way to understand it. Now here is the same thing in the form of a chart. So we have the product backlog, which we learnt is a big list of requirements that team gets together for a planning meeting and choose a smaller list of it called a sprint backlog. They will do in this sprint. And once again, don't worry about the finer details of how we do it. We will see those later in the complete detail. But in this lecture we are just scratching the surface of things. So we pick a small subset of requirements to do that is called the sprint backlog. We develop and test those things in the two or four weeks sprint. And then we go for a demo with the stakeholders. We go for a retrospective with the entire team. And we can also released this increment to the end users. So pretty simple discharge that you see here is the entire scrum at a high level. These other tasks that you see here, the product owner, the team, the scrum master. These are called as the Scrum rules and we will see about them later. And then there are different meetings or ceremonies that we do in the Scrum to get all this together and we will take a look at data also later. But this right here on your screen is the high level picture. And once again, if you look at it, it again comes down to just three words. Iterate the whole process that we are doing again and again. Deliver increment to the end-user, take feedback and incorporated that set. So dat was guys is crumb In a nutshell. Now before we pick on the aspects that we saw here in much detail later, let's see one last topic of this chapter in the next lecture. Thank you. 7. MVP & Incremental Approach: Hello everyone. So let's talk a bit about MVP and incremental approach in this lecture. Now we keep seeing that h l is all about increments. So how does that increment concept work? Let's take a look and you know what, let's understand it first, why an image? And then we will come back to these slides. So guys, what do you see in the image is what MVP or minimum viable product means. Remember not this top part, the bottom one, we give the customer a minimum, something that fulfills their requirements. We let them use it. We take their feedback and then we improve on it in the next increments. And we keep repeating this entire cycle, delivering new increments in the process. Now remember the top part of the image is the traditional approach, like the waterfall, where we are giving the customer thing in increments, but they cannot use it like they cannot use just two pieces of Tyre. They cannot give feedback on it. And by the time the end product is ready, there would be a lot of things that they would want change. And then we would end up with the same problem that we talked about earlier with the traditional approach. So that's fine. Hi l. What we are doing is we are giving the customer state skateboard so they can travel. Then they will come with the feedback that OK, I want something faster and with a sitting options. So we will give them a bicycle. Then they will again come back with the feedback that I want something that does not take any effort that is a faster, so we'll give them a motor cycle or a car and so on. So in each increment, we are giving customers something that they can use, something that they can give feedback on. Based on that, we are improving the product. So that's guys, what MVP is the minimum viable product. We give an initial version of the product to the customer that they can use. The get their feedback. We improve it in the next increments and iterations. So it's based on the build, measure and learn approach, meaning that we're building something. We are taking the feedback and we are reviewing it, measuring it. We are learning from that feedback and we are doing new things. And again, guys, if you think about it, this underlying concept is again, iteration and increment. We build the product, we measure the feedback, we learn from it and do it all over again. So that's the whole concept and it's important to understand because this is the bigger picture of hL and is crumb. Remember we can not do things in a single short. That would mean making the same mistakes that we did with the traditional approach. So we get together as a collaborative team. We do things in iteration. We designed the initial MVP. We put incremental improvements on it and that's all about it. That's all there is to understand. Awesome. So now we are at the end of this chapter and we'll learn the core concepts here. We learned what age I l is, what is Scrum is a high level of how they operate and how the whole MVP incrementing works. We will carry on these learnings into the next chapter and see all these and more concept in detail. So it's going to be a very exciting learning journey. But before I end this chapter, I just wanted to leave you with two thoughts that are most important for someone working in HIV. So the first thought is that h L is not just a guide book. The most important thing is a mindset. If we are highly number thoughts, If we are age Eileen, our work, our collaboration with their team, only then we can successfully implement a gel or a Scrum. So think about HCI as a mindset that's most important. Second, HIS or a scrum is not a magic stick that will solve all our problems. It can show us what the problems are or what the problems have been with the industry. But it is up to us to carry the agile mindset, work together as a team to solve those problems and deliver exceptional product to the end user. So again, the two concepts, keep a child mindset and second, use age IL-2. Know your problems. It's not a magic stick that can solve all your problems. So guys, with this thought, let's move on to the next chapter and learn about something that is known as the Scrum roles, the people that make up the Scrum. So I'll see you in the next lecture till then. Thank you. 8. Introduction to Scrum Roles & Scrum Stakeholders: Hello everyone and welcome to the third chapter of the course. Now beginning this chapter, we are going to pick one-by-one, the topics that we discussed in last chapter. And we are going to go in depth of them to know the full details. So that topic that we are going to cover in this chapter are the people who make up a Scrum team, more commonly known as the Scrum roles. And I pick this particular topic first because like we saw in the last chapter, the first core value of h l says individuals and interactions over processes and tools. So individuals are the most important component of a Scrum team. And so let's first know about them in this chapter. And you know what, we are going to cover this chapter very interactively. In fact, we are going to call the people the Scrum roles as our friends and we will meet them one-by-one and know what is their job, what is their responsibilities, et cetera. So let's begin. And here is the agenda of this chapter. So we will talk about the following roles. They stake holders, the Product Owner, the development team, The Scrum Master. And finally, we will discuss the scrum team dynamics. So what is the bonding and relationship between them? So let's begin. So guys, these are the different Scrum roles or the way that we call it in this course, our friends in the Scrum is starting from the bottom left. We have the stake holders who are external to a Scrum team, but they have the business requirements on which 13 works. Then we have the product owner who is like the captain of the team. He or she decides what the team has to do and he sets priority of things. Then we have the development team who do the coding or testing work. And finally we have the scrum master who is the like the guard of the team. And he or she makes sure that the team follows is crumb effectively and they are not blogged on anything. Also guys, on the extreme right, we have the end user for which all the work is being done. So although it's not a Scrum role, it's still, it's very important to always keep the end-user in mind because he or she is the one for whom all the work is being done and caring about their requirement and feedback is very, very important. So let's begin and take a look at our first rule, our first friend, I stake holders. So who are the stake holders? Well, a stakeholder is firstly someone who is external to the scrum team. And secondly, who has an interest or requirement or knowledge of the product being created. So think of the stake holder as the product management team in your company who is getting requirements from the end-user and passing it to the scrum team. Or somebody in sales, or even the CEO of the company could be a stake holder. When we are working on the terms and condition page, the legal department guy will be a stake holder because he or she will provide the text to be written. When a promotional flow is being designed, the marketing team member will be a stakeholder because he or she will use the system. And if the Scrum team is working on something and they take help from a person on another team because he or she has more knowledge of debt. That's also a stakeholder. So all these are like different stakeholders and these stake holders reveal their design, product or software. And they provide the feedback, either coming directly from them or from the end user. And this helps us to create a better and valuable product. So guys, dads the meaning of stake holder. Just to recap it quickly, he or she is external to the scrum. He or she has an interest requirement or knowledge of the product. And finally, he or she helps provide input to create a better product for the end-user. Alright, so now that we know who the stakeholder is, let's look at the other Scrum role or friends in the next lecture. Thank you. 9. Product Owner - roles & responsibilities: Hello and welcome back. Let's talk about our next friend in the Scrum. So guys on your screen is Kevin, and Kevin is our product owner. Scrum role that we are going to talk about in this lecture is the product owner, or PO In short. Now the product owner is a very important role in the scrum team because he or she is like the leader of the team and the voice of the customers need to their team. Kevin here is responsible for making sure that that team delivers valuable products to the end users or stakeholders. Kevin also has to define goals and creative vision of the product. So the scrum team that he's leading, the end developers or testers, they do not know about the product, what it is intended for, what is the requirement to be fulfilled? They only know about the technical aspects. So Kevin has to define those business requirements to the team. He has to translate those business requirements into the way debt that team understands and knows what has to be done. Also, Kevin has to manage the product backlog. So we saw in the last chapter that the Product Backlog is like a big list of requirements that has to be done. The task of managing that list is with the product owner. He has to create requirements in the backlog known has known as user stories, he has to write the low-level requirements or acceptance criteria in them. He has to modify the requirements, removed them, prioritize them, etc. And in fact, this is one of the most important responsibilities of a product owner. Data is to maintain the product backlog. Next point. Next responsibility is to manage the priority of things in terms of time, money is scope, etcetera. So pretty clear. Ready, Important task again. Next, Kevin has to oversee the actual development of product. So he has got the backlog setup, he has got the budget cleared. Now he has to make sure that the actual work of making the product happens is smoothly. So this, this means working with the development team, doing a sprint planning to fix the agenda of the sprint. Answer any query debt that team has support their work, et cetera. It also means working with stakeholders to plan the next incremental additions to the product or the release, etcetera. Fifth task, Kevin has to anticipate client needs. So again, to reiterate, all the work that we're doing in the team is for the customer, the end user, and the product owner has to understand what the customer needs. A lot of user requirements come from the stake holders, but they will be at a high level, how to best implement it, how to read the customer's mind, how to predict any risks they might have. All the, all this is the day-to-day work of a product owner and a very important task. Next, Kevin, the product owner, has to act as a liaison between the stakeholders, the scrum team, or even the users. So he's the primary communicator of the team. He communicates with the external guys. He communicates with the external guys. He's the communicator of the team. And finally, Kevin is accountable for each iteration and increment of the product. So he has to make sure that there's sufficient improvement, end of progress being made with each iteration, the final call on the quality of product performance, etcetera. It is with the product owner and he has to decide if the team can move forward or needs to go back and redo the things. So guys, on your screen, what you see are the primary roles and responsibilities of the product owner. Now before we conclude one more point, remember many times there could be a business analyst also on their team who will offload some of the work of the product owner. So the business analyst and the product owner roles and responsibilities overlap somewhat. He or she can take some of the work that the product owner does. All right, so as we saw, the product owner is a very important role in the scrum team. And the product owner is the one who has to juggle between a lot of responsibilities. Just to recap here is to work with the stakeholders on one side, the scrum team on the other side. He has to get the requirements, translate them. And he's the one who has to ultimately make sure that the entire scrum process is adding incremental values for the benefit of end-user. So very important role, lots of responsibilities on our friend Kevin here. Great. So now that we know about product owner, let's take a look at another role in the next lecture. Thank you. 10. Development Team - roles & responsibilities: Hello everyone and welcome back. Let's talk about our next friends in Scrum. So say hello to Andrew and Karen. Andrew is a developer on the team and Karen is the QA or tester. And they are both referred to as the Development Team. So just a quick note here, although the scrum team contains different roles, like developer or a tester, or designer or senior developer or senior tester is crumb does not call them separate. They are all just known as development team because they are developing the product as per the Product Owner's needs. So these are the folks who are responsible for delivering the end product. And that is their high-level responsibility just to summarize things in one sentence. But let's consider it in more detail. The first responsibility of Andrew and Karen is to understand user stories that are written by the product owner. They have to implement these stories. So obviously they have to know about it when the team gets together for the sprint planning or backlog grooming. And we will look at these ceremonies in detail in later chapter, the development team has to make sure that they fully understand what the user is. Story says, what the Product Owner wants, what are the exact requirements so that things can be designed in the same way. Next day also provide inputs in creating the user stories. And remember these are just inputs the development team generally does not create a user is storied, That is the work of product toner. But they can keep chipping with inputs or suggestions, etc. If it is a purely technically story, then dear input will likely be taken as the final call. But the primary responsibility of creating user stories is with the product owner. The development team only supports him. Third responsibility of our friend Andrew and Karen is to estimate the user stories. So estimation is a big topic in a scrum and we have a dedicated chapter on that later. For now, just know that development team will provide their estimates for the user story so the product owner knows how much work can be delivered in a sprint. Fourth, the development team will commit to user stories to be done in a sprint. And this commitment comes after the sprint planning. And it's something that development team has to be honest too, and ensured that that commitment is met. Next point is the work aspect. So writing code or testing the user stories that were taken it and ensuring that the quality product delivery to the end user. In fact, this is the bulk of the work of the development team and this is where their majority time and effort will go each sprint. So they are the ones who would be translating the requirements into effective work. All right, then we have the responsibility of identifying risk. And whenever we say risk, it has to include mitigation also. So if something cannot be done, Something is at the risk of being not completed. The development team has to raise it to the scrum master or product owner so they can help resolve it. And the final responsibility is to push the changes into production so that team design quality improvements after they scream is sprint ends or whenever the product owner wants, the team has to push those increments, those changes into the live environment so that the end user can use it and all their hard work can be put into use. All right, guys. So these were some of the roles and responsibilities of Andrew and Karen, our development team. And just to summarize once again in one sentence, the development team are the ones delivering the end product as per the requirements provided by the product owner. Okay, let's move on to the last role now, which is the Scrum Master. So let's see that in the next lecture. Thank you. 11. Scrum Master - roles & responsibilities: Hello everyone and welcome back. Let's talk about the role of Scrum Master. Now when we think of Scrum roles, the first term that comes to our mind is of a Scrum Master. But you know, I kept this intentionally for last so that we know what other roles are. And then we can see how the Scrum Master helps to facilitate the work for all of them. So guys, this here is our friend Bob, who is the Scrum Master of the team. And I'll tell you what Bob has a very interesting role in the team because he has to support the team. He has to make sure that that team follows is crumb best practices. And you also have to make sure that the team members are not blogged on anything. So the first bullet point you will notice about Bob is that he is the servant leader for the scrum team. And what that means is he has to follow a supportive leadership style. He has to support the team, serving the different roles in the team. He's serving the Product Owner in lot of things. He's serving the development team and he's also serving the organization by successfully adopting a child. So that's why, as I said, is Scrum Master is a servant leader. It is one of the most important and broad roles on the team. The Scrum Master helps the Product Owner in planning work with the team so that the delivery goals of Product Owner are met. And he also helps the Product Owner in managing the backlog of requirements. It is effective and up-to-date. Next, the Scrum Master makes sure everyone on the team understands the goals and scope of work that is required. So these are the ways in which the Scrum Master helps the product owner. He helps him with the backlog and he helps to define the goals and scope debt to everyone on the team. So everyone is on the same page and does the work that the product owner wants. Next, let's talk about the ways in which Bob, the Scrum Master, is helping the development team. So he's responsible for making sure that the team is not blocked. They are not distracted by external interruptions or other distractions and that they are able to work on the sprint commitments. And this is a very important job guys because you know that the team has committed to a set of work for the sprint. And if they are being sidetracked or distracted than that, work will be hampered for sure. So it's the job of a Scrum Master to make sure that does not happen. The team is able to focus on their commitments. Same time is Scrum Master also ensures that the team is not overburdened. So do during a sprint planning, the scrum master checks on estimations and capacity planning to make sure that everyone has sufficient work, but nobody has overwork. So these are the ways in which the Scrum Master's serves the development team. And finally, the Scrum Master is the HAL Coach of organizations. So Bob here has to organize the different is crumb ceremonies. Like they stand up, they sprint, planning, retrospective, etcetera. And we will see this ceremonies in detail later. But for now, the Scrum Master is the facilitator, the organizer for all these ceremonies. And lastly, he has to make sure that the scrum is being followed effectively in the organisation. And he has to make sure that the best practices are diploid. So these are the Scrum Master's contribution towards the organization. To sum it up, all like I said, is Scrum Master is a role with very broad set of responsibilities. When we talk about working in a scrum or H L and we talk about its benefits. Those benefits will only happen when a child or a Scrum is being followed effectively, when people are able to work effectively without any distractions. When the product owner's vision are transferred to the team and the job of a Scrum Master to ensure that all of that happens. So as you can understand the importance of Bob, the Scrum Master is a lot in the team. All right, now that we know all the different roles in a Scrum team, let's talk a bit about their coming together and working together. That is about the team dynamics in the next lecture. Thank you. 12. Scrum Team Dynamics: Hello everyone and welcome back. Let's understand the concept of Scrum team dynamics. So we know a Scrum team has a product owner, a business analyst Development Team, Scrum Master. So how do these guys come together to work together as one single unit? What is the synergy that binds them together? The answer to all this is, again, what we saw in the previous chapter. The first core value of debt is individuals and interactions over processes and tools. And this is what drives the team dynamics. So we saw earlier that is Scrum teams are self organizing and self-managing. That means is Scrum teams should not be governed by old methods. There is no development manager or testing manager within the scrum team to control resources or estimate things that team effectively managers itself. The team estimates for their work. They tell the product owner how much time it will take, who will do the task, et cetera, and they honor their commitments. Next point, the Scrum Master is there to act as a facilitator to organize things. And as we saw, that is one of the responsibilities of a Scrum Master. But you know what the team should not entirely depend on a scrum master. Let's save the Scrum Master is on leave, one day is still then the team should gather together and do their daily stand up. Because the concept, remember guys is of self-management, to interact, to collaborate with each other, not to the product donor or a Scrum Master not be dependent on them. Third point is Scrum teams succeed or fail as a whole team. So when we talk about age ILO reports in the later chapter, we will see that teams are assessed on how much is storypoints they're delivered, how many stories they closed, closed, etc.. So it's the team output that team reserved, not individuals, just like we have in sports. In fact, the word is Scrum itself comes from the sports of rugby. Next point is Scrum teams are cross-functional. They do not go by titles. So like we saw earlier also, there is a single development team. There is no developer, architect, tester, designer, etc.. There is no categorization if needed, the developer should also do that testing. The tester can take up the BA work, et cetera. Fifth, and we are talking about culture from here onwards. So it's a cultural thing. I Scrum teams typically R is smaller in size, that is around nine to 12 people is a very good number and this entire team sits together. There is no concept of isolation, there is no concept of separate cabins. That team sits together. They sit close to each other, so there's a bonding between the team, an open environment for discussion. And last point is a culture of effective communication in the team. So there is a daily stand up in the morning. Team sit together, they discuss on things they communicate with each other is Scrum teams have a team name, our team manifesto, et cetera. And all this helps to create a bonding, a synergy between their team. So guys, these were some of the points to achieve team dynamics because remember, HI, or is Scrum is all about individuals and interactions. So it's very important for teams to work together and deliver exceptional product to the customer. All right, so this brings us to the end of the chapter, but we'll learn some cool things here. We met our friends in the Scrum Team. We learned how the team dynamics works. Now in the next chapter, we are going to talk about their meetings, their interactions in what is known as the Scrum ceremonies. So I'll see you in the next chapter. Thank you. 13. Backlog Grooming & Introduction to Scrum Ceremonies: Hello everyone, and welcome to the fourth chapter of the course. So up till now we have learned the definitions of Agile and Scrum. And we have seen the different rules, all individuals that make up the scrum team. Now in this chapter, let's talk about the various meetings that these roles participate in, and that is known as the Scrum ceremonies. Now, before we move ahead, just to recap once again, is Scrum is based on the concepts of iteration and increments. So a Scrum is all about repeating iterations called sprints, in which we design increments for the end user. And to manage these sprints effectively. To run these sprints efficiently, there are a sequence of meetings or ceremonies that happen. In this chapter, we are going to talk about these ceremonies and in the order in which they happen. So you get the logical sequence of things. And in the end, we will look at them together and then we will understand the entire is crumb cycle. So let's begin. So guys, here are the contents of this chapter and these are nothing but different is crumb ceremonies. Now in one of the earlier chapter, we talked a bit about Scrum lifecycle. And I mentioned there how it is very similar to how we plan things in our daily life. So if you get that, you will get the purpose of these ceremonies also. So hear me out and watch the mouse pointer accordingly to see how it relates to Scrum. So guys, let's think about how we work in our real life. How do we handle things in our real life? So we write down a big list of things that we want to do in our life. And then we take a small subset of it that we decide to accomplish in say, the next week or two weeks, etc.. We'd think about daily, how much we have achieved on this goal, whether any fixes needed, whether something is blocking us, et cetera. And then when the week ends, we take a recap of how the things when we do the course correction, and then we repeat everything all over again next week with a new list. Sounds familiar, right? And let me tell you guys what we do in the Scrum is totally similar to this. As you would have guessed. We take a backlog or a big list of requirements, we pick a small subset of it, we work on it in the sprint. Once the sprint ends, we demo the work to our stakeholders so we can get there quick feedback. Then we do a retrospective of things to improve on. And we push the changes to the end user if needed. And then we repeat all this again and again. That's all it is. That's the entire cycle of his Come ceremonies. See how simple it is. So let's move ahead and check out each of these ceremonies in more detail. So guys, let's talk about our fastest crumb ceremony, the backlog grooming. But before that, I just wanted to mention that we will talk about each of the ceremony in the same format that you see on the screen. Meaning when it is done. Who are the attendees, how much duration the ceremony steak, and finally, what is their purpose? So let's begin. So what is backlog grooming? Now, as the name suggests, it's a grooming or a refinement of the backlog. So to understand this ceremony, we first need to understand what is this backlog? Now when we are in product development, we have to work on designing new requirements, right? So obviously we need to capture those requirements somewhere. And DAT IS whatever backlog is. The backlog is a list of new features or changes to existing features, bug fixes, everything that the team has to do. So think of it like a big list of requirements that is created by the Product Owner in consultation with the stakeholders, and that's the work that the team has to do. Now this list will obviously contained tons of features, right? So we need to review it periodically. We need to add details to it, we need to prioritize it, etcetera. And this is important, this is important guys because then only we will have items that are ready to work on in the next two weeks sprint the prioritized list of items. And this guys is exactly what backlog grooming or Backlog Refinement ceremony does. So let's look at the other slides. Is first, when is this grooming done? It is done before the sprint planning. And that makes sense, right? Because we need that top priority items ready for discussion by the sprint planning. Also, there is no hard and fast rule. How many days prior to a sprint planning you should do it. But like two through are two to three days before planning is good, we don't want to do it very early and then things might change. So let's just stick to two to three days before the sprint starts. The next sprint is starts. That should be good. Next point, who will participate in the backlog grooming? So we obviously need the product owner because he or she is responsible for the backlog. What should be done? What is the priority if the team has any questions, he or she can answer it. So we definitely need the product owner. Then we have the scrum master supporting him or her. Remember, the Scrum Master helps the product owner indifferent work. So helping him groomed the backlog, helping them refine the backlog is one of the Scrum Master's task. So the product owner would be there, the Scrum Master would be there. And finally, we need the development team, so we don't need the entire development team events. Some people from the development team will also do the work. Next. How long this meeting laughs. So again, no hard and fast rule, but like one hour is good. Remember we talked about doing backlog grooming toward three days before the sprint planning, right? And that means that that team would be end of the current is sprint. So obviously team will have a lot of work to finish and we don't want to keep them sitting for like five hours in a meeting. So one hour of grooming is sufficient if needed. We can do another session of one hour later, but that much should be sufficient. We don't want to keep that team held up for long hours before the next at the end of the current is sprint because they would have worked to complete. So we would do two to three days before the sprint planning. And like one hour if needed, we will do another one-hour session, but not too long. And lastly, what is the purpose of backlog grooming? So first, we review user stories that have to be done in the next sprint. Most important point, we have to get the things ready because the next sprint is going to come in the next two to three days. So we need to be ready with the content that we have to do their next, we have to resolve unknown and uncertain facts for correct estimation. So remember this is the first time that the development team is seeing the user stories. So they can have some questions obviously, and we have to resolve them in the grooming meeting. Who will resolve them? The product owner will dissolve them. And by resolving it is necessary so that team can estimate the work correctly. Third point, identify dependencies and risk beforehand. So we are planning to take the tau top priority stories in the next sprint. So let's identify any risks or dependency in them now only, so we're not stuck later. Next point, assign estimates to user stories. So this is like discussing story points and we will see estimation in much detail later in a later chapter. But for now, just know that each user's story has to have a story point for estimation. And this is storypoint is given ideally in backlog grooming. Some teams do it in a sprint planning, but backlog grooming is more ideal time to do it. Fifth, we split the user stories that are too complex or they are our unknowns. So if there is a lot of work in one user is story and team feels that they would not be able to do it in one sprint, then we can break it down into multiple stories. So that's also one of the agendas of backlog grooming. And last the key takeaway point. Successful grooming leads to effective is sprint planning. So the more effort we put in backlog grooming, the more prepared we get things done during backlog grooming, the more effective is sprint we will have. And did that make sense, guys? Because remember, our requirements are clear, our requirements are descriptive their estimated correctly, then things would be very easy in the next sprint. Alright, so that was all about backlog grooming. We have completed the first ceremony. Now we have a priority list of requirements. We know which things we have to work on in the next sprint. So let's take a look at the next ceremony. They sprint planning in the next lecture. Thank you. 14. Sprint Planning: Hello everyone and welcome back. Let's talk about the next ceremony. They sprint planning. So they sprint planning is the most important is crumb ceremony, and it involves several aspects. We will talk about those things here at a high level. And then in a later chapter, we will really learn a sprint planning in more detail, including importance and estimation techniques. So let's begin. Now if we recap into the last lecture, we did the backlog grooming and the team finalize the user stories in terms of priority order. The team discussed those user stories and if they had any queries or dependencies or risks, they were raised to the product owner and hopefully he or she has resolved it. So now we are ready to go into the next sprint and start working on those requirements, those users stories. But before that we need to plan on how to do it. And data activity is called as a sprint planning. When it is done, obviously at the beginning of the sprint, we cannot start the sprint unless we have completed sprint planning. Who participates in it? The product owner, the Scrum Master, and the entire team. So in backlog grooming all the team was not needed. But here the entire development team should attend because everybody will get there next. Sprints work from this ceremony only next how long it should last. So again, no hard and fast rule, but for a two-week sprint to our says, okay, remember if the Sprint Planning is running pretty long, it means that the team is not doing backlog grooming properly because the bulk of discussion related to the user stories should happen in the backlog grooming only and in the planning, we should ideally just be estimating and tasking things. And finally, let see what are the purposes of a sprint planning. So first thing, we review the backlog and we decide which items to pull into the sprint. Meaning what user is, stories, bugs, etc. The teams will work on this sprint. Remember the user's stories are already ready after backlog grooming and they are already arranged in the priority order. We just have to decide based on the team capacity, how many they can take in the sprint, like the top five stories or 80 stories or tennis stories, et cetera. Next we discuss the team capacity. So we talk about how much is the team's availability? Is anybody on leave? Is there a holiday? Does anyone have any other personal or professional work, etcetera? So this is a part of estimation and we will talk about capacity in full detail in the later chapter on is sprint planning. Third, we assign tasks to developers tester. So this is a major activity of a sprint planning. We have to assign the work, that task to the person in the team so everybody knows who's working on what. And remember in Scrum, this assignment should be mutual. Everybody should say on their own what they want to work on based on the skill, past experience, etcetera. Everybody should get equal and sufficient work in the assignment and nobody should be overloaded. Next purpose estimate timeframe for each task. So for each user is story, we create task like development, testing, UAT, etc. And the team provides their input like this particular task will take four hours, this will take five hours, etcetera. And this is the teams estimate of work. We then run it again, The available hours of that team, that total capacity. And based on dat, we decide how many stories we can take from the backlog in the upcoming sprint. So again, more on these estimation capacity, etc, in the later chapter. For now, just know that is sprint planning is the ceremony in which we estimate timeframe for each task. Next point we discussed known risk dependencies that can disrupt a sprint. So we talked about risk in the grooming also, if they are not addressed, if there is something else that has come up like if not enough people are available in the sprint. If there is some information that has come up new and it is not fully address, these things should be brought up during the sprint planning so that we know beforehand. And then things would not hit us suddenly in the middle of the sprint after we have already committed to all the work. And last point is Scrum Master facilitates the meeting to ensure effective discussion and agreement. This is a very interesting point, guys, and we saw it earlier also that the scrum master is the guy who handles all the ceremony, who runs all the ceremonies. So when we are in the sprint planning, when we are deciding the work to be done, the Product Owner, we'll obviously try to push for more work because he or she has the pressure from a stake holder to deliver things quickly. Write the team, on the other hand, will estimate conservatively and they, and so there would be a difference coming up. There could be raised, there could be dependencies, unknowns. There would not be sufficient work for everybody. There could be overwork for everybody. All these things can happen. So there's multiple thought process that is going on. And it is the work of a Scrum Master to handle all these aspects. The Scrum Master facilitates the meeting to make sure that all points are discussed. The Product Owner answers all the questions that our team has had. The team does not have any unknowns, that team estimates things correctly if there are any risk they are handled beforehand. We saw our dear also did the work of a scrum master is to get the best possible and quality output from Team. And those skills are put to use best during the sprint planning session. All right guys, so this was all about a sprint planning. Now remember we again have a chapter later to talk about is sprint planning including estimation in much detail. For now, let's move on to the next ceremony and see what data is in the next lecture. Thank you. 15. Sprint Daily Stand Up: Hello everyone and welcome to the next ceremony, discretion, the sprint daily standup. So let's recap what we have done till now. We did the backlog grooming, we prioritize the stories. We did the sprint planning. We have taken the user stories, we have created tasks for everybody so everybody knows what they have to work on. And we have started the current is sprint. So now we are in the current sprint. And as long as this is sprint is running each morning, the team will do a quick 15 minute meeting that is called the stand-up to talk about the progress and roadblocks. So let's talk about this ceremony in detail first, when it is done. So it is done every day of the sprint. It is done usually in the morning before everybody starts their work. So the team has the agenda set out for the day. Now, some teams do it twice a day at the starting and end work hours. That is totally okay. There is no hard and fast tool. It depends upon the team's internal agreement. But usually one meeting at the start of the morning is ideal. Next, Who are the attendees? The Product Owner, the Scrum Master, but most important, the entire development team. So most people think of stand-up as a reporting exercise. We're the team gives their status to the product owner, but that's not entirely true. The meeting is for the team members to tell there is statuses to each other. So even if the product owner or the Scrum Master is not present in the meeting, the team should still gather for stand-up and they should discuss things. Because remember, they are giving their status to each other, not to the product owner or a scrum master. Next point, what is the duration of his stand-up? So it should be very short, not more than 15 minutes. Remember, we just have to discuss three quick points that are written below. It's not a full hour-by-hour status of work. And so there should be no side conversations, no deep details. If there is some additional discussion that is coming out of the standup is status. The individuals or team can discuss on it after everybody has spoken, but that should not hijack the stand-up meeting. We want to wrap up the stand-up meeting in ideally 15 minutes. And finally, what is the purpose of this ceremony? So first and foremost, to answer three questions. What did I do yesterday? What will I do today? Do I have any blocker? So this is the golden format of stand-ups everywhere in Scrum. And each team member should stick to answering these three questions. Next, we communicate progress and raise impediments. So the basic idea of standup is to share progress that is being done by the team daily. So we know we are moving in the right direction at the right pace. And to raise any impediment or the blocker data team has have so that we know what is holding the team back and who will help resolve that blocker, the scrum master, or the product owner. Last point, collaboration opportunity may come up based on the statuses. So let's enter. Developer a says that I am blog because I cannot get the source code on my local machine or developer be reports in the standard that I am stuck because it is a new thing for me and I haven't worked on it recently. So there is a collaboration opportunity here. Some other developer in the team can say that, ok, I know Dad thing, I will help you remember a scrum talks about collaboration in their team and is stand-ups are a great way to promote that collaboration. Just a word of advice. Do not start talking the fine details in the standup itself. Just said at no worries, I can help you on that. And then the two individuals can sync up on it after everybody's done with the stand-up. So stand up is a great opportunity to report progress, to report any blockers, and to identify collaboration opportunity between the team. Because remember the sprint completion is the team's responsibility. Completing all the wealth that they have committed to is the team's responsibility. Soda team is giving a status to each other that are telling their progress. They are telling their blocker, they are helping out each other. All right. So now we know what is stand-up ceremony is. Remember three questions. What did I do yesterday? What will I do today? And do I have any blocker? Alright, let's go carry on our learning momentum. And let's talk about the next ceremony in the next lecture. Thank you. 16. Sprint Review or Demo: Hello everyone and welcome to the fourth ceremony discussion, which is the sprint review. So, so far we did the backlog grooming and we prioritized our requirements. We did the sprint planning and estimated and tasks those requirements. We started the Sprint and on each day with data quickest stand-up to discuss the progress. Now we are at a point where they sprint has completed and we are going to do our first post is printed activity, which is called a Sprint Review, or more commonly the demo. But before I start on the details, let's think about why we need the ceremony. We already took the requirements, the stakeholders know what that team worked on. So why show it to everyone now? The answer is early feedback. Remember, HIS Scrum is stress on early and continuous feedback. So we want to get that feedback and we want to improve the product based on debt. And we also want to get that feedback early on. So that is why we are doing this review immediately after the end of the sprint. Makes sense, right? So let's see the fine details now. First, when is the sprint review or demo done? So obviously at the end of the sprint now we don't want to wait ten days after the end of the sprint. We don't want to do it as soon as possible once the sprint ends. So ideally the teams do it on that day there is sprint ends and then they go into the sprint planning for the next sprint so that if there is any output coming from this demo sessions and in nu, improvements that are needed, they can quickly take it up in the next sprint also. So again, when is the sprint review done at the end of the sprint? Who are the attendees? So it is the full list, but most importantly, it needs the participation of the project is Stakeholders and the product management teams. Because remember from the last chapter, the stakeholders are the ones for whom we are doing all the work. So it is important to demo them the things. Next. What is the duration of this review meeting? So 15 to 30 minutes is good, maybe an hour. Again, there is no hard and fast rule, but it is quick demo of the new features developed. We are going to show them major flows only. We are not going to show them each and every detail scenario. So 15 to 30 minutes or max, one hour is a good time limit. And finally, what is the purpose of doing this review? So the first one is to showcase the work that is done by the team in the past is sprint. So it's the first time that they stake holders are going to see the work for which they had given the text or texts requirements. So the product owner had gone got the requirements from the stakeholders here, translated it into do-able acceptance criteria. As for the team, that team worked on it, they delivered it. So now is the first time that they stake holder is actually going to see that thing in action. Second and most important feedback from stakeholders. So like I said, each aisle and Scrum is dependent upon early and frequent feedback. So they sprint demo, we'll make sure that that happens. Next thing, celebrate accomplishment and teamwork. So the entire team has put in one is sprints worth of work to create these features. They have worked hard for the two or three weeks, whatever was the length of the sprint in the organization. And when that feature is shown to the multiple people, the management guys, they stake holders, it brings a sense of accomplishment to the scrum team. It gets them motivated to see the output of the hard work that is being demoed to everyone. Last point, ideally only fully demonstrable and tested work should be shown. So this is like a disclaimer. We should not show things that are partially ready or that have several defects. Remember, the output of each sprint is what we call as a potentially shippable product. So we should only present things that are fully ready and tested. And who makes that call? Who makes the call on the quality of the product, on the performance of the product, the product owner. Great. So now that we have completed the Sprint and showed our work to the stakeholders, there is still one set of money that is left. We are not done yet. We still have two more ceremonies to be left. So let's talk about the next one in the next lecture. Thank you. 17. Retrospective: Hello everyone and welcome to the next ceremony discussion they sprint retrospective or also known as the retro and short. So what is this retrospective and why are we doing it? We already took an newsprint. We committed to all the work that we had done. We demoted to the product stake holder. So what is the need of doing this? One more ceremony Now, let's see. So the answer is that is crumb contains repetitive activities. We know that right? We do the grooming, we do the planning, we complete the sprint, and then we start with another sprint, right? But in between all of this, we need to figure out that what all went good and if there is any scope for improvement, it is very important to do this analysis because that's how we will improve on things else. It will be just same reputation of things with the same problems going on again and again. So that's why retrospective is very, very important. Unfortunately, many teams do not do it. They do not care for it. But it is very important to take out that time to do retro after every sprint. So when it is done, it is obviously done after the sprint has ended. Again, we don't want to wait too long after the sprint has ended because we want feedback on the last sprint and as Days pass on, people will forget about it. So the idea is to do it as soon as the sprint has ended, maybe the same day or next day after demo, etcetera. So that the sprint is fresh in the memory of people and they can give correct feedback. Next, who attempts it? So the product owner, the scrum master, the development team, the entire team should attend it. We do not want any external person. We do not want the managers, we do not want the stake holders. No, this is the team's analysis. So the team should do it all. The team should be present and they should honestly do it within themselves. Next, what is the duration? So that duration is like 30 to 60 minutes. Again, there is no fixed rule. The idea is to discuss things and to make sure that everybody gets sufficient time to speak. Finally, the purpose of first and most important, gather feedback to make the process and culture better. Remember, we have to do the same things, iterate on the same things again and again in Scrum. So they sprints, will go on. We will do is print one to a hundred, two hundred, but we must learn something from each sprint. We must know how to make things better with each Sprint. And dad is the objective of doing retrospective to find out the problems with the sprint, to find out what were the good things and how we can improve further. And that's why we talk about two things. First, what went well? And number two, what could have been better? So anything from the just completed is print enter team things wasn't good as step and should be done again. Or if something was not good and something that we can improve on, we should not do. We bring out all those things? Everybody talks about it. That's the purpose of retrospective and honest review of the sprint debt went by. Next point, remember the idea is not to highlight flaws or make it a blame game exercise. Like I said in the last chapter in Scrum, the wins and failure are entire team's responsibility. So the retrospective should be done honestly. It should be used to improve on things. And more importantly, it should not be taught of a blame game exercise. We are, we are just pointing out everybody's bad things. It's for the improvement of print, it's for everybody's betterment. So let's keep it honest. Let's not blame everybody. Lastly, the practice of regular retrospective is strengthens the continuous improvement aspect. So we have to learn from the past, we have to improve on things. And that's the purpose of retrospective. Alright, so that was all about retrospective guys or retro, If we now have just one more ceremony left. So let's talk about it in the next lecture. Thank you. 18. Release Planning: Hello everyone and welcome back. Let's talk about the last topic of Scrum ceremonies known as release planning. So guys, release planning is an important ceremony in a scrum, although you will see most courses not talk about this one. I included it here because it is important to understand these details. We need to know when to deliver the product increment to end user so they can use it. And all our hard work comes to use. So guys release planning is all about deciding what plant increments we want to push out to the end-user. And when do we want to do it? Remember the purpose of every sprint is to design new instruments and we have to figure out when to release those increment to the end-user. Some organizations will release it into production after every sprint. Some organizations will do it after two. Sprint is no fixed rule to it. It is called as release cadence, and it totally depends upon the business requirement or the product roadmap, or the cost or the value being added to product. These are the multiple factors on which our releases would be based. And we will talk about all those aspects during this release planning ceremony. So first of all, when it is done, ideally we should do the release planning at frequent intervals. So we should do it like after every sprint. Because remember based on when and what we have to release, we might have to modify our backlog. We might have to re-prioritize requirements, realign resources, etcetera. So it is best to do it at frequent intervals. Next point, who attends the release planning meeting? So it should be the stakeholders, the product owner, and the entire scrum team. Because remember everybody from the development team might have some role in the release. The developers will deploy the code, the testers would verify the code so everybody has some work. So it is good to include the entire scrum team or a small subset of it. Next, what is the duration? Again, no hard and fast rule. 30 minutes to 60 minutes is a sufficient duration. And lastly, what are the purposes of this ceremony? So first, as we discussed, the release planning helps to figure out what all features we can deliver to the customer. And remember, things might be guided by a feature list like we want to do a release once all these features are ready. Or it might be driven by a date like we want to do a released next month, second Friday, so on so whatever is the criteria we discuss about those things in the release planning ceremony. Next, we look at the product roadmap and we make the decision. So it is guided by the product requirement, the stakeholder inputs, all these factors together to decide when do we want to release the product. Third, we also discussed the balance between customer needs and scope. So the customer may want something new every week, but there are genuine concerns of things not being ready in that short time or for that matter, there could be concerns about the budget also. So we talk about all those things. We try to find a balance between the our cost and releasing frequently for the user. Next point that release frequency will varying or each organization, like I said, some teams will release every sprint. Sometimes some teams may release after to a sprint. There is no hard and fast rule. It depends upon the organization, it depends upon their business needs. Last point, the release plan is not a static plan and it can change based on new addition to the backlog. So that is why it is important to revisit things. Regularly, discuss things with the stakeholder and do this, this release planning ceremony frequently. Alright guys, so with this, we come to the end of all our Scrum ceremonies. Let's recap things quickly in the sequence in which they happen. So we do the backlog grooming before the sprint starts. Then for starting the sprint, we do the sprint planning to kick start the sprint. Each day of the sprint, wildest print is running. We will do that daily stand up. Finally, when the sprint ends, we will do the demo and we will do the retrospective. We should also include the release planning somewhere here, like after the sprint ends and at a frequent interval. So guys, remember all these ceremonies are fundamental to the scrum. They are time-boxed and each of them serves an important purpose, like we saw. We saw their importance, we saw their frequency. And you can recap this chart very quickly to recap when you need of when that ceremony happens and what is their purpose. Alright guys, so we saw the various is crumb ceremonies. Let's move on to the next chapter and discuss the next component of Scrum, which is the Scrum Artifacts. Thank you. 19. Epics & Introduction to Artifacts: Hello everyone and welcome to the fifth chapter of the course. So far in our journey, we have seen what is h i and what is a Scrum. We have seen the different persons in a Scrum team known as the Scrum roles. And we have also seen the different meetings or is crumb ceremonies that they do to develop a product or increment. All in all, we have got to know the who and the how part of the story. Now in this chapter, let's learn about something called the Scrum Artifacts and how it helps the team in its journey of Scrum. So let's begin. So these are the topics that we would be covering in this chapter. But before that, a very important disclaimer to avoid any confusion. Remember the Scrum Artifacts are actually just the product backlog, the sprint backlog and increments. So number 456 on our list. However, to understand them, we also need to be appear off epics and user is story, and that is why we are moving in a logical order. In this chapter, we will first talk about Epics, then we will talk about user stories. And because user stories are the source of requirement for our entire team, we will see the best practices to write good user stories. This will help us know how to write them correctly in our organization or keep a check if someone else is writing it, then we will move to talk about our artifacts. The Product Backlog is sprint backlog and increment so that things are clear for us. And finally, we will learn about something called the definition of done, which is a very interesting concept and documentation of the agreement of the Scrum team. So that's why I included it in this chapter. So let's begin our journey and let's start with the first topic. So let's first talk about what is the meaning of Scrum Artifacts. So if we talk in general terms, the artifact word means the documents that we create. And the purpose of these documents is to provide us key information and make sure that everybody on the team has the same understanding of things. Now when we say provide us key information, what is the information that these artifacts can provide? So to understand that, let's forget is crumb for a moment, and let's think about working on creating or modifying a product in general. So what is the different information that we would need if we are doing that? First of all, we would need to know what is the requirement. Because those are the requirements on which we would be working. Next, we need to know the how part, how we would be approaching that requirement, what is the part that we would be doing, etc. And finally, we also need to know the progress, how much is done, how much is remaining, et cetera. And guys, this is the same concept that applies to a scrum. Also, artifacts helps us to provide key information like number one, the product under development. So these are nothing but the requirement that we want and they are stored in the forms of epic and user stories. Who writes them? The product owner writes them in consultation with the stakeholders and with the help of a Scrum Master. And where does the product owner keep these user stories? He or she keeps them in the Product Backlog. Second, upcoming activities. So we already saw that during the sprint planning, we take the user stories from product backlog. And based on the team's capacity, we finalize a sprint backlog. That is the list of user stories that the team would be working on in the upcoming sprint. And last point the work completed so far. So this is reflected in our product backlog or sprint backlog completion also. And remember there are multiple reports also show this information. And that is why you will see several authors straight reporting like burndown chart, etcetera also to be an artifact. But here in this course we will stick with the original artifact list and we will treat only the Product Backlog is sprint backlog and increments in this chapter. For other reporting methods like Burndown or velocity chart, we have a dedicated chapter later entirely covering the different is crumb reports. And finally, last point, what is the advantage of having artifacts? So it provides key information to everyone and gets everyone on the same page in terms of understanding. For example, let's say if we did not had any product backlog, how will they stake holders are team members, know what all we have to do and how much work is remaining. Everybody will have a different understanding of the expected work and this will cause confusion in the team. So artifacts helps to resolve these kinds of problem. Alright, so as I mentioned earlier, the key artifacts in the Scrum, our product backlog, a sprint backlog and increments, and we will get through them in this chapter. But to clearly understand things we first need to know about epics and user stories. So let's start with the first epics. So guys bought are these epics? If we talk in general terms, epics are basically big requirement. So in this chapter, much of what we are talking about is in reference to requirement only. And the biggest documented piece of those requirements is epics. As the definition on the screen says, an Epic is a large requirement that can be broken down into small piece of work called user stories. So that's the definition of epic. Let's say, let's consider an example. Let's say that we want to make an e-commerce website and we want to create its checkout or order placement flow. So that is a very big requirement with many pieces of work, we will have to take care of Checkout by credit card, by PayPal, Apple Pay and much, much more. So checkout redesign would be an Epic. And to do the subsequent requirements of credit card checkout, PayPal checkout, Apple Pay checkout, etcetera. We will create user stories, that is the example of epics and user stories, and that is the relation between them. We will see this more clearly when we do the practical project later, don't worry. But for now, just keep in mind that big requirement is epic and we create a small requirements or user stories from it, as simple as that. So let's read for the first, epics can be considered as the top tier of product development work. So product development means requirements. And these requirements come from Epic, which are broken down into user stories. So epics are the top level or top tier of requirements in product development. Second, epics can extend multiple teams, multiple projects, and a Scrum board. So this sounds logical In our example, epic of Checkout redesign. One is Scrum team will handle check out on the website. Other team will handle backend order processing. 13 will handle handle sending out emails when the order is placed, etc. So epics are big enough, they can include multiple teams and there is Scrum boards. Next point, epics are often delivered over multiple sprints. So obviously because epics are so big that we cannot do them in a single sprint. It is multiple sprint off work. It is divided into multiple user stories and for multiple Scrum teams. And last point, epics evolved over sprints, getting more information. So as we work on topics, as we will be working on our checkout redesign epic, we will learn more things. We will get new requirements which we did not think of earlier. And so we will have to create new user stories to tackle those requirements. So as we progress, as we move ahead in our sprint, we will get new users stories tied to these epics. Alright guys, so dat was all about epics, but you don't have to remember all these things. Just remember two key aspects. Number one and epic is a big piece of work. And number two, it is broken down into smaller user is stories that usually involved multiple team and a sprint. Dad said That's all epic is. Great. So now that we know what an epic is, let's talk about its handling in the form of small pieces called user stories. Let's talk about these user stories in the next lecture. Thank you. 20. User Stories: Hello everyone, and welcome to the topic of user stories. Now this is going to be a very important lecture because whenever you are working in the Scrum, you will deal most of the time with user stories. These user stories will be the source of all requirements and you will reference it whether you are quoting something or testing something or discussing with stakeholders. So that is why we will talk in great detail about user stories in this lecture and the next one. So let's begin. Okay, it's first of all water user stories. We already saw in the last lecture that the big chunks of requirements are called as epics. And from these epics we create a smallest, small requirements called user stories. We take these user stories in a sprint and we work on it. So user stories are basically the smallest unit of requirement in Scrum that can be delivered in one sprint. So when the team gathers for the sprint planning, they will take like five or seven or ten user is story-based on their capacity and they will embark on to complete all those user stories within one is sprint. So that's what a user is. Story is the smallest unit of work that team can deliver in one sprint. Let's see the bullets first, user stories are general explanation of requirements expressed in the terms of end-user. So what is in the user stories requirements and how do we write down those requirements? Very important. We always write down DEM down in the perspective of an end-user. If we talk about the checkout with credit card on our e-commerce website user story, we will write it like as a user, I want to place an order with a credit card and then we will give the further details. We will never write it like a technical person or a business person know, our user story is always written from the perspective of an end-user. Next point, how do we write down detailed requirement aspects in the user story? We'd write it as something called the acceptance criteria. So the acceptance criteria is a set of predefined requirements that will explain what is needed to be done. So for example, for our credit card is story we will start with, as a user, I want to place an order with a credit card. And then we will mention the acceptance criteria is like number one, user has the option to enter a credit card. Number to user has the option to enter a debit card. Number three, user has the option to view their list of safe guard and like that. So that is the structure of a user story. And don't worry, we will see an example also later in the lecture. But just to recap quickly, the structure goes like as a user, I want to so and so, and then we have that detail acceptance criteria has third, who write the user is story, so we already saw it. It's the product owner. The Product Owner is responsible for writing user stories. He or she can take help of the team if it is needed. He or she can take help of the Scrum Master two facilitated, but the ultimate responsibility to create user stories, to modify them, to update them, to prioritize them, et cetera. Everything is with the product owner. As we saw in the last lecture, it is one of their primary responsibilities. And last point, user stories are a component of estimation. So we will talk about estimation in much detail in the later chapter. But for now, just remember that for each user's story, we estimated using something called story points. So these user stories also serve as a medium for estimation. So let's move ahead and let's take a look at how we're actually user story looks like. So guys here is how a user story looks like. And this is problem. Probably a User Story created for printing something from the issues dashboard like G2 or something. But don't worry, just ignore the context. Let's just focus on the format. So as you can see, the user story starts with the word as a user. So like I said, we always write the user stories from the perspective of the end user. We will never mentioned it from a business standpoint. We will never mentioned it from a technical standpoint. It will always be returned from the viewpoint of an end-user. And that's why the user's story always starts with the line as a user. And then you can see we have the detailed requirements, that is the acceptance criteria. And acceptance criteria have been written very nicely in bullets. So data, it is clear, everything has been explained in great detail. So now you know when the team gets together for the backlog grooming or the sprint planning, they will go through this story. They will read the acceptance criteria if they have any questions they can ask the product owner, he or she will answer it and so on. But we have to give each and every detail to the tiniest level possible in this acceptance criteria. Remember, we can add any technical details also like if there is some technical information debt will help the development team. We can add it at the bottom after every business user detail. And if we, if needed, we can attach a nice mock-up also. So the mockup helps in visual clarity, especially if we are doing a design change or if we're doing a UI intensive change, then it is always helpful to attach a mock-up to the user is story. So that's how a user is. Story looks like Guys. And now that we know what a user is, story is watts, it's formats, what sits importance. Let's move ahead and let's learn about the best practices to create a user story in the next lecture. Thank you. 21. How to write great user stories: Hello everyone. Let's talk about the best practices to write a great user is story. So as I discussed earlier, writing user story is mainly the Product Owner's job. So if you are going to work as a product owner, you need to know this. Or if you are working as a business analyst or developer or a tester, you still need to know it. 22. Artifact 1 - Product Backlog: Hello everyone and welcome to the first artifact, the product backlog. So guys from the previous chapter, we have an idea of what the Product Backlog is. Quite simply, it's a list of oil deliverables that have to be done in a product. So if we want to do some new features or modify some existing ones, or we want to fix some bugs. These are the things that make up the product backlog. Next point, the Product Backlog is always tried to be kept in a priority order. So the product owner should revisit the backlog frequently because he is responsible for the product backlog and he or she should keep it in a prioritized manner. Otherwise, we would not know what is urgent. We would not know what needs to be done first and it can get lost in the list as product backlog expand. So let's go through the bullet. The first thing on the screen as you see is the definition of the product backlog, which like we discussed, is number one, a list of all deliverables that have to be done. And number two, it should be in the priority order. These are the two key takeaways from this lecture. As the first bullet says, product backlog includes new features, changes, bug fixes in France, changes, etcetera. So these are some of the things that we will have in the product backlog like we discussed. And in fact, based on our past learning, we can refine this list further and just simply said at the product backlog would ideally contained number one, user stories and number two bucks. Second, The Product Owner organizes these requirements or user stories as per priority. So very important, like we discuss, it is necessary to keep the product backlog in priority order. And who is the person that takes care of adding new stuff to product backlog or maintaining its priority order, the product owner. So we saw in one of the earlier lectures that creating the backlog and maintaining the backlog is one of the primary job responsibilities of the product owner. Next point, the Product Backlog can keep growing and it acts as the place holder for all future changes. So in any product development methodology, there would forever be new addition to requirements. And so the product backlog would forever keep changing with new stuff added, removed, or re-prioritize. And last point, each sprint the team takes user's stories from product backlog to be done in the current cycle. So any change that has to be made in the product, it is first added to the product backlog by the product owner. It is discussed with the entire team. It is parasitized with the entire team, the estimate on it, and then it is taken in one of these prints to work on. So guys, that's it, that's everything about the product backlog. Once again, in summary, you can think of the product backlog as a prioritized wishlist, knotted to-do list because we might change tracks and not want to do everything in there. So we call it as a prioritized wish-list that is handled by the product owner. And it serves as a big bucket of requirement from which we pull the small requirements and develop it in a sprint. So guys, this was our first artifact. Let's check on the next one in the next lecture. Thank you. 23. Artifact 2 - Sprint Backlog: Hello everyone. Let's talk about the next artifact I sprint backlog. So guys, at this point we have a product backlog that contains the user stories for each new requirement that the team has to do. Now the team will groom those stories in the backlog grooming. And then they will gather for a sprint planning session where they will take the first five or first ten users stories to work on in the upcoming sprint based on their capacity. And this group of five or ten users stories that did take is our next artifact known as the sprint backlog. So as you can see, the definition also says a sprint backlog is a subset of Product Backlog identified by team to be completed during the sprint. So we already saw the product backlog. It's a big list of requirement that team takes a small set of requirements from there and makes up the sprint backlog. And how much would be data sprint backlog? It would be that much work that the team can complete during the next sprint, as simple as that. So let's move ahead and read the bullets. So first in a sprint planning that team selects users stories as per priority defined by the product owner and the team capacity. So we already saw about this when the team would gather for a sprint planning, we'll go over the Product Backlog, which is in a priority order. Remember, and the team would pick up the first five or ten stories based on their capacity. They will do this five or ten stories in the current sprint and data is what the sprint backlog is. Next point for each user's story in the sprint backlog, that team identifies the task needed to complete it. So this is the other aspect of sprint planning that we discussed in the last chapter. Just taking the stories and creating a storyboard is sprint backlog is not sufficient. We need to figure out who will work on it. This process is called as tasking. It basically means assigning tasks to each individual team member. So far, one is story. We will assign development tasks to one guy, testing tasks to one guy, mock-up designing UAT, et cetera. And individual team members will take up this task and work on it. So this helps to clarify who will work on what, how much work each guy has. Are the owner-occupied? Do they have under work all these things? Next point, a sprint backlog should ideally remain unchanged during the duration of a sprint. So once we have committed to doing like tennis stories in the sprint, we should ideally not make changes to that list. And remember I am using the word ideally because let's say that if somebody has capacity available because they finished the work, or let's be more realistic. And let's say if something urgent came up, then we will surely have to pull in new things to the sprint backlog, right? But other than that, we should always stick to finishing what we committed during the planning. Also note that in case we are pulling in something new, that team needs to figure out how to accommodate it. They can not do all the already committed work plus this new work, right? So they might need to re-prioritize thing, they might need to remove something, they might need to take help from other team, etc. So ideally, we should not make changes to the sprint backlog once they sprint has started, but it most likely happens. And when it happens, when we have to take something new, we have to think about all these factors. We can do the new taken up work also. And last point, guys, if any item is not completed, it can be added back to Product Backlog and re-prioritized at the start of next sprint. So until now we have talked about the happy path, mostly where we took like ten user stories in a sprint. We completed all of them and then we started with the next sprint. But that's now how it happens always, sometimes things will not get closed and they will get rolled over to the next sprint. So at the end of the sprint, we check the sprint backlog. We see what all is not done and getting rolled over. And we can either continue working on it in the next sprint or we can move it to the Product Backlog and re-prioritize it below other stuff. So this is an exercise that we do at the end of every sprint. And before they start off next sprint, we have to figure out what to do if any of the things in the sprint backlog did not get closed. So guys, this was all about our second artifact. They sprint backlog. Remember we will once again go into the full aspects of Sprint Planning including estimation and how we do all these, taking up the stories, think kappa sitting thing, et cetera in the later chapter four now we have just seen a high level of the product backlog, our second artifact. So let's move on. Let's check the next and last artifact in the next lecture. Thank you. 24. Artifact 3 - Increments: Hello everyone. Let's talk about the last artifact, the increment. So guys, we have used this word a lot in the course. So let's see it in complete detail. What is an increment and what does it mean? So in simple terms, and increment is an addition to the product. In our discussion so far, we have seen that in Scrum that team creates a product and then every sprint they add new features or increments to it. Each of these increments adds to the previous version of product, creating a better, improved and quality product. So that's the definition of increment. Its the product enhancement from current is sprint plus all previous sprints. Let's see the other details. First, at the end of a sprint, the Product Increment should be in a useable condition and it should meet the team's definition of done. So remember whatever increment we are doing in the sprint, we can only consider it valuable if it's in a useable condition and if it satisfies the teams approval criteria known as definition of done. We will see this definition of done in a later lecture. But for now, just consider that it's a checklist of all the criterias that dot product should meet in order to be considered it as completed. Second, the increment must be in a useable condition regardless of whether the POD sides too release it or not. So this looks pretty similar to the first, but there is one additional cash debt is releasing the product. Remember one of the criteria of Scrum is that each sprint should result in what we call a potentially shippable product. So that means whatever we do in a sprint, it should be good enough to be released to the end-user. Now it's another question whether the product owner wants to release it or not. He might want to release it after two is sprints. He might want to release it after one month entirely his call. But nevertheless, each increment must be in a useable condition and it should result in a potentially shippable product. Next point with each Sprint, the Product Increment increases towards the end vision or goal. So pretty clear, we have a product roadmap, our vision of how we want the final product to be. And with each sprint, with each increment, we are little by little adding to that roadmap, that end goal. And last point, guys, the core aspect of Scrum is to deliver a done increment. So if someone asked us, what do we do in a sprint, the answer is that in each sprint we create an increment to the product. We create a nice, improved, high-quality increment of the product. And that increment meets the productive roadmap. That increment meets the team's definition of done. Alright guys, so dad brings us to the end of all the three artifacts, the product backlog, sprint backlog and the increment. Let's recap all the three artifacts once again via this image. So we have multiple requirements that can come up from the stakeholders in the form of new features or defect fixes or technical additions, etcetera. The product owner takes up these requirements and creates a product backlog, which is like a big wish list of requirements of the things to do. We take a small subset of requirements from this backlog and we create the sprint backlog, which is the work that the team will take on in the upcoming sprint. And finally, once the sprint work is completed, we have an increment to the product, which is like new edit enhancements through our product and it should be potentially shippable. So this guy's on your screen is a summary of all the three artifacts that you can quickly recap for your memory. Alright, so we have seen all the three artifacts, but there is one term that we heard a lot in the last slide and that is definition of done. So let's also see what data is in the next lecture. Thank you. 25. Definition of Done: Hello everyone and welcome to the last topic of this chapter. Let's talk about something called as the definition of done. So imagine we are working in a sprint and we take a user story to design the checkout with credit card like we talked earlier. So there are like seven acceptance criteria in the user story. And at the end of the sprint, developer comes up and says that I have done all those seven Changes. Everything is good. We can consider the story has done. Now, should we just go by his or her understanding of w1 and close their story? No. Right. We should rather have a list of evaluation criteria to make that judgment. Because remember, each is 2D in the sprint should add to the increment and result in a potentially shippable product. So if we don't have a set of rules, debt certify the user story has done. We might be adding incomplete or low quality things to the product. And this is where the definition of done comes into picture. As a Scrum team, we should create a checklist. We should create a list of criterias that that team can cross-reference. And based on that, they can say that the user is stories done or not. And dad checklist is known as the definition of done. It's a list of criteria that that team is supposed to complete successfully before declaring the user story to be done and before considering the product sufficient to release. And what are the things that are commonly present in the definition of done, we can have criterias like technical design should be reviewed, code should be unit tested. Functional testing should be complete with no critical or Blocker defects. User acceptance testing should be done, etcetera. So these are just some of the criteria's. I'm just throwing out some examples. In reality, the team discussed together and they create an exhaustive list, and they followed that list, each sprint to make sure that they are adding valuable increment to the product. So let's read the bullet first. Des, definition of done helps to verify the Product Increment is completed and ready for delivery. So when someone says or user stories done, we cross-check everything in the definition of done is finished or not. If yes, the plant increment should be considered completed and ready for release to the end user. If not, let's correct the things that are failing and then recheck again. Second definition of done helps to minimize risk, understand progress and savory work, effort or costs. So if we do not confirm that our product meets the definition of done, it might be incomplete, it might have defects, it might, it might not meet the user's requirement, etcetera. And this will increase risk cost, effort, all of these factors. So definition of del w1 helps to minimize all these things. Next point, definition of done varies across companies and team, but it should be agreed upon by entirely Scrum Team. So there is no fixed list of items that have to be included in the definition of done. It's something that the entire scrum team come together and discuss, including the product owner and the Scrum Master. They discuss all the points that discuss mode should be in there and then they agree to it. This will become the teams guidebook and they will evaluate all future changes against this definition of done. And last, as you can see, some of the items debt can be in the definition of done, like I discussed earlier. But remember, this is a basic list that should be there in my opinion. It is, of course the team's called, they should have a discussion and they should come up with their own list. You can print it out, you can paste it up in the TMJ area so that everybody knows what are the criteria's Dad that team will follow before certifying everything as completed. All right guys, so dat was all about definition of W1. And with this, we have come to the end of this chapter. I am very happy to tell you that we have now covered the three core categories of Scrum, the roles, ceremonies, and artifacts. We will of course continue our learning journey. But at this point we have learned a lot of things related to his scrum. Now in the next chapter we will take up a new topic is sprint planning and estimation very important and learn about it. So I'll see you in the next chapter till then. Thank you. 26. Sprint Planning in full detail and its importance: Hello everyone and welcome to the sixth chapter of the course. We are going to dedicate this chapter to two important concepts is sprint planning and estimation. We have already talked about is sprint planning in the chapter on Scrum ceremonies. But here we are going to expand further on it because as I said earlier, also, a sprint planning is the most important ceremony of Scrum and many important decisions and the entire team's work for the next two weeks, sprint will depend upon it. Similarly, just like any other project management framework, the concept of estimation is also very important but tricky in Scrum. That's why I have clubbed these two topics of sprint planning and estimation into a separate chapter so we can cover the full aspects in all details here. So let's begin. Here is the agenda of this chapter. We will start with why sprint planning is important and then move to estimation. We will talk about is story points, which is the primary estimation method in AGI and planning poker, which is commonly used for this estimation. And finally, we will talk about capacity and velocity, which are two aspects to consider when we are doing is sprint planning and estimation. So let's begin. So the first thing guys, we're going to talk about is why is sprint planning is so important? As we saw in the earlier chapter, is sprint planning meeting where the entire scrum team, including the product owner and the Scrum Master, get together before they start off a sprint and they take up the user is stories from product backlog data team will work on in the upcoming sprint. So obviously sprint planning is the ceremony in which we decide the goal of the entire sprint. We plan the averted the full team would be doing in the coming days and also the Product increment that would be developed based on this. So dat explains parts of it, part of its importance, the importance of the Sprint Planning is dat. It also helps to identify factors like effort and capacity for the entire team. And this is also very important to calculate and record. We will see in the next slide how it is done and what are the core concepts behind it. But for now, just remember that the work plan and estimation are two very key outputs of Sprint Planning and datas wise sprint planning is a very important thing. So point number two, in a sprint planning, we finalize the sprint backlog. That is, what is the verb debtor team would be doing in the upcoming sprint? So the entire team's two weeks or four weeks of work, whatever is the length of our sprints would be decided entirely based on this planning meeting. Next point, the exact requirement acceptance criteria is discussed and agreed on. So as we saw earlier, the requirements are captured in the form of user stories and we have acceptance criteria inside them. And just so we make the right product as expectations, it's important that the entire team understands these acceptance criteria. So in the planning meeting, we discussed these acceptance criteria and if any team member has any query or concern or risk, it is highlighted and resolved in there. Now remember, this might also be something that would be done in the backlog grooming. But nevertheless is sprint planning is the forum in which the requirements are again discussed and agreed on before we can finally take them into the sprint. Fourth, each team member estimates or points the user stories. So it's sprint planning is where estimation also happens. That's why this meeting is again very important. Next point task are allocated to individual team members. So after we have finalized what user stories we would be working on. The next question that comes up is who will do what? So we assign work to team members, we create tasks for them so everybody knows what they are supposed to do. And last point, the team's performance is discussed via Burndown, Velocity chart, etcetera. So we will talk about these reports in later chapter. But for now, just think that how can we make sure that that team is estimating things correctly? How do we know that we are progressing correctly in the sprint? So for that we have charts like burned down and velocity, etcetera. We refer them during the sprint planning to see the team's performance. And that will help us to not overcommit to things and ensured that we take up only that much work debt we can deliver completely. So guys, I hope you are now clear on why sprint planning is an important meeting. And when you are working in an organization, make sure that you remain attentive and focused during the sprint planning meetings, ask any queries that you have. And lastly, do not overcome it more than what you can deliver. All right, let's move forward and discuss another topic estimation in the next lecture. Thank you. 27. Estimation in Scrum: Hello everyone and welcome back. Let's talk about estimation now. So guys, estimation is a general concept. It's not just limited to Scrum. Whenever we are working on creating anything, whether any product or software, we would be asked to provide an estimate. Data estimate is some value or number of how much time or effort it would take to do the thing. So that's what estimate is. Now this concept of estimation is very important and let me sit tricky also, because whenever you are working in a project, people might not remember lot of things, but they will always remember the estimate that you gave them and they will hold you accountable to that. So it is very important to estimate things correctly. Now, just like any other project management framework is, crumb also involves estimation. And when do we do that? Estimation? We do it during the sprint planning. What do we estimate? We estimate user stories. Now remember in some companies they also estimate bugs or defect because they also take time and effort. But it's not a general trend. It depends upon the organization. Most organizations is still only estimate user is stories. Next point, there is a fundamental difference in the way we estimate things in HI Norris Scrum and the way we used to do it elsewhere. So if we talk about the traditional approaches we use to estimate bottom-up, meaning is step one will list out the requirements. Is step two, we think of all the tasks to do is step three, we estimate each of the tasks in hours or days. And then finally, step four, we add them all up to get the overall estimate. So this was the bottom-up approach that was used traditionally. Now in a gel, we follow the top-down approach, meaning we estimate on the entire feature set based on the information available, correct, currently. And then as something new comes up, we can incorporate debt. So the overall idea, remember this very important is to estimate with whatever information available. And then if things change, we can consider that. And this gives us the advantage to react quickly as per changes. So this is what gives it its big point of being adaptable to constant changes. We estimate with whatever information available. And then if things change, we considered that third, each member of the team should give their estimates. So a Sprint Planning is a meeting that all team members attend like we saw and except product owner and the Scrum master, all of them should give their estimate. Product owners do not point user stories, they only give query response is crumb masters also do not point to user stories. They only help run the sprint planning. However, if the Scrum Master is doing a dual role like a developer or test or also then he or she can point if the team is okay with it. But in normal circumstances, product donors and Scrum Masters do not point user stories. The entire development team does it. Next point, if there is a conflict the PIO or scrum master should weigh into explain. So most of the time it happens that one team member will estimate a story as say five points and other would say like OK, it's eight points and don't panic by hearing the Word points. That's what we are going to learn in this chapter. Just think of them as units now. So one person gives the point as 5B and other person gives the point is eight. So there is a conflict. And in cases like this where there is a conflict, the Scrum Master can help the team to reach an agreement. The product owner can also weigh in if he or she feels that 1% pointed higher because they miss understood or over thought requirements. So the general idea is to discuss and then reach a consensus if there is a conflict. And again, we'll touch on these points in detail later. But as you can see, the whole estimation exercise is a consensus-based approach in Scrum. Fifth most common estimation units are storypoints, time, T-shirt sizes, custom units, etcetera. So what do teams point with? What are the units? The most common ones are story points like 135, et cetera, the Fibonacci series. And we will learn in a while what it means and how to decide these points. Now other than these points, that team can also estimate on time value, or they can even estimate on T-shirt sizes like small, medium, large, extra large, etc. Final point, most important estimation methods are planning poker, t-shirt size, dot voting, affinity, grouping, etcetera. So these are just the names of methods that we use to assign points to user stories. Now planning poker is the most common ones, so we will talk about that in detail later. T-shirt sizing like we saw, is about grouping is stories into small, medium, large, extra large, etc. Dot voting gives each team member a limited number of dot stickers and they can vote for individual users stories by putting a sticker next to it. So more the number of dots in a user story bigger is its size. Now this method is used for a small number of stories and when we want to keep things simple, it's not as common. The most common method is planning poker. And the last method 2, affinity grouping. What it does is it asks her team members to group similar stories together into sizing categories. So this method is also used to easily estimate if there are large number of user stories if you want to group things quickly. But as I said, the most common method to estimate is planning poker, and that is what we will see in this chapter. So these are the most common estimation unit skies and these are the most common estimation methods in the industry. And remember, we'll talk about these in much detail in a later chapter. So let's continue our learning and let's talk about his story points in the next lecture. Thank you. 28. Story Points: Hello everyone and welcome back. Let's talk about story points now. So guys, what is a story point? In simple terms, it's a unit of measure that is used by Scrum teams to provide estimate of completing requirements. So that's what is storypoints is just an estimation unit. And let's learn it by an example. So let's say if I come up to you and say I want to create an e-commerce website. How much effort will it take to design the login page? And you will say something like that, okay, it's our medium effort, right? And then I'll ask you, okay, how much effort will it take to design the checkout flow? You will see that, okay, it's a very large effort or a large effort like dad. So that's how we talk, right? And let's now replace the same thing with numbers. And we will call these numbers as its story points. So we will estimate things on something like 13581321. So this is the Fibonacci series and we will use these values for now. So we'll ask you to provide estimates on these numbers only. So if I ask you that, okay. If it's a very small change, like just changing some texts verbiage, you will say that, okay, it's a 1. If it is a little more complex than it's a three-point, if I want to design the login page, then you'll probably say that it's five points or eight points. If I want to design the checkout page, you will see that it's very complex. It's probably 13 points or 21 points. So like debt. So guys, dads, what is storypoint is, you might have thought that it is too complicated, but it's actually as simple as that, a number to indicate the estimation of think, write. And we will learn more about this, how we progress, most importantly, how we give this estimation. But for now, just remember that a story point is nothing but a unit of measure that is used for estimation. Second, age ILL teams use the story points versus time format. So in HI Lori Scrum, the primary unit of estimation is a story points. And the reason we don't use time is because everybody's definition of time is different. If I ask person one how much time it will take to design the checkout flow. He will say that maybe 20 hours. If I asked person B the same question, he will say that it will take 30 hours. So different people have different time unit, and that is because of difference in their knowledge or past experience, etcetera. But if I ask the same person to estimate one user stories relative to another via your story points. Like if example, I asked both of them to tell me how complex the checkout flow is in terms of story points, they will most likely come up with similar values. And that's the logic of why we rely on his story points over time-based values. However, remember that points are also, points are used at the story, User Story level. We still use ours on the task assigned to individual team members so we can decide their available time. But that is not our primary unit of measurement in AJI. If somebody comes to you and ask you what is the team output, you will say that it is x points, not via hours. So you Story Points are the primary unit of estimation in HIV or scrum. Next point we estimate without time commitment and embrace uncertainty. So when we are estimating in time units, we have to make a precise time commitment. But it's storypoints prevent this because there is no mention of time. Also when you are using story points, it allows us to capture uncertainty, which we all know is a practical reality when we are dealing with requirements. So four story points. We use discrete values like 1358 et cetera, which is a Fibonacci series, like I said. And this addresses uncertainty because you will see that as the numbers are becoming bigger, the difference between them is also increasing. So this will help to raise an alarm if the point is huge, like 13 or 21, and this would mean that the requirements are too complex. We have to break them down into smaller stories. Fourth, relative values matter more than raw-value. So very important day story points might not signify much if you look them in isolated with, but if you consider them in a relative manner, then it would provide great clarity. So for example, is story debt is pointed three would be thrice as much as a story pointed one, and it would be half as something pointed five. So just like that, we can understand it in relative terms. Next point is storypoints consider effort plus complexity, uncertainty. So this is a very important concept and lot of times people are asked this in interviews. What does this story point indicates? So the answer is it's story points indicate the complexity of a story along with the effort and any uncertainties. For example, let's say that we want to change the size of the profile picture on Facebook. We want to make them bigger right now they are coming in four by 400 pixel and we want to make it 700 by 700 pixels. So simple, we just want to make this change. So if we ask the developer, he would say that it's a very simple change 1 for me. But if you consider the same from the aspect of tester, he or she would have to verify the same change on different browsers devices. He would have to make sure that it did not break anything like showing the profile picture on group page, et cetera. So that's why complexity could be low, but the effort for the tester is high. So we have to consider all these factors. And this is a very, very simple example on effort and complexity. We will see more on it later. And if we have some unknowns also in the requirement, dash should also reflect in the point. So we will likely take a safe path and we will point at little higher if there is any uncertainty. So these are all the thought processes that go into pointing and we will see how to give point soon. But for now, remember very important, it's asked in interviews also, if somebody asks you, what does this story point indicate on what basis as you give this story points, tell him that it is effort plus complexity plus uncertainty. And last point is Story Points are a little confusing in beginning, but we evolve as a team. When I see new people on their team, they are initially effort to point or they simply repeat the points given by others. And that is because they don't know what others will give. And then they can be questioned on where, why their points are different. So avoid all these doubts do not fall into this trap is storypoints is a little puzzling in the beginning, agreed? But within one or two sprints, you will learn how to evolve as a team, how to point things as a team, and then you would be good. Alright, to help make this journey even more easier for you to help you explain the entire details of his story points. Let's talk about how some tips that can help us to decide on giving the correct story points. So let's see that in the next lecture. Thank you. 29. How to decide story points with common examples: Hello everyone and welcome back. Let's learn about the tips to decide the best story points. But before we move forward, let's recap the three most important information on his story points that we saw earlier. Number one is Story Points are a unit of estimation in a GI. Number two is Story Points are given as numbers, most commonly Fibonacci series 13581321. And number three, story points include complexity, effort, and any uncertainty. Alright, so now that we know what is Story Points are, let's assume that we are sitting in the sprint planning and the first user is story comes up for discussion. And you know that you have to point it soon with everybody else on the team. So what is the thought process that is going on in your mind? What are the different tips and tricks that you can use to make sure that you are pointing effectively and correctly. So let's read about them. The first, read out the acceptance criteria and ask questions for clarity. So make sure that you understand the detailed requirement that is returning the acceptance criteria. You know what the Product Owner accepts, expected to be done and there is no doubt if you have any question, ask the Product Owner, ask the developer or a tester and get rid of any unknowns or any queries that you will have. Next end the most important aspect to do on our part. Think of your work thoroughly. If you are a developer, Think of what all you will have to code. Whether it's a legacy code, whether it's front-end, back-end API, whether it's a complex area, etcetera. If you are a test or think about the high-level scenarios, how we will get the test data. Do you have to test on several browsers? Do you have to test on different devices, et cetera? So think about all this. Think about these things when you are reading the acceptance criteria and this will solve 99.9% of your problems. This will give you a great detail about the complexity and effort that is involved in that story. And you would be able to point according to that. Third, listened to others answers and comments. So like I said earlier, is sprint planning is a very important meeting. So be attentive there, be focused. They are listen to what others are seeing because your doubts or some additional information might be hidden in debt and that will change your thoughts about the story. Next point, learn from past estimates. So estimation is something guys, debt comes a lot from past experience also. So you should keep in mind your learning from the past, whether it is by working on something similar or knowing about the functionality and include that in your estimate. Fifth, make informed estimates but do not inflate for convenience. So one of the things that happens a lot is people tend to point things higher for the sake of convenience, they will just keep everything in the higher bucket, but that is not correct. Try to make your estimate as much as knowledge based as possible. Next point discussed, do not just average out four 0s. So this is a very important point. Let's say that the team is pointing a user story. And person a gives pi, five points, and person B gives 13 points. So there is a conflict. One person is saying that it is 5 or the person is saying it's a 13 pointer. Now what we should not do is say that, okay, you give five. He gave 13. So let's settle for an eight. No, debt is wrong. We need to discuss why person a thinks it's a five, and we need to discuss why Person B thinks it's a 5V, need to hear them both out. And then we need to come to a consensus and why. Because maybe there is some additional information that is with them. Maybe we did not think about something, maybe we did not get the complete details. So there should always be a discussion in case of conflict, each side should give their arguments and then the team should read point. So this is very important, like I said. And as always, the Scrum Master would play an important role in facilitating this. Seventh, if it is too high, is split. So each team learns from their experience, what is the maximum is story point that they can do. Normally if it is 13 or 21 for most teams. But if it is 13 pointer or 21 pointer, it means that it is too big. The requirements are to waft and visually split the user story into smaller components. And the last number eight, do not worry, it will get better with time. So like I said, estimation is something that comes a lot from experience. Do not worry if your points are too different from others in the beginning, just give it a couple of sprints and then you will be good. Also remember that it is okay to have different points because you might have some information that other people did not have. Maybe they did not think about something. So point as it seems OK to you and then give your supporting logic if there is a conflict. All right guys, so this is some of the practical tips that will help you point better. Now let's consider some common examples of each story points so that you help, so that you understand the concept even more better. So guys, as we discussed in the past, normally we use the Fibonacci series for pointing. And as you can see on the screen, we have the cards four values, 13581321, debt that team can use to point. Normally, 21 is a very high value and it would mean that the change is too complex or effort taking. And it should be broken down into smaller stories. Or if there is a lot of unknowns 2, then we should resolve those unknowns first and then take up the history maybe in the next sprint. The memory. In some companies they might also think of 13 S2 high point and split it. It just depends upon the team's past experience, whether they had been able to do 13 pointers in past or not. If they are not comfortable with 13 pointers, if they had not been able to complete it in the past, we can break it down into multiple stories of like 5.8.3 points like that. So let's see what some of the common scenarios that we will fit into each point value. And like always, we will take the example of e-commerce website because that is something that we all have used and we can relate to. So guys on your screen on the right is starting from the lowest point, the one-point. So 1 is a very, very minor work, extremely low or 0 complexity, like suppose on the website we want to change the name of something. We want to make some changes to any text message. We want to change the login name to sign in, or we want to change the order history word to your order. So like debt very small work, very low complexity. Next we have three points. So this is something little more effort and complex than one because remember, as we discussed, is Story Points are relative. So justify, if I just tell you that something is 3, it does not mean anything. It will only signify something if you compare it with one pointer or a pointer and then it would make sense to classify things. So what three is? Three is a little more effort and complexity then one, like if we are creating the Remove option in shopping cart. Click on the product, it is removed from card, the pricing is updated, things like debt or another example is the forgot password email. So the entire forgot password change would be very big. But here we are only talking about sending email. We have broken down the story into small pieces. We are only talking about the email. So sending the email with a link to reset password is most likely a three and debt is just to give you an example, one more thing to consider here is that some teams also used two points. So they use in the Fibonacci series, they also insert point value two. So that is something again that is based on the relativity. It is something that is a little more complex than one, but less complex than three. Next thing we have the fie pointer. So let me tell you guys that 58 are the most common used values and they mean the medium complexity. So fiber is something like searching for a product because there are a lot of combinations in searching. There are external integrations also to deliver the search result, etc. So it's a medium complexity and Soviet telling it's a-fib. Or let's say if you want to create a contact seller form that the user fills up and it sends the information to the seller like debt. So that's also fie pointer because we are creating a form. We are integrating it to the third party vendor. We are sending the email to the appropriate team. So a lot of moving parts. We will say that it's a file pointer. Alright, next is eight pointer. So again, more complex and effort taking then 5p. So like designing the flow to register on the website, We need a form, we need to save the details. We need to make sure that the email is unique. We need to make sure that the password is a strong. We need to send the email to the user. So as you can see, it's a little more work and complexity then what we call 5p. Likewise, if we are adding the item to cart, it is a very important flow in e-commerce. So we need to cater to Add to Cart single-item, multiple item. And actually the more complicated stuff like if the product is not available or if you cannot add or less or more than ten quantity, if you already have the item in card through those sort of things. So there are a lot of scenarios, lot of flows to consider. And we also have to factor in the pricing quantity, all these different systems. So that's why I will call it an eight. Now most of the times when you are integrating something to an external system, meaning something outside the team, it's usually a little higher effort, complex. It's little higher complex, it takes more time. So whenever you are hoping something, whenever there is an external dependency on their team, make sure that you include that also in the picture and you point a little higher. All right. The next one is 13. So like I said, 13s are usually split into smaller user stories if the team is not comfortable because it's a big change like designing the entire checkout flow. And maybe that's even at 21. Note at 13 more, maybe we're integrating a new payment method like we are integrating PayPal or Apple pay debt would be at 13 because you can understand a lot of work to do. There is lot of integrations, coordinations with the external team. There's lot of end-to-end testing that is involved. So that's why I'll point it as it 13. Now remember guys, these are just examples in your companies. Some of them may be pointed differently based on your past experience and how much knowledge you have and you will learn it once you start working. These examples that I gave here are from a layman perspective and only consider the most common case. But if you somewhere, if you go to an interview and they ask you examples, you can quote them. All right guys, so I hope you are clear on his story points now is still if you have any doubts or any scenario from your company or interviewed at, you'll want to hesitate, do not hesitate to use the Q and a option or email me. So this is my email id, guys. And if you have any doubts, like I said, if you have any doubts or any scenario from your company or interview where things were not clear to you you want to discuss, do not hesitate to use the q ND option or you drop me an email on this address. Okay, now that we have learned about his story points, let's talk about the method of pointing things. And it's going to be a very interesting topic. So let's see that in the next lecture. Thank you. 30. Planning Poker: Hello everyone and welcome to the topic of planning poker. So don't worry guys, I'm not going to suddenly start teaching your poker. You are still in the correct course of HL. What planning poker is, it's an age-old estimation and planning technique that is based on team participation and consensus. So remember, as we talked earlier, also planning poker is one of the methods for estimating things, and there are a lot of other methods also, but planning poker is the most common. It's the most consensus-based And I would say it's the most involving method for team estimation. And that is why it is used by majority of the organizations. And the way it works is, and that's what's written in the slide also, but let's talk about it. So let's say that we are in the sprint planning. The product owner opens up the first user is story from the product backlog and he or she talks about it. He tells the team what is the requirement, what is the acceptance criteria, etc. If there is any questions or risk, et cetera here, or the product owner addresses it. And once everything is done, once the team is clear on all the requirements, they do not have any queries, they do not have any unknowns, they do not have any risk. The product owner or a Scrum Master will give each team member a set of cards like this one that we saw in the past lecture. So everybody would be given out cards with the number 13581321 written on it. And I remember guys, the product owner and the Scrum Master, they do not point. So they would not take any card on the the development team would take. And on the count of 1.2.3, the entire team will reveal the card based on their estimate of the user story. So everybody would raise one of these cards reflecting the story points that they think is appropriate. If everybody gets the same points, good enough, that will become the story point. If not, if there is a conflict like, let's say, person one, race the card for five points and person B raise the card for 13 points, then they both have to explain what is the rationale behind choosing that number. And that is why I said in the beginning also this is a consensus-based exercise. We are not going to say that, okay, everybody except one person gave 13, everybody else gave five. So let say that five is the story point. Note that is incorrect. Even if one person gave 13 or even if one person gave a different number from other, then that person has to explain the logic behind choosing that number. Because remember guys, he might know something or he might have thought about something, or he might have, from his past experience, know something that other team members do not. So it is necessary to hear him out. And so we have a discussion around this, why he gave a high points, why the other person thinks it's a low point. And based on what the person says, again, we read point the whole thing and this thing goes on and on again until there is a consensus. If there is some new information that comes out of it, the product owner has to answer that. If there is a risk or unknown that comes out of it, then the product owner has to dissolve it. And only then the team would go ahead and take this user's story and pointed. So that's how it works. And this very point, all the user stories that team has to take in the sprint. So guys, that was all about planning poker. And as I said, it's a very interactive, consensus-based method to estimate thing. And it's the most widely One. One more point to add here, the activity of planning poker dat is giving a story points. It can also be done in the backlog grooming. Once the team goes through user stories in the backlog grooming and all their doubts are cleared, then we can point it. They're only using Story Points and planning poker. However, 1 of note, even though we do it in the backlog grooming, it's still recommended to revisit the story points and discuss things once quickly during a sprint planning because remember something might have changed, some new information would have come up and also the entire team was not present in the backlog grooming like we saw, but they are present in the planning now. So it's a best practice to recap quickly even if we have already pointed things in the backlog grooming. Alright guys, so that was all about planning poker. The slide also says the same things we talked. So if you want, you can pause and read the slide. But anyway, we have already covered all of that. So let's move on and let's talk about the next topic, team capacity in the next lecture. Thank you. 31. Team Capacity: Hello everyone and welcome to this next lecture. So in this one we're going to talk about team capacity and how we do a sprint planning based upon this capacity. So let's first understand what capacity is. Now when the team gets together for the sprint planning. And let's assume that we are discussing things for a two-week sprint. So two weeks mean that there is ten working days and each working days is eight hours. So each person is supposed to contribute a t hours in this sprint. But this might not be true. Somebody might be taking a leave or somebody might have a training, or they can be busy with other commitments. This can happen, right? This is a practical thing and this is what capacity takes into context. What is the availability of the team in hours for this sprint? And based on that, we would do the sprint planning. So let's see the slide now. First thing, Capacity is the availability of team in hours for the sprint. So we already saw this. We are estimating the word debt can be done in this sprint as per the team's available hours. Next point, capacity is calculated by total working hours in a sprint minus personal or professional commitments that are team members might have. Let's say the team members might have leaves meetings in Scrum ceremonies, etcetera. So we have to rule that out and then we have to calculate the total working hours of the team. And in fact, let's look at it for an example. So guys, let say that we have five members on the team, a, B, C, D, E, and there are ten days in the sprint with a total working hours of eight hours every day. So total hours that everybody on the team has is 80. Now let's consider that one day in the sprint is a holiday, so everybody would be off, nobody would be working. So everybody would not have eight hours available for this sprint. Then let's say person a is on leave for one day, so he is not going to be there for another eight hours. Rest, nobody's taking leaf, so we are putting 0. And then let's say that person D has a training for four hours on one day. So for four hours he's not going to be working in the sprint. And lastly, let's put aside some times for the different is crumb ceremonies because remember, we are having a daily standup, We are having backlog grooming. We might have something other meetings, et cetera. So roughly let's leave out six hours of time for the entire sprint for everyone. So that real availability of the team is this much, which is 400 hours minus all these things that are in here. So the total available hours were 400, and then we are going to be occupied for 82 hours, some member or the other. So the available capacity is going to be 400 minus 80 to 318 hours. So 318 hours is the amount of time that we have for this sprint. And anything that we want to do in this sprint, we should only plan for that much amount of work that can be done in these 318 hours. That is what the entire concept of capacity is. And in fact, we are going to be more realistic because we are only planning edge to edge here. So ideally, let's be more realistic and let's only consider a portion of this time. So there is something called as focus factor. That is what is the team is capable to remain focused. And we assumed that any team has a focus factor of only 80%. That means that the team is going to be focused only 80% of the time. So the real capacity that we are going to have is 80% of this 318, that is 258254 hours. So this is our capacity. This is the capacity of the team and this is the time duration for which we should estimate work in this sprint. So now that we know we have 254 hours of capacity, we will start from the highest priority story and then we will start adding tasks to it. So let's go back to the slide and look about it. So we have 254 hours of capacity. We will start from the highest priority story and we will add tasks to it. Like we will add front-end development, back-end development testing, et cetera, all the different tasks that are needed for completing that his story. And for each of these tasks, we will add estimated our satellite for a story number one, that development will take five hours. The backend development will take four hours, testing will take two hours, etcetera, just for an example. So we have total 11 hours debt would be taken up in this particular story. Now the remaining capacity, remember we had a total capacity of 254 hours. So the remaining capacity is 254 minus 11, that is 243 hours. So we had an initial capacity of 250 or four hours. The first story is going to take 11 hours of work. Now we have to 43 hours of work remaining, so you still have capacity. Let's move on to the next story. Let's estimate the task in debt, and let's say that it will take ten hours. So we had to 43 hours after the first story. The story will create ten hours. So now we have 233, our Soviet still have capacity. Let's move on to the next story and that is how it goes. We keep picking a story until we have available capacity. Once the capacity is used up, we stop taking more stories and whatever we have taken until now becomes our sprint backlog on which the team will work on in the upcoming sprint. So that's it guys, that's how capacity based planning is done. And it is considered a very efficient way to do a sprint planning. Because remember, we are being very realistic in calculating everybody's availability to work. Nobody can be there to work a 100 hours. People might take leaves, people might not be available. And we are taking all those factors into consideration. We are comparing their task with the JavaScript is available to figure out how much time is there. And that is why the team capacity planning the team capacity and using that team capacity to do a sprint planning is very efficient, very helpful. Alright, so now that we have seen capacity based planning, let's look at the other variant, velocity based planning in the next lecture. Thank you. 32. Team Velocity: Hello everyone and welcome to this lecture on velocity and velocity based is sprint planning. So let's first talk about what velocity is. Velocity is the amount of work that is finished by team in each sprint dads what it is. So let's actually learn it by an example. So let's say that in a sprint one, we took ten users stories and they're totally story point was 75. It, at the end of this print that team was able to complete eight users stories. And the total story points that they were able to deliver was 60. Sprint to the team took a t story points and they were able to deliver on 55 story points. In a sprint three, the team took 60 story points and they were able to deliver only 40. So our average velocity is the average of these three numbers that the team was able to complete. So roughly around 50 or 51 points, that's our velocity and that's how much work the team should plan to take on in the sprint. So we will, when we gather for the sprint planning, we will start with the User Stories in priority order, and we will keep taking them, we will keep adding their points. And once we reach 15 story points, we will note that this is how much we are able to do. This is how much we have been able to do on average in the past three sprints. We'll stop there. We will not take more than 50 story points. We will pull all the stories up till that 15 story points into our sprint backlog. And that is it. That is how the velocity based sprint planning work as simple as stat. Let's now see what the slide says. All though we have covered a lot of these things. So starting points velocity is the amount of work finished by team in each sprint. That is the definition of velocity that we saw. And it is calculated by adding the story points of all completed user stories in the sprint and taking their average, like we saw in the excel sheet. Third point, we ideally used last three sprints up data to capture the velocity. And this guys is very important. It is done to avoid any temporary fluctuations. So let say that that team was a tender team delivered less in one sprint because the stories that they took were more complex. Or let's say many people were on leave in data Sprint or there was some outage, etcetera. So we want to rule out those temporary fluctuations. And that is why we are going to calculate the velocity. We take the average of at least last three sprints and use that to compute our velocity. Second last point, apart from estimating things correctly and avoiding over commitment, the velocity data is very helpful, especially for project planning. And that is because it gives the product owner and the stake holder a clear idea of how many sprints it will take to deliver the required functionality. So let's say that we have n number of user stories left in the backlog and the team is able to do 15 story points on average. That is our velocity. So that will give us an idea of how much time it will take to complete those any stories in the backlog. And last point, we should always consider velocity data in every sprint planning so that we know that team's past record and we do not overcome it to things. So one of the most common problems that the team faces in reality is the problem of over commitment. And taking a look at that team's past record, the velocity data will help solve this problem. Alright guys, so we talked about velocity and capacity, and we also talked about doing a sprint planning based on them. I wanted to mention once again at this point that is Scrum teams suffer from a very common problem of over commitment, where we pull in a lot of users stories into the sprint. And then at the end of the sprint, many of them remain open. So this is a very common and practical reality. It is called as over commitment and it happens a lot. So that is why it is very important to keep an eye on the velocity and also calculate the capacity when we're doing a sprint planning because if the team is not available, if the team is on leave, then we would not be should not take as much work as we should ideally complete. So that's what I normally do and recommend. What I do is I use the capacity to plan things for the upcoming sprint. And I use the velocity data to get a general idea of how the team still every record is. So both these points are equally important. Both these metrics are equally important and we should consider both of them when we are doing a sprint planning. Okay guys, so with this, we come to the end of this very important chapter and we covered the very important topic of estimation here. So great learning. Let me just repeat it that if you have any query or doubts about any topic in this course, please, please do not hesitate to use the Q and a option or drop me an email. The concepts of estimation are particularly very confusing in the beginning, although as you evolve, you would be good. But if you have any questions, if you are not clear on anything, if you need help with any specific topic from your organization, please do not hesitate to drop me an email, my email ideas right there. And I will always respond to your message within 24 hours. Alright, so let's carry on the momentum of our learning and let's look at a new topic in the next chapter. Thank you. 33. The Scrum Board & Introduction to Scrum Metrics: Hello everyone and welcome to the seventh chapter of the course. So guys, this chapter is about reports or metrics used in Scrum. And if you think about it, every project management framework in the world needs a reporting mechanism to measure the effectiveness and progress of things. And it's Scrum is no exception. There are several options in his Crump to measure the progress and we will learn about them in this chapter. And you will notice one thing unique, and it is that all of them are not about individual performance. Rather it is about Dart team. So that's what is Scrum is like we saw earlier. We succeed or we fail as a team. So let's start and take a look at the contents. Now remember guys, I have included some topics here that you will normally not find in other reports discussion, but they are equally important to measure things and that's why I wanted to talk about them. So we will start with the Scrum board and daily reporting from it. Next, we will learn the Bund down and burn up charts followed by velocity chart and how we can even use the Product Backlog to observe things. So let's begin. So the first topic we are going to look at is the Scrum board. And actually the Scrum board is the face of every Scrum process. If you go to any place that is following is crumb, you will likely notice this physical board and it lists the different users stories that that team is doing and their progress. Or there could be a virtual version of it in the Gita or any other tool that we're using. But nonetheless is Scrum boards and the placement of users stories on them. The first medium to check progress of things. So as the slide also says, is crumbled is a visual snapshot of the sprint backlog. That is, the user is stories that we are doing in this sprint. And it is maintained in a virtual form or physical form. So some of the teams do the is crumbled in a virtual format, while others keep it in a physical version. Both of them are same in the layout. If I show you the virtual version first, this is how it looks. So this is a project for an e-commerce website, and as you can see, there are multiple users stories like this. One here is for the login page, this one here is for the checkout page, et cetera. And for each of these is stories we have created that task like front-end development, testing, UAT, etcetera. And this is just one example. Teams can create task at more granular level also if it is going to separate persons. And also as you can see, there are four column for statuses are to-do, in progress, testing done, etcetera. And again, this is just one way of categorizing. The teams can customize this it based on their discussion and agreements. And that's one of the advantage of tools like this. So in the morning when their teams do their standard before that, everybody should move their task on this boat accordingly. So like development is currently in progress, so it is sitting here, test case design is in progress rate is sitting here, et cetera, that you it is not a started, so it's still sitting in the to-do bucket like debt. And as somebody's work is completed, they will move it to that done bucket. So like when development is completed, they will move it to Dan mentor test case design is complete, they will move it to done. And once all these task are moved to dent debt means all the work is completed and a story can be closed. So this was the virtual boat. And actually we will use this same kind of bored when we will do our life project chapter. So this was just a brief introduction of cultural boats for now. And similarly we have another physical board also. So this is one of the examples of physical boat. And then we have another one right here also. So both of them are similar. And if you look at carefully, it is very similar to the virtual board debt also we saw. And it has the again, the columns for different statuses like to do in progress, test done, etcetera. So we are creating these columns. We are separating them by threats to mark the status of each task. We are having a sticky note for each task can We will move them into different buckets as they are completed. So the whole concept is the same, whether it's the virtual Board or the physical boat. It's just the difference in their setup and how the team reacts to it, how their team uses it. Sorry. So coming back to the slide, some teams like to do things on a physical board because it is always visible. Anybody can stop by and see progress of things. There is a feeling of accomplishment when you are moving their sticky notes, et cetera. And some team, they preferred to do the virtual board because it is more real time. There is no effort needed to create it. It saves the sticky notes, papers, et cetera. So again, depending upon the teams preference, they can choose any version. But the most important takeaway is that the scrum team board is the most common report of the work that the team is doing in a sprint. And that's why I included in this chapter, it's one of the great reporting methods for the team's work. Just by going to the Board, anybody can see what all team is working on, which team member is working on what task? What is the total points that our team has taken? How many of them are closed? How many of them are open? That is, there is any blocker, etc. So all in all the total information of the Sprint is contained in this one single board. Usually the teams do their morning stand up also with this boat open or if they are doing a physical version, they stand close to the board and do the stand-up. And it promotes discussion between the team on each of the item. And the most important thing, one of the good aspects is that when somebody has completed their work, when somebody moves their tasks to the done column, it creates a sense of accomplishment in the entire team. Alright guys, so that was about a Scrum board. Let's look at another report in a next lecture. Thank you. 34. Burn Down Chart: Hello everyone and welcome back. Let's talk about the burndown chart now. So before we do that, let's consider a typical example. In our team, we do two weeks of a sprint and we start the sprint on, let's say every Monday. So Monday to Friday of current week and then Monday to Friday of next week, we will be working on this sprint. And then the third Monday that comes up, that team we'll start with next sprint. That's the flow rate of a two-week sprint. Now let's say that in this current is sprint we took eight users stories with a total of 45 story points. Now the team has to work in such a way that we keep good progress and we keep closing is stories at frequent intervals. Otherwise, what would happen? We would be overburden towards the end. And then there could be user stories, debt do not get closed and roll over. So the chart that shows us this particular information, that is the work that is left to be done versus the time is called as the burndown chart. And this is how it looks like. So we have the User Story Points on the vertical y-axis, and that days or time is on the horizontal x-axis. And if you look at the chart, there are two lines in here. This graven is the ideal line. That means, which means the gradual progression of things and completion like if you're working at a constant ideal rate. And the second line is the actual completion line. So don't worry about how this chart is made. If you use a tune like G, right, would automatically created for you, there would be no manual work needed. Let's try to understand what this chart conveys. So we start with 25 story points. That's our total estimate. And the whole idea is to keep this red line as close as possible to the gray one. If the actual readLine is going above the DRE one, it means that we are going slower than estimated. And if it is below, it means that we are going for faster. So both cases are not okay. We have to remain as close to the gray line as possible. These boxes, gray boxes that you see are for the weekend, so there would be no progress here. That's why this gray line is flat over here. Otherwise, at all, other times, it's going down gradually. So that means that we are closing things gradually. So the whole idea is that the actual work also this red line should be as close as possible to this grey line. And the best way to do it is to close stories at regular intervals, as simple as that. That's all that is needed to get an ideal burndown chart, estimate what you can take as much work as you can deliver, and then close things at gradual interval data set. Now before we go back to the slide and read, other things are quick observation here. You will see that over here this chart has shot up. So why has that happened? That happened because we might have taken in a new user is story in the middle of a sprint, which is not an ideal thing as we discussed, but it happens because there might have been some new urgent business requirement that came up. So that's why the graph short up at that point. All right, let's go back to the slide now and let's continue. So we already saw what a burn down chart is and what are its X axis and Y axis. Third burndown chart helps us to track progress office sprint because we can check it daily and see if we are closing the stories or not and how they sprint is going. So if there are only two days left in the sprint and the actual line is miles apart from the gray line, then it's a problem. Next thing, it keeps the team on schedule. So just by looking at the chart, team can know if they are on track or not. And third, the burn down is very simple to understand. As I said, it's created automatically by Gita or any other tools that you are using. There is no manual effort needed and you can look at it every day and understand whether the team is on right track or not. Last point, burndown charts should be analyzed regularly, especially by the product owner and the Scrum Master to make sure that the teams are on track and the teams are doing progress. And even the entire team can look at it in the stand-up. In one of my projects, we had a physically Scrum board where we did stand up every morning. And the Scrum Master used to put a print out print out of the burndown chart every morning before they stand up so team can see what they are doing and they can make sure that they are progressing at the right track. And also remember that this burn down chart is a very good tool for retrospective meeting. Also, it will tell the team how they progress. Was there any roadblock, why they could not close things at regular interval, et cetera. So simple chart and multiple utilities. All right, let's move on and let's talk about another report in the next lecture. Thank you. 35. Burn Up Chart: Hello everyone and welcome back. Now that we know about the burndown chart, let's talk about something that sound similar, but it is a different thing altogether. The burn up chart. So guys, the burn up chart shows the amount of work that team has already completed and the total amount of work that is required in the project. So it's a measure of the total work needed versus what is completed. And this is how the burn up chart looks like. And here once again, we have the effort or the story points on the vertical y-axis and the time on the horizontal x-axis. But in the chart you will now see three lines. So the yellow one is the ideal line, the red one is the total effort needed to achieve the product development goal, meaning our total required effort. And blue one is the work completed, how much the team has already accomplished. And you can see that this yellow ideal line is going up with time. That means we have to progress towards the end goal with time and in a consistent manner. So each sprint we should reach a little up closer to it. If we are below the ideal line, it means that we are going slow and we are at the risk of completion. So that's what the burn up chart is. Remember in the burndown chart we check that we are burning down things that is, are we closing down is stories where as in the burn up chart, we see that if we are going up, we're going up towards our end goal. That is the way to understand it. Let's go back to the slides and let's check in the other details. So point number one, N2 we already covered. Remember in the burndown chart we have the outstanding work on y-axis, but here in the burn up chart we have completed and total work. And that's why some people consider burn up charts more positive because it talks about the completed work versus burndown, which talks about the outstanding work. Next point, what are the benefits of burden up charts so it shows the total work and the completed work side-by-side. So that's a very good comparison. Next, it shows the how much work is remaining and that we're seeing both things side by side. We can see the progress of things. And last point burn up chart provides more details of project completion. So we obviously have separate lines of total work and completed work like we saw. And so we'll know our project is how it is progressing and if it is on track to completion. Also, let's say that if there is a new addition to the project, you can see this bump right here. So this will show that something new got added and so our scope increased. That is one very good advantage of burn up chart to track the overall project status. Alright guys, so that was the burn up chart and other important is crumb report. Let's learn a new report in the next lecture. Thank you. 36. Velocity Chart: Hello everyone and welcome back. Let's talk about one of the most simple but powerful report in Scrum dot is the velocity chart. So in the last chapter we talked about velocity, and it means how much work we have committed in a particular sprint and how much we have actually committed. So that is the velocity. And when we plot these things side-by-side, we get what is called the velocity chart. So this is the velocity chart, and as I said earlier, it's a very simple report. All we have is two bar graphs side-by-side. And on the y-axis we have our unit of effort like every story points. And on the x axis we have the sprints. And remember, as we talked earlier, also, it's best to look at the data for past three or five is printed to understand the things better. So what we are doing is for each sprint, we are plotting the committed Story Points in gray and the completed is storypoints side-by-side in green. So as you can see for a sprint aid, that team fell short of completing everything that it committed. The commitment graph is somewhere around 35, whereas the completed is around 30. So that means that the team did not complete all the stuff that they had agreed upon. So in a sprint eight, we fell into it in short is print nine and is print ten we got a 100% completion. Sprint 11, We actually did more. So that means that the team took in something extra in the middle of a sprint and they were able to complete data also. So this is a good teams velocity chart guys because as you can see in most of the cases, they achieved what was estimated. And in fact, in one of the cases they are over-delivering. Also. Another thing to note is that here in a sprint 13, that team took a big hit and there is a huge gap between what the committed and delivered. And remember why that happened is up topic for retrospective. But you know, it could be due to several reasons like multiple people had to take sudden leaves or team got held up due to some urgent work that came in or some other blocker came up, et cetera. And it happened in one sprint. All only rest. All is sprints are good. And that is why, if you remember, we said earlier also that when looking at velocity, we should look at the average of at least pass three sprints. So looking at this chart, what is the information that we can get? We can say that for this particular team, around 45 to 55 story points is a good number. Data is the data team should ideally take because they have been able to complete that much working all day sprints. So that's a good number for them when they gathered for Sprint Planning and when they decide to take in their stories one-by-one, they should settle for somewhere close to 45 to 55 points. So that's it. That's a velocity chart, guys and how to use it. And remember, as I said, it's a very simple but very effective chart. Creating it is very simple. We just have to plot the estimator is story and actually completed the story side-by-side. And in fact, if you are using a tool like Gita or any other project management tool these days, they will automatically created for you. You don't have to do any effort. Only thing is that when you are viewing it makes sure that you are using the past three or five IS prints of data to make the analysis. All right guys, let's go back to the slide and let's continue. So let's just talk about the last point because we have already seen the rest once. So velocity chart helps to know what is the team's capability, how much they can ideally deliver. And based on that, we can plan our sprints. We already saw it in the last chapter. Actually not just a sprint, it gives us an idea of the overall project also. So for example, the team roughly does 50 in a sprint and we have 150 points more to do before we can release the product. So we can obviously see that it will take three sprints to finish up all the work. That is the purpose of using the velocity chart, that is the purpose of knowing how much work the team can do. So again, very simple but effective report. All right, so now we have covered the most common is Chrome reports, but there is one more analysis that I wanted to talk about. So let's see that in the next lecture. Thank you. 37. Keeping an eye on the Backlog: Hello everyone and welcome back. So guys, until now we saw several options that help us analyze how the sprints are going, what is the team's progress, etc. We took a look at the burndown chart, the burn up chart, the velocity chart, etc. And these are some of the most commonly used reports in Scrum. But at the same time, the product backlog that we have kept on talking for so long now, that is also something that I wanted to talk about and datas because just looking at this product backlog can give us lot of insight into how things are going. If you remember from our last chapters, the Product Backlog is like our product roadmap. So it's a wish list of what all things we want to do. We have a new requirement, we put it in the Backlog. If we get a new defect that can be done later, we put it in the backlog. So at regular intervals we should analyze if our backlog is not turning into something too big and unmanageable because then we would never be able to finish things, right. We would be doing doing five things in this sprint for a particular release, but there would be like ten more added to the backlog and it will be a never ending process. So that's the general idea of this slide. I wanted to let you know this concept from my personal experience that reports like burndown, burn up velocity. They are very good metrics. But at the same time, simply looking at the backlog can also reveal how things are going on in the team. So let's see what the slide says. First is the backlog too big and unmanageable? So we already talked about it. We should never reached the point where we have to say that, okay, we did three points of work to release the product. Sorry, we did three sprints of work to release the product. But now we need to Maurice prints because there have been a ton of things added to the backlog. We don't want to do that. Our backlog should never become too big. Our backlog should never become unmanageable. Next point is the backlog being reviewed and prioritize frequently. So this here is the answer to all our problems. The product owner should review the backlog frequently. He should prioritize it and you should clean it frequently. So dat is the solution. Third point is everyone just dumping things into backlog. So in some of the teams that I have talked to, What happens is that taken a user story and then any defect or any requirement that comes up, they just move it to the backlog. So I'll advise against this practice. Remember the result of every sprint is a potentially shippable product. So addressing the defect is also important if it's an edge case defect and we don't expect it to happen frequently, then probably we can defer it for later. But simply putting everything blindly into the backlog is not a good idea of doing things. Next point, be transparent about technical debt. So technical debt is a very interesting concepting agent. You can read about it. It simply means the cost of future reworks that will come because the team chosen easy and fast solution now instead of the better and time taking one. So a big backlog is a sign of high technical debt because we are simply postponing things. And remember, at some point it will eat into our effort and cost because we will have to address them. So that is the technical debt. And debt is something that should be kept in mind, especially if you're in a management role. Fifth, RV closing one user story and adding two more to the backlog. So if we are not thinking through requirements clearly what will happen is we'll do one user story, but later we'll find out two more requirements that we've missed. And we'll have to add those requirements to the backlog to do later. So think, think about requirements clearly. Think about it as a team, discuss about it, tried to capture as much requirement as possible in a single shot. This is something that might not be totally avoidable, but we should do our best as much as we can. And finally, are we adding lots of bugs for done work to the backlog. So if each Sprint, our bug count is increasing, then it means that somewhere and we are not doing things with quality. And unfortunately this is a very common occurrence in is crumb because things move so fast. So try to understand requirements clearly. Ask any query you have. The idea is not to create something with like ten defects that will take lot of time for the team to fix. This is something that should be observed, especially by the technical leads and managers. All right guys, so this was some alarm signs to look in the backlog, as I mentioned, we have reports like Burndown Velocity, et cetera. But if you keep an eye on these simple things in the backlog, it will give you lot of information about how things are going. All right, so with this, we come to the end of the chapter. And in fact, we have now covered every topic related to Agile and Scrum that we had planned for in the course content. We now know about HIV, about Scrum, the different roles, ceremonies, artifacts, estimations, metrics, et cetera, everything that is needed to be an AGI and Scrum expert. So corporate congrats guys, you are now a champion in age Island is Scrum. You are fully familiar on all the things about these topics. You can start putting it to use. You can use it to drive improvements in your organizations. You can mention it in your resume or anything that you want. So guys, this course does not end here, although we have covered all the topics now that we have learned every detail in theory, let's put it to use in a practical project and see how things work in the real world. Because remember Andi, when we will do things, we will learn about the real world implementation. So I'll see you in the next chapter and we will start working on an end-to-end project to discuss everything in detail. Thank you. 38. Practical Project - Implementing Agile - Part 1: Hello everyone and welcome. So guys, this is the practical learning project of this course. And in this chapter we will apply all the learning that we have done so far in the course to see how things work in the real world, I suggest that you pay a lot of attention to this chapter because only if you focus on the practical aspects of thing, you will get to know the full details. So let's begin the action. So in this chapter is going to be divided into four parts where we are going to start with how we get the requirements and how we do write them as usage stories. Then we are going to see how the product backlog is created. How do we do the sprint planning and how do we finalize the sprint backlog? Next, we are going to see how the sprint happens, how the work happens when they sprint is running. And finally, we are going to see how the work is released and we move forward. And as you can see, there would be no slides in this chapter, all the learnings are practical. We are going to use this Xcel Energy EDA tool to understand things. Now in this project we are going to simulate the creation of an e-commerce website. And I like to use e-commerce for explanations because it's a very dynamic domain. And all of us could relate to it. We have all used Amazon, eBay, or any other e-commerce website. So it's a good example to consider. And we are going to create an e-commerce website from scratch, and it's going to be called as a child Mega Mart.com, that summer project setting up this e-commerce website. And we will see how to do that. So let's begin. So let's get started with the first part, getting the requirements and converting them to user stories. So how do we get the requirements? Now the requirements may come from different sources. All companies nowadays have a dedicated product management group which are responsible for generating or collecting these requirements. And for our purposes we call them as stakeholders. So we have already seen what is stake holders are. They have the business requirement to be fulfilled, and so each team will get the requirements from them. Now, remember these stake holders first generate or collect high-level requirements, which is like a product vision document. So they might meet with the end client or user to understand these requirements or for our purpose of creating an e-commerce website. They will refer to market needs or competitors to understand which features should be there. And based on this, they will create a high level requirement or vision. And this will be followed by a requirement brainstorming session where, you know, the product management teams get together and they decide which all features or Epics needed to be done from the high level requirements. And finally, must this is finalized. We have the epics, which will be broken down into user stories. And we will write the acceptance criteria for these User Stories which will become our requirements. So that's the whole overall flow. High-level requirements, then Epics, then users stories and acceptance criteria in them. So for the purpose of creating an e-commerce website, let's picture Amazon or eBay in our mind. And let's think about what all features or epics that didn't need. So for example, they need the following. We need an account epic with user stories for registration, login, forgot password, my account page, email registration, password change, etc. And then we need a searcher pixel. In the such a pixel we will have things like creating a search box list page of all products, product refinements, sorting category pages, product pages, etc. Then we might have a checkout page. So it's a very important and critical area of any ecommerce website. And we will have user stories for the shopping cart page, the checkout shipping address page, payment with credit card, PayPal, Apple Pay order confirmation, email, all these things. And last let's have the epic for order processing architecture. So this is going to be the technical stuff we need to create a user database, a product database, ordered database, etc. And I have included this example here to let you know that for doing the business requirements, we need that technical stuff also. So there could be technical requirements also pure technical requirements like creating all these databases. All right, so now we have all these epics and we know what all users stories we need to create for them. Let's start with writing these user stories and their acceptance criteria. And for Dad guys, we will be using this tool. So this is the JIRA tool. You might have heard about it. It's a very nice and powerful tool and it's used by different companies. Debt follow a GI and some of the, most of the big names in the market for product management and HL implementation. And you can try it out yourself. Just go to their website which is at lesbian.com and click on this try now button over here to create a free account is no payment information needed. You don't need to give any credit card, it's totally free. So you can create an account yourself and you can explore all these features for free. So when you create an account in Gita, the first thing that you would need to do is create a project. And I have created mine with the name of the e-commerce website debt. We are creating a gel Mega Mart. You can also create your own project. Just click on this Create Project Button over here. And it will open something like this. So you have to click on the select classic button over here. And once you get to this page, just give a name for the project and make sure to keep the template as it's crumb because we are going to be developing this project using the scrum methodology. And dad sit, once you have filled all these details, you will land back here with your project listed over here. Okay, so now that we have a project, let's go ahead and create our first epics. So let's click on this Create button over here, and let's create our epic. So if I go back to the Excel sheet, we had four epics, account, search, checkout and architecture. So let's create these epics in the g r2. So I'll select the option for epics over here. And I will use to create the first epic. Epic name would be account. And let's give the summary as this is the epic for account works. I already done this, so it's showing auto populated with suggestions, but are, you know, you can give anything in somebody and you can keep the epic named as something specific debt points out which area it is or which team it is, those sort of things. So let's click. So let's create this first Epic. And what we are going to do is click on this, Create another button over here. Because we have to create three more epics. So I'll click on this Create. And as it says, our first Epic is created. Okay, let's create the next one for checkout. Or it was actually searched. So let's created for search, and this is the epic for search works. So let's click on Create. Next we can add the 14x Checkout. So this is the epic for checkout works. And finally, we can click Create the last one for architecture. And dad set, we have created all our four epics. So if you remember from our learnings, and epic is a big requirement from which we cleared the smallest, small user stories. So we decided to adopt for epics for our project account checkout, search and architecture. So we have created those epics. Now the next step that we have to do is to create user stories inside them. So let me click on this option right here, and let me click on this story. So now we are going to create our fastest story. And let's create this story for self registration. So I'm going to name it something like user self registration flow. Alright? And once again, don't worry about all these auto populated things it's happening because I have done it once for practice on this browser. But in your case, you can type it out. You can give it any name that you want. Once again, we want the names to be specific so it points out to what the story's know. Anybody can look at the summary and figure out what this story is. So we are going to go with this summary. And then the next step that we are going to do very important is to list out the acceptance criteria right over here. So if you remember guys, when we were doing the chapter on user stories and acceptance criteria, we mentioned that whenever we are writing acceptance criteria, we always start with the words as a user. And actually the general format is this as a persona. So as a user or as a marketing specialist or as a legal team, whoever is the end customer for which we are designing this chain. So as a persona, I want a goal. So what is the end goal of creating this user history like in this case, the end result is that the user should be able to register. That's our goal. And then finally, so that the benefit parts of what is the benefit of doing this chain. The benefit is that once the user is able to register, he will be able to do the shopping. So this is the general format in which we died, the acceptance criteria. And I'm going to write it in this way. As a user, I want to register on the website so that I can begin shopping. This is our this is our general statement, right? And it has been written in this format. The persona is the user. The goal is to register on the website and the benefit is that he can. He or she can begin shopping. So this is our first line, the summary. Let me just remove this part. And then what we need to do, we need to write that detailed acceptance criteria. So the acceptance criteria, as we saw earlier, is that detailed list of the requirements. And remember whenever we are writing the acceptance criteria, we have to be as detailed as possible. We don't have to leave anything to assumption. We have to mark everything as clearly as possible. We have to cover each and every detail as much as possible, right? We don't have to go a lot into the how part, how it will be implemented, but we certainly need to put everything that is required, the y part. All right, so let's click on this one. We are going to write it in a nice bulleted way. So I am going to say a user lands on the website and clicks on the register button. Next point, registration. And don't worry about the exact content in here. I mean, this is just one way of writing down the things based on the application that you are working on or your company's designing the acceptance criteria has might vary, but the general idea remains the same. We want to provide each and every detail as much as possible. And we want to make sure that everything is captured in here so that people are, do not leave anything to their assumption because you know, what would happen is if tomorrow one of the developer gets this story and he starts working on it, and if there is some point is missing, then he might want to fill in the gaps with with his own understanding of things. And then he might end up designing something that the product owner does not want or the company does not want. So we want to avoid situations like that. And that's why we are going to provide everything in here as much detail as possible. Now, one more thing that, and I am saying this while I'm typing. So one of the things that I particularly stress upon when creating user stories is to have a mockup. So like if you imagine this particular case, we are trying to create a registration page. Now, we can write all the information as much as possible. But if we put an image in here, dire shows the registration page with all these fields, then, you know, it would help to clear out things more easily. Remember, one picture is worth 1000 words. And if we are providing a picture in here, then people would be able to more closely relate to things and they would understand the things with complete details. So we have written the acceptance criteria and it says user lands on the website and clicks on the register button. The registration page should contain these fields. So CVR clearly pointing out what all fields should be there, right? If the email address is already in use, we are clearly saying what is the error message that we want to give? We are not just come off finishing up by writing that show an error message. No, we are even telling what the error message should be because we want it to be clear. We want it to be the way we want exactly right. And then we have given some rules for password like they should be between 815 and contain letter number is spatial corrector like this. And once user provides all the details and clicks on the submit button, they should be taken to my account page. So this is the way to write the acceptance criteria. We have to be as detailed as possible. And this is the browse option from which we can attach a mock-up. It will show that design that is required and it will be of great help. And finally, what we will do if we scroll down, we have to attach this user story to epic. Remember epic is our big requirement and we do several users stories to complete that epic. So for this user story, we have to select an Epic and this user story belongs to the account epics. So we'll create the account epic over here. And I'll click on this Create button. So that's it, guys. Congratulations, we have created our first user is story. And if we go to this user is story, you will see that it lists out everything, clear, clear bullets and indentation. So every anybody that comes in here, he will see things clearly. So that that's how it works. That's the complete flow. And in fact, we have seen that journey from the very beginning. We have seen how requirements are created, how they are sorted into epics, and then how these epics are converted into user stories. So if I go back to our Excel, we have completed the part one-off process, which is getting the requirements and converting to user stories. Right now what I will do is I will create user stories for all these requirements that we saw. I will enter them into the Gita so we can get what we call as a product backlog, a full list of our requirements. So let me create these stories and then I'll see you in the next lecture to carry forward our end-to-end step. Thank you guys. 39. Practical Project - Implementing Agile - Part 2: Hello everyone and welcome back. So now we are going to look at this part, the part two, where we will be creating the backlog. We wouldn't be simulating the actions of backlog grooming and a sprint planning. And we would be ending up with our sprint backlog. That is the work that we have to do in every sprint. So let's go back to the project. So if I click on this project name and go inside it. On your left, you'll see these first four options, which is what we have been talking a lot about in our learning so far. So we have the Scrum board, which at this point would be empty because we haven't fully setup the things and started our sprint. So we'll come back to this later. Then we have the backlog. So this guys is our product backlog. We have talked about it so much. We have kept saying data product backlog is a full list of our requirements. So this is here it is. And I have created the user story for all the requirements that we had in our Excel. And so you can see all these stories are sitting in the Backlog. This is the full list of requirements that we had to do. And you can see all these requirements are tied to the epic also. So like in your company, if Account is one team, then we know that ok, are the accounting has to take care of all these changes. If searches and other team then just by looking here, we can say that okay, search team has to take care of all these things or these belong to the search functionality. So that's the benefit of having epics that we know which area it is coming from and which i specific functionality, those things tied to right? Now let me close this section so that we have more space. And so guys, we have all these 23 usage stories that are sitting in your backlog. We are now good to start with the next step. So this is where we are going to do our first HI is ceremony, the backlog grooming. So let's open this first user story that will create it that we wrote with the acceptance criteria. So the product donor or the Scrum Master will open this user story and the product owner will read out the description and acceptance criteria, what all that he wants to be done in the story. He will show if there is a mockup, which once again, I highly recommend for changes of this sort because it will clarify things. The product owner will explain all these details and it will show them mock-up. Now that team will try to understand these requirements and if they have any question, they will ask it like, what is the length of this firstname field over here? What is the length of this lastName field, et cetera? Because remember, we want to clearly mentioned each detail. So the product owner will answer all debt and he will also add those details to the story. So let's add it over here. So let's say that the firstname should be 30-character. The lastname should be 30-character enlight DAT, right? Because remember the idea is that we want to capture all these things as detailed as possible. We do not want a developer to create the first name with just ten fields because that was the thought process. No, we want it to be exactly as we need. So we'll mention everything here and it is good to document everything because remember, nobody will remember all this later. So better to document it now so that it serves as a reference for later also. So this was the question answer down will go on and people will ask question, the development team will ask question. Product owner will answer it all those things. And once that is done, once every question has been answered, once all the points are cleared, we come to the very important part of estimation. Alright, so let's say that that team is sitting like this and the product owner right here opens the story on this screen, he reads out the acceptance criteria, answers any question that that team has. All this happens now, the entire team data is sitting over here, the development team, except the product owner and the Scrum Master. This entire development team will have cards like this that we saw. So these are simple cards with the number 13581321, the Fibonacci series. So these are nothing but every story point options. And we hand over each of the members of this development team one set of these cards so that they can point a story. And what will happen is at the count of 123, they will all raise one card with their estimation point. So let's say for this is story, everybody raises a fib and ignore my bad drawing skills guides. I am not very good at Photoshop. So everybody in the team raise the card with five. Everybody says that, okay, this is our user story. Story points is five, everybody's agreeing on debt. And so we are good to story and we'll proceed with the next one. So this is the happy path flow where everybody agreed on one common point. Now let's say that there is a conflict. Everybody here pointed out of five, but this guy over here, he pointed that out as an eight. So now what happens? Remember, we cannot say that since the majority of guys are pointing at five, Let's go with five. No, we have to get a consensus. The planning poker exercise is driven by consensus. Everybody has to be heard, everybody has a voice. So the scrum master or product owner will ask this guy debt why he thinks it's an eight. And then he will explain his thought process and might be as something that others did not think of. And so the team will reward based on this new information and maybe everybody will now vote it as an aid because they could not think about something earlier that the sky pointed out. And in that case also there would be a consensus or the product owner and the team will clear out these guys doubts who had pointed out in 08. And based on that new information, he will be okay to accept it as a five. So everybody's pointing it out as a five. We have a consensus. And so in this case, the story point will be finalized as five. So we can come back to the story and we can add a story point as five. So this is story is estimated as a five and this is how guys the estimation will happen. And ideally we should do it during the backlog grooming. Some teams do it during the sprint planning, but that's not ideal. The backlog grooming is the better, sorry, money for this. Now, let me go back to the backlog and you see that if I refreshed it, it will start showing those five points here. So those points are app yet we now know what is the story points for the fastest story. Now let me pause this video and update the story points for some more stories also. Okay guys, so I have dated the story point for the next 60 stories, and this is collectively 42 points. And let's assume that data is our team velocity. We have analyzed the data for the past three spins and we have found that occurs somewhere around 40 to 45 points is the ideal estimation for this team. So we are going to stop here. We have done enough grooming to be prepared for the next sprint. Now if the team wants and if they have time, they can groom the next one or two stories for future. Otherwise, we are. Good to start with the next sprint. We have enough material to start with the next sprint when the time comes. So now that we have a prioritized and estimated backlog, let's fast forward to the sprint planning ceremony. Now the day will come when we'll have to start with the next newsprint. So we will click on this Create Sprint button. And this is a very sprint one. And so what we'll do is we will pull the pointed is stories into it so we just have to drag and drop it. So you guys remember so far you have seen in our journey how much JIRA is helping us do all these tasks. And that is the reason that JNI is one of the most popular tool in the industries nowadays and it is used by all the companies that want to, you know, data using a GI elites, one of the most useful tool for product management, HI EL management development, all those things. And it is very popular in the industry today. So we'll drag these first seven stories into the sprint because this is the work that we are going to take into the sprint. So just bear with me while I do that. Okay, so have moved all these 70 stories and, you know, within the seven also, if we want, we can change their order depending upon the priority. So this product backlog is a prioritized list of requirements. And within the Sprint also, we should keep the stories in the list of the priority because the team will start working from the fastest story. And that should be our priority order. If they dont have sufficient time, deaf day might not be able to complete this one. So let's keep thinking priority order here. So we have pulled a 70 stories into a sprint. Now that team will get into a sprint planning, they will go over the stories again one-by-one. They will quickly recap it and then they will assign tasks. So let's do that. This is our first story that we had created where we had written the acceptance criteria. And also this one is on the top of our sprint backlog. So let's create the subtask inside it. So I'm going to create multiple sub-tasks like let me create one for UI development, right? And then another one for Java development, test case design, test case execution, and finally UAT and etc. So this is just an example. I'm creating it based on my logics. You can create task as per the norms in your organization. But remember, again, the idea is to keep them detailed. Like if one person is going to be doing UI development and other person is going to be doing Java development, then we don't want to create one task for development. We want to separate it out so that everybody knows who he is tasked with, what work and who is doing what. We can track their progress, etc. So this is the way we'll create subtask. And if I go inside this Foster up task, we will assign it to the developer. Whoever member of development team is working on this. And we will also add the estimate of the average to this guy. So remember, Sprint Planning, apart from pulling in the stories also involves two more tasks. First is tasking, so we have to assign the task to whoever is doing it. And the second is we have to estimate their hours for it. So that will help us determine the overall capability. So let's say for this task, this guy's taking five hours, right? So we'll pull, put data in here. And that is his estimate, the time estimate of completing this task. And that's it guys, that tasking and our assignments done. Now once again, let me pause the video and do the same thing for all of the stories. Okay, so now I have completed the tasking for all these stories and we are all set to start our sprint with these 70 stories. Remember when we are taking these stories, we kept an eye on their points and our velocity. So our velocity for the past three sprints was, let's say an average of 45. So we decided to keep our story points still 42. So we have to, we have to be aware of our velocity and not overcome it, not exceed what we have been able to do in the past three sprints. And at the same time, we saw that when we created tasks, we added hours inside them. So based on that, ours, we would be able to compare it against the capacity of that team. And again, make sure that we are not over committing. So these are two aspects we have to consider during a sprint planning like we saw in theory, velocity and capacity. And it would help us avoid over commitment that like it would make sure that we are not taking more than the 70 stories that we would ideally be able to complete. Ok, so we are all done. We are done with the pulling in the story is tasking, putting in hours, et cetera. So let's click on the start is Sprint button and let's start our fastest Sprint. And we are going to keep this two-week sprint guys. There's an option to select as many weeks as you want or there's a Custom option, but we are going to stick with two weeks. And let's start from from it today and then let me click on start. And as you can see, our sprint is created successfully. Gita created it everything and put it on our, on our Scrum board. So this is guys our Scrum boat. And as you can see it lists out all the stories that we had taken in indices print all the 70 stories along with all their task that is assigned to whoever team member would be doing it. So this is every sprint boat, this is our sprint backlog, the work that we'll be doing in this sprint. And based on this, we know that what we would be working on for the next two weeks. Alright guys. So if I go back to our Excel, we have completed this part. We successfully created a backlog. We successfully assimilated the ceremony of backlog grooming and a sprint planning. We saw how we estimate things, how we pull out cards. We created tasks for different stories. We put ours in them, we created our own sprint backlog, and finally we started the sprint. So now we are in a sprint. Let's move to the next chapter and let's simulate that activists Print Period tank. You guys. 40. Practical Project - Implementing Agile - Part 3: Hello everyone and welcome back. So this is our sprint backlog guys that we had created in our last chapter. So this is our work for the next two weeks and everybody moved once they sprint is starts, everybody will start working on the task assigned to them. And also now that we are in the sprint, remember we have to do a daily stand up every morning. So every morning the team will gather for a stand up like this. Now remember they are doing this stand-up with this physical boat. We have a virtual mode. So if we want, we can do it the same way by using a screen with the virtual board openly, like these guys are doing with a physical board. But the idea is the same. Everybody should update their task status before they stand up. So like the UI development for first story as it started. So let's move it into in-progress. That test case creation for the first story has just started. So let's move it into in-progress. So this is the bulk dental team would should ideally do before they stand up and stand up, they will always stand in a circle like this next to the physical board or the virtual mode, whatever. And they are going to answer their status in three questions. First, what did I do yesterday? What will I do today? And any blocker entices the golden standard format guys, these three question, it's going to be a quick 15 minute, minute meeting every day and then everyone goes back to their work and this keeps going on every day. So they sprint, is running, everybody's doing the work assigned to them. They are updating their task. They are attending the stand-up and so on. Now let's consider dot for this is truly the UI development is closed, so we will move this to done. The test case design is also closed while move it to done. Once the development has happened. Let's move this guy also. So once the development has happened at testing will start, the testing will also complete. Then once the testing has completed, the UAT will also start and complete. So now everything inside this is stories completed. So now we'll, JIRA will say that, okay, you have completed all the task inside it. You want to update the story. So let me click on update. And as you can see, this story will move from in-progress to close. So we have completed our first work in the Sprint. We have completed our first deliverable, our fastest story. And likewise, the team would also be working in parallel on all these things. And they would be updating their task. They would be delivering that status in the stand-up and they would be closing on things. And remember, the same thing would be done to the defects also, the defects would also be assigned to individual team members. They would be working on those defects, moving them into different disease status columns that we are seeing and they would be closing it. So that's how they sprint. We'll work, that's how the sprint we'll progress. And other thing that you should note is that while we are in this sprint one, we also have to do the backlog grooming for Sprint two. So two or three days before the sprint one is supposed to end, we will do the backlog grooming for the next sprint. So the entire sequence of events that we have seen until now, we'll repeat, we will review the product backlog. We will prioritize these stories. We will review the stories. Then we're pulled them into the sprint 1 third next sprint planning comes and all those sources of this, like I said, a Sprint is a scrum isn't iteration of task. So we keep on repeating this iterative cycles again and again, and we keep on delivering new increments to the user. Now remember if you click on this thing and you will see an option here for reports. So if you click on this reports, you will see that different metrics or reports that we talked about. So you have the burndown chart. You have the burn up chart. I sprint report the velocity report everything bread we saw. And these charts will not populate properly for me because remember, I just created the sprint few minutes back and I am coming to view it today so it will not populate for me. As you can see, there is the ideal line is there, but there is no completion line because we just started the sprint few minutes back. But you can try it on your own. You can try to create a sprint clear first, create some history, Epics, then creates some stories with acceptance criteria. Then create a sprint from it. And then you can close some of these stories each day and you can see this chart moving anyhow, the idea here was not to show these reports. We have already seen it. What I wanted to show you was that JIRA is providing you the option to view these reports and JIRA is creating these reports automatically for you. You don't have to put in any manual effort to create these reports. And once again, this is another advantage why we use JIRA so much for Agile and Scrum projects, right guys, so this is the primary flow of things and we have covered the bulk of the things and I explained everything in a nice and easy way and I hope that you are clear on everything. So if you see the excel, we have covered the three parts. We got the initial requirements. We created epics for them, we created user stories, added acceptance criteria. Then we did the backlog grooming, we prioritize the stories, reviewed them, estimated them, we pulled them into the sprint task, them, putting our sort them, we created a Spring, we knew whatever the sprint backlog is, the work that we have to do for the next two weeks. Then we did our work in the sprint, we did the daily standup. We moved a task on the board, we closed the stories, we close defects, we saw the burndown chart, all the so this was the primary flow of things. This was a lot of things that we have seen. A I hope that you are clear on everything. If not, you can ask me the questions if you have any. So this part is also done. Now, let's see the last part in the last lecture. Thank you guys. 41. Practical Project - Implementing Agile - Part 4: Hello everyone. So we covered a lot of aspects related to the end-to-end project in the past chapters. Now, let's see if some few last things in this lecture. Let's check out this nice calendar that we have here. So as you know, we started our two-week sprint right here. We did the sprint planning. We got our work for the next two weeks and we did clear cut tasking of who will do what everything was clear on the board, nobody could change it. I have read the work was visible to everybody. We know who is doing what, whether they are in progress, whether they are blogged, etc. So things are pretty much sorted on their own. The work is progressing. We are doing our daily standups, et cetera, et cetera. And then if you notice here, everything is going smoothly. And then right over here a few days before the sprint ends and we have to start the next sprint. We are doing the backlog grooming or the backlog refinement. Now we can do it here, we can do it here. There is no hard and fast rule, but we want to keep it a few days before start off next sprint. Because remember, if something comes up in this backlog grooming like a unknown or risk, we have sufficient time to resolve it before the next sprint starts. And also remember these are the last few days of our running a sprint. So people might have work compiled append devolved to complete it before the end of this spin. We don't want to take up a lot of people's time in the last two or three days. So normally I would prefer to do the backlog grooming on this Wednesday or maximum Thursday. So we will do it over here and then we will be all set for the next sprint. And then as you will see on this Tuesday when the current is sprint ends, we are doing the sprint review or demo. We are, we are showing our work to all stakeholders. And also we are doing the retrospective where the entire team would gather together for analyzing how this entire is print works, whether they have any suggestions or feedback, etc. And guys, if you notice, this is the beauty of the whole process. We are doing this demo and retrospective immediately at the end of the sprint. So once we demo the product to the stakeholders, we are getting there quick and early feedback. And once we are doing the retrospective, we are getting the lessons learned from this current is sprint that we can implement in the next sprint that is going to start the next day. So these two ceremonies are also done, and now next day we'll start with a sprint planning for the next sprint, sprint two, we will already have the product backlog that we finalized here in that grooming. And similar to what we saw, we will take up the stories as per our velocity and capacity. We will task them, we will put hours, et cetera, and this iterative process will go on and on. And one last thing, this calendar does not mention it, but somewhere we will have a release also of the product of the increments that we have designed so that the end user can use it. And there is no fixed rule to setting the release date. It is finalized in the release planning meeting, and it can be done like here or here. There is no fixed date to eight. It depends upon the product roadmap, the customer demand, cost, effort, etc. We saw all these topics and the release planning chapter. So guys, this was the entire practical aspect of Agile and Scrum. We have implemented a project from scratch. We have created the user stories is sprints, task, et cetera. We have done the different ceremonies or Backlog Refinement, backlog grooming, Sprint Planning, retro demoed, stand up, all these things. So I hope that you understood everything clearly and you will now be super confident of everything that we learned. So this last part is also complete it. But as you see, we have covered a lot of things in this chapter. So if you have any questions, if you are not clear on anything, please do not hesitate to use the Q and a option or you can drop me an email over here. This is my email address and like I mentioned in the past, also, I proactively reply to all emails within 24 to 48 hours. So send me whatever questions you have and I will try my best to answer them. Now before we move ahead to the next topics, one more asked from my side, guys, please leave a review of the course. It will hardly take two minutes of your time, but you're rating will motivate us further to create great content like this for you. Alright, so let's move on. We have completed all our learnings in Scrum. We have covered the theory parts, we have covered the practical parts. Now let's take a look at the certification aspect in the next chapter. Thank you. 42. Certification Exams with Tips to crack them: Hello everyone and welcome to the nine chapter of this course. So now that we have seen all the aspects of Scrum in theory and practical, let's talk about how to use this knowledge and get a certification. I understand that a lot of people taking this course would be interested in getting a certification also. So let's take a look at that journey. Let's first talk about what other certifications, how to enroll for it, and how to give the exam. And then I'll share some tips that will help you clear it. So there are two certifications that are most popular in Scrum. The first one is the certified scrum master or CSM. And the other one is 35 to Scrum product donor or CSP o. If you are a starter in Scrum or you are just looking to get a certification for your knowledge of his crumb, then I'll suggest you go for the CSM one. And if you're already in the business line like a business analyst may be, you can take up the product owner course. So depends upon your line of work, your future plans, et cetera. But I will suggest that you start with the CSM. So in this lecture we'll talk about the CSM course. You can read more about CSP also, the process is not much different. So let's go to their website, which is on the screen and see details. Remember if you are doing this course later, the things that I talk here might change a little bit. And that's why I'm pointing to you to the website also because that will always remain up-to-date. So this is the certification page. And if you scroll down, you can see the various learning journeys here in the Scrum master track. We have the certified Scrum Master Advanced Certified is Scrum master certified scrum professionally Scrum Master, like likewise in product do not track. We also have couple of courses and in the developer track also we have some courses. I don't recommended courses into developer track. If you are a developer and if you want to learn is crumb for your own personal or professional learning, then just go for the CSM course that is the best if you are a product, if you are intruder business line like a business analyst and you want to become a product owner, you can probably off for this course certified Scrum product owner. But for most people, the certified scrum master courts would be the best one. So let's click on this certified scrum master link and it will open something like this. So on this page you can see all the details and if you scroll down, you can see the requirements for giving the exam. There is one prerequisite for giving these CSM exams and datas that you have to attend an online or in-person course before you can give the exam. That is like a workshop and it is mandatory and don't worry, there is no extra fees for it. It is already part of the exam fees and it will help you also because it will be sort of a revision for you what you have learned in this course already. Now, once you are done with this workshop, you can give the exam and there would be like 50 questions and you have to get at least 37, correct. And the time limit is 60 minutes. And trust me guys, this is a too relaxed rule. The CSM exam is very, very simple. And if you have followed this course thoroughly, if you will revise the things in the workshop, you will clear it very easily, just be prepared. It is very simple. Now if you scroll down and if you click on this finder Course button, it will take you to the workshop details page based on your country. And you can see the locations, dates, trainers, et cetera, based on your location. So I recommend that you can do some lookup on line four based on the course details, timings, trainers, etcetera, whatever suits you, you can read about the location also. So in my case, everything if you see its showing online only because we are in the COBIT time, so things are closed. But once things are normal, iv and workshops open for in-person interaction. I will suggest that you go for a in-person class only it is more interactive and it will help you more better. So you can click on the Register link for any of the course that suits you. And it will open a page like this with the more finer details. And once you click on this box, it will give you the details to make the payment. So just right here and after you make the payment, you will get a welcome email. You can do the workshop, you can, once you complete the workshop, you will get another email that will contain the details to give the examination as simple as that. Remember, the only prerequisite is that you have to attend this workshop before you can give the exam. And I think it's a very good thing also, you get two, interact with other professional software field. You get to revise things quickly and then you can give the exam based on that current knowledge. And actually all this and more information is presenting their FAQ page also. So if you go to the homepage, scroll all the way down and click on this FAQ. It will open something like this. And now you have to click on this Certification Questions box right here. And you will get the complete details about a certified scrum master and CSP exam. The most frequently asked questions, I navigated their entire website to get you the best information. And I found this FAQ page to be a very nice one. So if you click on this first, how do I become a certified scrum master? It will take you to a page like this. And in the first two questions here you can find pretty much all of the information that you would want to know. Want to know. I have already told you about it, but it's still if you want to read it, these 2 first questions will have all the information. Also you can click on this. What can I, can I expect from the CSM test question and read the details about the exam. So as I said, it's a 60 minute exam with 50 multiple choice questions and you have to answer at least 74% correct. And it's an online test. You can give it from anywhere that you want. So that's it. That's all the details that you will need to know about the CSM exam. And most importantly, remember, as I said, it's a very simple exam. You will be able to clear it very easily with the learnings from this course and a revision that you'll get in the workshop. Alright, so now that we know about the exam, let's go back and let see some trips, tips to crack this exam. So the first one is read the Scrum Guide before taking the exam. So if you go to the website, let's do that again. So I went to their website, which is a scrum Alliance.org, and I click over on this resources and click on this e-books. And disguise. Right here is the Scrum Guide. So you can click on it and you can download the PDF. It's only 19 pages and you can take a print out of it and keep a copy during the exam. This is the download link to get it. Next point, take some mock test before the exam so you can find out lot of mock test online, just Google for it and go through a couple of them. It will help you to practice. It will tell you MOOC some common questions also that you can prepare. Third, when you're appearing for the exam, One of the common issues that all answers might sound similar. So make sure that you read all the answers carefully and then you select an option that quizzes that you took in the course. We are on the similar lines to give you an idea of how the exam was. So that will help you to some extent. But remember, always make sure that you are reading all the answers carefully and ten, selecting an option. Next point you can, you can use the elimination rules, so eliminate the wrong answer first. This will help you to rule out some options and then identify the correct answer. Fifth, be patient is stick to the facts knowledge. So as I said, the exam is very simple. We have already learned a lot of things for it in the course, and you will have a refresher in the workshop also. So be patient, be confident and stick to what you have learned. 6, review the questions before where you have a doubt so you can hold the answers where you have a doubt and come back to them later. This will help you save time. And finally, before submitting the exam, make sure that you have answered all questions. So recheck quickly that all questions are marked as answered before you finish the things. So that's it, guys. Those were some of the tricks to help with the CSM certification exam. And let me repeat it for the one last time. If you do this course thoroughly, if you revise the things in the workshop and appear for the exam confidently, it's very, very simple and you will be able to clear it very easily all the very best. All right, so with this, we come to the end of the chapter. Let's move to the next one and learn about interview questions. Thank you. 43. Interview Tips: Hello everyone and welcome to the last chapter of this course. Let's talk about some quick tips that will help you clear any interview, whether it is for an HIV related role or in general any profile. I have included this section in the course because I believe the objective of us in learning something new is to improve our carrier profile and at some point or the other translated into a better job. So that's where this section will be useful for you. And on the same lines, I have included around 13 interview questions in the chapters resources section. You can read them before any interview and quickly revise things. So let's begin. So guys, let say that we applied to a job and now we have to go for an interview. So how can we prepare for dat? Let see some golden rules. First and foremost, be well-groomed and prepared. So dress-up professionally, if there is a dress code required followed at LC, You can dress-up in anything that is professional and then go to the interview fully prepared to not just show up for the sake of it. Second, do some research on the company, the job profile, etcetera. It is good to know where you are going. The interviewer might also ask if you know about the company, so do your homework. Third, behave, prepare the behavioral questions. So the first question that they ask in any interview is always Tell me about yourself or walk me through your profile. So prepare a good answer to that. Something that tells about who you are, your educational details, your work experience, your technical skills, any notable project awards, recognitions, etc. In my initial days, I used to have a written answer for this so that I can be prepared. You can also do that. But if you do that, just make sure that you do not sound up like you have mucked up the answer, say things in your regular tone. And then apart from this, there are other behavioral questions also like, what is your expectation? Are you a team player? All those kind of things. So you can find the complete list on the internet. The idea is that prepare for these behavioral questions also, and not just the technical ones. Fourth, be ready to talk about each process in your company. So when I am taking interviews, I ask people to explain the agile process and complete journey in their company. So prepare something on the same lines. How do you get the requirements? How do you do the ceremonies, how you estimate his story points, how you manage the HL board, all of these things. Next and very important answer clearly, so answered in a direct and accurate way, you can use examples to supplement your answer. It is always helpful to follow up with the examples. You can give examples of anything similar that you did in n, in your current company or elsewhere. 6 do not you do not fight. Be open-minded, listened to the interviewer and keep things polite. Next point and again, very important. If you do not know the answer, say that honestly, there is nobody in the world who knows everything, So remain honest and pass on the question. Do not try to bluff the interviewer. You will get caught for sure and it would not be good. Second last point in any interview, the interviewer will ask you at the end if you have any questions. So use that opportunity to ask anything about the job profile, the company, et cetera, that you want to know that will also show your interest in the job. You can ask the interviewer for his or her general feedback about you if they can provide any, but do not discuss about the salary aspects there that will come at a later stage. And finally the last point b, confidence. So be prepared, be optimistic, answer everything confidently and hopefully the result will be good. So guys, these were some important interview tips. Now you will also find a list of 13 interview questions attached to this chapter, which I have carefully created to cover different aspects of AGI and Scrum. Be sure to go through them, revise them before any interview. And dad, combined with the learnings of this course, the tips here should help you sail through any interview. I wish you all the best guys with this, we come to the end of this course. It's really exciting to think about everything that we have learnt in this journey. We started with the shortcomings of traditional approach and why a child came into picture. We talked about the core concepts and definitions of Agile and Scrum. We saw the Scrum roles is crumb ceremonies, is Scrum Artifacts, planning and estimation reports, certification, interview, lot of things. And we also did a project with practical implementation so that you get a hands-on understanding of how things work in the real world. So it was indeed a great journey. And I hope that this course helped in your objective of learning about Agile and Scrum. Once again, I would like to reiterate two points that I mentioned also in the beginning of the chapter. First, HL is not just a methodology most important, it's a mindset. We have to be a giant in our thoughts, our work, our collaboration with their team. Only then we can successfully implement a gel or a Scrum. So keep that HIS mindset always width you. Second, HI Lori. Scrum is not a magic stick that will solve all your problems. It will show us what the problems are or what the problems have been with the industry. And it is up to us to carry the HL mindset, work together as a team and deliver exceptional products. So the end user. All right, so we are at the end of the course, but remember by enrolling in this course, you are entitled to lifetime query support facility. So if you ever have any questions, feedback, if you want to talk about something in your organization, how it worked, and if you have any confusion, do not hesitate to drop me an email, my email IDs on the screen, and I promptly reply to aliments in 24 to 48 hours. Now before I end, one final asked from my site, please do spare a few moments to review this course and give us a rating. Your feedback is very important for us and it helps us create exceptional content for our learners. So once again, guys, thank you so much for choosing this course and I wish you all the best in your learning journey. Thank you.