Day 3 Scrum Overview

 

First, we'll discuss these questions, and then the affirmation part. I wanted to talk with so I have already talked. Now, first, we'll discuss this question, and then these are the assignments for the next week. Let me copy and paste from here; let me put it here because I'll be adding more questions here. Question number four: What is the difference between Scrum and Agile? I'll be adding more questions throughout that class.

Now, one by one, I'll take random names, and everyone's turn will come. You guys have to explain these answers how you're going to answer in a real interview. First question, I'm taking any random name: What is SDLC? What are the different stages of SDLC? What is Waterfall? What is Agile? What are the three differences between Waterfall and Agile? Any random name will come. Sonam, what kind of project you use in Waterfall and what kind of project you use in Agile? Nihal, can you explain Agile to a five-year-old kid? Already discussed. What do you mean by horizontal slicing and vertical slicing? Is Imad there in the class? Or let me give a chance to Imad. Clear? If you guys will not be able to answer, I will open the forum first, but make sure you're answering how exactly you're going to answer in the interview. First question: What is MVP, MMP, and MBI? Can you give one example, Ranjit?

________________________________

MVP, MMP, and MBI Discussion & Clarifications

Ranjit said: MVP is Minimum Viable Product. It is the sole features of the product that makes the product to go into the people actually, so you need to require to launch a product. Those features are the sole features, and these are called the minimum viable product. For example, if we look into the early '90s, the car manufacturing's main agenda was to transport one from place A to place B. That's how they come up with an idea to make a car.

Next is Minimum Marketable Product. One second. MVP, what is one example of the car example you have given? What will be the example? The example of the car is the features that need to be there in the car are four tires, a gear, a moving engine. That's the minimum requirement for a car actually.

Let's take the example of a cycle. A cycle is a whole product. Yes, will a wheel be an MVP or not? Yes or no? No, it won't be an MVP because it requires a cabin as well to sit inside, and then on the four wheels, there has to be an engine. I'm talking about the cycle because it is manually driven, and the car is for the engine purpose. My question is: for example, a cycle is one product. Let's forget the car for some time. Cycle is one product, and one of the components in a cycle is a wheel. Correct, a two-wheeler? Yes, so for example, one wheel you prepared. Is that an MVP of a cycle or not? Yes or no? No, it's not a complete product; it's one of the features of the car, so it cannot be a complete product. So that will be MVP or not? No, it won't be MVP. For example, in the case of WhatsApp, whatever we learned, complete features are a lot of features: sending, receiving messages, audio calling, video calling, and multiple features. What problem you are solving? The initial problem with the cycle was already there. So, the initial problem that address was: you require a vehicle that can transport you without putting any manual effort. So, for that purpose, that is the main basic product that you are making. So, Minimum Viable Product can have multiple features; it's not just... If the wheel is not the MVP, then what will be the MVP in the case of a cycle? In a cycle, a set of wheels could be an MVP with a seat and a handlebar so that a person can drive.

What are the two basic purposes of MVP? The purpose is to solve a problem that is initially discussed between the team and the stakeholders. MMP is the Minimum Marketable Product. Initially, when the minimum viable product is made, you need to market it to the people so that it can be available in the market. As we came across, the minimum additional features that are required to sit in the car were, suppose, a radio or air conditioning or the styling of the car. That would be an MMP, a marketable product, because just a car with four wheels and an engine is solving a problem, but it's not a marketable product in the market. So, you need to have some features that could entertain the audience in order to be available in the market. MBI is Minimum Business Increment. Suppose now we take the same example: in the late 20th century or in the current situation as well, the car can be more advanced with features like GPS, safety features, or maximum fuel efficiency. These are the increments that have been happening within a longer period of time since the late 20th century. So, MBI is the increment. So, increment includes GPS features or fuel efficiency or safety features that are available in there.

________________________________

Corrections on MVP Purpose & Examples

Can you clap for Ranjit, guys? Everyone, very good answer, Ranjit. Very good. Now, a few corrections, Ranjit. The purpose of MVP is to validate the product—whether it is going to work or not. Let me come again. The purpose of MVP, Minimum Viable Product, is to validate the product, validation. Okay? For you, you come up with the basic version, first prototype, and you validate. Like, you'll have the beta test given to beta testers, and they will be testing what about the minimum basic feature you have developed—whether it is working or not working. Once we release it to the market after adding more features, like making the MMP, whatever the issue is going to come, you detect at the MVP stage only, correct? Yes, absolutely. So, those things—the purpose I asked you: What are the two purposes of MVP? Validate the product, and second, to gauge whether this product is going to work in the market or not. Okay, you got it.

And the best thing, what I asked the question, I tried to confuse Ranjit: that in the case of a cycle, can the wheel be the MVP or not? No. See, the cycle's purpose is to move from place A to place B. So, only the wheel—people can't move from one place to another place. So, Ranjit answered very correctly that the MVP for a cycle can be a basic cycle—you don't give the seat, you don't give all the luxury—just a basic cycle, wheel, and handlebar, and a person can sit and you can go. The basic purpose should get fulfilled. We get the example of WhatsApp: basic purpose of sending/receiving messages. Why are you telling MVP is sending or receiving messages and registration? Because we are able to fulfill the basic things of a WhatsApp, whatever the WhatsApp kind of came up with, correct? Absolutely. So, it's not like any small component you made and you're telling, "Hey, no." The basic thing should get fulfilled. Basic thing in the case of a cycle or a car is moving from place A to place B; that should get fulfilled. What Ranjit answered was correct. Clear? Thank you.

Over. But with MVP, we will not be able to market. Over MVP, we add minimum one or two features to make it marketable, what Ranjit explained. And again, after MMP, to sustain in the market, to make sure you are running with the curve, you are going the same path as the customer is getting changed, you keep adding minimum features. For example, one time safety feature, airbag, you give. Another time you came up with some other feature. Again, another time you came up with some other feature. All features, one by one, will be called as MBI. Yes or no? Clear, everyone? Yes.

Ashutosh, you're raising your hand. Two things you just told about MVP: one was the purpose of MVP is to validate the product—where this will work or not—and what was the second one? To gauge if the product is going to work in the market or not. To gauge if the product is going to work, but like they will launch or not. A lot of companies, what happens, they kind of roll back the product even at the MVP stage because they thought this will work, but when they prepare the MVP, they're like, "Hey, it will not work." So, they kind of roll back; they don't even launch the product.

So, basically, what's the difference between the validation and the gauging? It's almost the same, right? Like validation means... you can see almost the same. Something kind of... for example, if any problem is coming, for example, you made two basic features, any issue is coming, for example, the design is not good while testing when the beta testers are using it, correct? So, those, you know, like defects are coming, some issues are coming. So, you will... whatever the issues are coming, that will again go to the IT team, engineering team, and they will be fixing this. So, what you're doing during the validation? Validation means what? With this feature, is it working or not? Some issues are coming. Those issues will be fixed at the MVP stage before releasing it to the market, kind of re-engineering. Re-engineering kind of, like whatever... like everything should work before going to the market. Ranjit, can I rephrase this in a better way if you allow me? Yes, please. Sure. Thanks, Ranjit. So, product validation is the validation of the features that you are already developing. So, whether the seats are working, whether the wheels are round—these are the product validations. And all these combined together, whether this product will work in the market—that is the second point. That is one, am I correct if I'm correct? Sometimes the product is good, but we feel like it's not going to work in the market, correct? So, that gauging is the second point that you mentioned. Hike was a good product, miserably failed in the market, Hike Messenger. This is a business call. They think from a lot of perspectives: return on investment. They do a lot of interviews of their potential customer. They do a lot of analysis. They see the market: "Is this really an issue for us to solve in the market, a market gap, or someone is already solving it? Do you have that percentage of market share to solve it?" Correct? All those they analyze, and then they take the decision. That is a business call. Got it, Ashutosh? Yes.

Any doubt in question number one? We good, everyone? Okay.

________________________________

SDLC Stages and Waterfall/Agile Comparison

Second, what is SDLC? What are the different stages of SDLC? Can you explain with an example, Jeeva? Jeeva said: SDLC stands for Software Development Life Cycle. It is basically a software development efficiency and meeting the user requirement, and it's having seven layers, we can say seven steps. For example, if we are launching any application, we need to complete all seven steps: firstly, plan, requirements, design, development, testing, deployment, and maintenance. For example, for planning, it means we are just considering the scope and objective as a planning. And the requirement, it means all kind of documentation. Designing, it means architecture and building the UI, database. Development, it means we are writing the coding and building an application. And the testing: whatever written coding, we are testing and finding the bugs and trying to fix it out. And the deployment means we are just launching that application within the real-time users. And the maintenance: whatever issue comes up or updating the new things inside the existing application, this is all the kind of steps we are just following under the SDLC.

Can you clap for Jeeva, guys? Fast, keep clapping for your teammates, Jeeva. Now, the correction. See, you know the answer. What is happening? You know, whenever you guys are explaining, please, like how Ranjit took the example of a car, you could have also... see, people understand in layman's terms. You could have taken the example of WhatsApp, Amazon, as a product, anything for example, and you could have explained the same thing in a much better way because once you explain with an example, it looks genuine and practical.

Going forward, after 10 to 15 classes, I'll be teaching you 2D to 3D—how to answer the interview question so that you look like a practical Scrum Master, and all this, I'll be teaching you. But so far, what we know is that we need to use an example. For example, I'll guide you. What is SDLC? Yesterday I told three terms: Software Development Life Cycle is a process of developing software from a start to end, making sure what exactly three words I used: highest quality, lowest cost, in the shortest time possible. That was missing. Second, under SDLC, we can have multiple models: Waterfall and Agile. We need to include Spiral and V-model. That also needs to be included in the answer because then your answer will look like, "Hey, we have content in the answer."

Now, what are the different stages of SDLC? Your answer was... like you mentioned plan, requirement, design, development, testing, maintenance. But here you could have taken the example of WhatsApp. That, "Hey, first we'll gather the first idea. Somewhere down the line, 15 or 20 years back, someone would have thought, 'Hey, can you have some app where people sitting across the globe communicate?'" That was a problem to solve. They came up with the idea. They went to multiple users; they got to know this problem needs a solution; we need to solve the problem. Then the requirement: what is the requirement? IT team or engineering team would reach out to the stakeholder, the business, to get the requirement. What is the example of a requirement? Sending/receiving messages, registration, third, audio calling, video calling. Then design: we'll be designing architecture design, UI design, in such a way that even millions and billions of users are coming, we have a strong database, there is no lag in the software, not crashing, all those needs to be kept. And even UI design is good. Development: all those features whatever you discussed the requirement, developers will start coding it using multiple front-end, back-end, and all this. Then testers will start testing it. Like if any bug... you mentioned already. And then deployment: deployment means releasing it to the actual user to start using it. And then if any problem, they're coming up with maintenance in it. There will be a team called Production Support Team. If any issue comes, those production support teams will be resolving those issues. Now, see, first time you're doing it, great answer. But whatever I suggested, that correction is to happen. Everyone got it? Yes. The answer should have substance. Clear? Okay.

________________________________

Waterfall Model

Great. What is Waterfall? Lizzy, so Waterfall model is the earliest SDLC that was used for software development, and I think in this model, it is an example for a sequential model. So, it is also referred to as a linear sequential life cycle model. But there are a few ups and downs; there are more cons than pros in this model, where it is not flexible, it is less flexible, and it is rigid and resistant to change. And due to the sequential nature, Waterfall may limit feedback until later stages of the development. And Waterfall is used for long-term projects, for example, for large and complex projects which have concrete timelines and limited client involvement. For example, if we talk about healthcare sectors where Waterfall can be used to do the electronic health records systems for the patients. So, starting with defining the requirements, where basic information of the patients, that is information requirement, the information management is done, their medical history, and tracking and appointment scheduling can be done. And this does not need major client feedback because it's already... we already know that it's just an electronic health record that needs to be developed. So, the developers can just collect data like the patient records and the medical databases and all that. And then the final stage will be where, after all the testing is done, it can be employed in all the healthcare facilities, and continuous monitoring and maintenance can be done by adding patient names or if at all they want any other feature afterwards.

Great. Can you clap for Lizzy, guys? Very good answer, Lizzy. First, your communication as cool is awesome, five out of five. Now, Lizzy, one thing you missed out. That in Waterfall, you mentioned linear sequential model and all this. In Waterfall, until and unless we don't complete one stage, we can't move to another stage, and if you are in some another stage, you can't come back to the previous stage. Apart from this, everything is good. Second thing, when you're talking about the requirement part, you took the example of a health monitoring app. Those requirements, whenever you're explaining, should be on your mouth. Like, take... see, for example, you take the example of two to three requirements. Completely fine. You're just explaining it. Or if you're not comfortable, go with a simple example. Clear? Sure. Thank you. Very good job, by the way. Yes, thank you. Thank you. I'm really happy.

________________________________

Agile Methodology

Yes. Next, Nihal. What is Agile? Like, Agile methodology is used in the Software Development Life Cycle where it is very flexible, collaborative, and like customer satisfaction, where like small incremental work will be... we'll be getting feedback and continuous improvement. And like Agile will be used where the requirement is not clear and wherever like we can easily change whenever we want, and the requirement and solution evolve through the collaborative effort with multiple meetings where like from the start and the end, we used to do it. And like we can change any time, not like a traditional where Waterfall is like we can't go back and do anything, but in Agile, like we can change any time, whatever the feedback we get, immediately in the next Sprint, like we can change it.

But Nihal, again, examples. Even if they will ask the example, not as the example. Examples are inherent; we need to give examples to sound like we know things. If I have to explain what is Agile, Agile is one of the SDLC process, Software Development Life Cycle, where we deliver the work incrementally. See, Agile is... you can have a better answer, but Agile is one of the SDLC, Software Development Life Cycle approach where we deliver work. There are two things: incrementally and iteratively. Both are different. I will just explain you. Incremental is plus one. Iterative means after an interval... some cycle, cycle, cycle. Very good word. These terms will make sure, "Hey, you are an expert of your domain." After some intervals. For example, what can be the example? I took the example of WhatsApp. I stick to that. For example, take the example of WhatsApp. Incremental means you first delivered user registration. Yes. Second increment is you then delivered sending and receiving message feature, correct? Yes. Third, you delivered audio calling. Fourth, you delivered video calling, and so on and so forth, correct? Yes. It means after every Sprint, there is a concept called Sprint in a Scrum. Like, after every one week or two weeks, three weeks, or four weeks, we'll come to this. Sprint duration as per Scrum can be one week, two weeks, three weeks, or four weeks. Any... mostly 99% of organizations follow a two-week Sprint.

So, what happens? What we're telling is Agile is one of the SDLC approach where you deliver work incrementally and iteratively. Incrementally means first user registration, then after user registration, what is another increment? Sending and receiving plus one. Again, audio calling and video calling. How iteratively? After every week... for example, first week you deliver... for example, two-week Sprint. To deliver this, you went to the business, got the feedback. Again, you deliver another after two weeks. Again, you deliver this after two weeks. Again, you deliver this after two weeks. Again, you deliver this. What is happening? And that's what if you go to Waterfall, what will happen? All together will be developing and delivering. Making sense? Yes. These words: Agile is one of the SDLC approach where you deliver the work incrementally and iteratively, and please take the example, "Hey, let's take the example of WhatsApp." For example, there are features like user registration, sending/receiving messages, audio calling, video calling, blue tick. If I have to develop in the Agile way, what will happen? I'll take one or two features first, deliver this, get the review from the customer or the business, whatever the feedback, we'll again incorporate those as a requirement. Again, we'll take the third feature, again we develop this, again get the feedback, and all this, and you keep delivering in the same cycle. By doing this, what is happening? We are responding to changes over following the plan. Yes or no? Yes. Over following a plan plus we have a feedback loop which is improving the customer satisfaction. See your answer and see my answer. Are you getting the sense? Am I making sense? Yes. Which will improve customer satisfaction. That's why throughout the training, I'll be only behind one thing: "Please start framing." Because it's in the interview; this is the game. Only everyone knows the answer. Who is able to tell the answer well?

If I have to answer it again: Agile is one of the SDLC approach where you deliver the work incrementally and iteratively. For example, let's take the example of WhatsApp. For example, there are features called user registration, sending/receiving messages, audio calling, video calling, blue tick. If I have to develop in the Agile way, what will happen? I'll take one or two features first, deliver in a two-week or one-week Sprint, try to deliver, get the feedback. We'll have a review with the customer, get the feedback. If any enhancement they need, again, those feedback will be accommodated. And again, take the third requirement, and we again deliver it. Again, the same cycle, keep going on. So, by doing this, what is happening? We're responding to the changes over following a plan, and because we have a feedback loop, which will improve customer satisfaction also. Here, all the stages of software development in Agile... all the stages of software development life cycle... what happened? In Agile, all the stages of software development life cycle work together, correct? No? Yes. Are you guys able to see the difference with the example? That's why I'm discussing those questions. Clear, everyone? Yes.

________________________________

Three Differences Between Waterfall and Agile

What are the three differences between Waterfall and Agile? Sonam, there are two Sonams. Which Sonam is taking the initiative? Sonam Nigam, please. Sonam said: Waterfall model is a linear and sequential approach of SDLC, while Agile is an iterative and incremental approach. In Waterfall model, there is continuous... sorry, in Waterfall model, customer interaction is only at the beginning and it is very much limited. Whereas in Agile, customer interaction is continuous, as continuous feedback is taken and improvement is done. Waterfall model is best suited for shorter projects, while Agile is used for longer projects. Example, we can take for Waterfall model: if any bank has to come up for creating a mobile banking app which has all its prerequisites already listed and has to go for a similar creation, so they can go for Waterfall model. And for Agile, like the Government of India came up for the development of the IRCTC application.

How many differences did you just tell, Sonam? Three. Okay. Whenever you're telling the difference, point number one, point number two, point number three, at least the interviewer can also count this: how many differences told? First thing. Second, even after going into the differences, first explain one line what is Waterfall and Agile, and then go to the difference. Say, "Waterfall and Agile are both approaches to develop software, and both come under SDLC." And now go with the difference.

First difference is, guys, help me in answering this. First difference is: Waterfall model is linear and sequential. Agile is iterative and incremental. Waterfall model is a linear and sequential model where until unless one stage is not completed, you can't go to the second stage; until the second stage is not completed, you can't go back to the third stage. Whereas Agile is an iterative and incremental model. Yes, you keep delivering work after every interval, kind of. Keep delivering the increment, keep delivering the working feature. Second difference: In Agile, you will have a feedback loop. In Waterfall, you will not have a feedback loop. And because of the feedback loop in Agile, we'll have more customer satisfaction. In Waterfall, you will have less customer satisfaction. Correct? What is the third difference? You mentioned longer/shorter. You can also mention: Waterfall is better for a short-term project where requirements are 100% clear. For example, if there is a short-term project but the requirements are not clear, will we go with the Waterfall? Answer is no. So, you need to correct your answer: short-term project where requirements are 100% clear, no ambiguity in requirement. You can also mention about the flexibility and the resistance to change. Correct? Correct. In Agile, we are flexible; we are responding to change over following a plan. Waterfall, we are resistant to change. Once we come back to another stage, we can't go back to the previous stage; we will not be able to accommodate any other requirement. Correct? Yes. So, Waterfall: short-term project where requirements are 100% clear, no ambiguity in requirement. And Agile is for a project where we have complexity and requirements are not 100% clear. Correct? Yes. And other differences I have told you. Clear, everyone?

________________________________

Project Types for Waterfall and Agile

Question number five. But these things should be practiced. Question number six: What kind of project do you use Waterfall for, and for what kind of project do you use Agile? Nihal, hi. So, for Waterfall, since we just discussed, it's linear, sequential; it has a sequential approach, and the execution is rigid, like phase-by-phase manner also. You know, the requirement of the customer should be fixed or should have clarity that he wants a specific thing, right? So, for an example, once the project starts, it cannot make any changes in between; we cannot go back to the previous step, and in the later part, we cannot implement the new changes. So, for an example, we can say constructing a building. You can say the customer comes up with, "You know, the customer wants a 3BHK or maybe 4BHK," right? And they want it in a certain way: how big they want the rooms to be, how the kitchen should be, right? Once it's made or constructed, we cannot go back or make certain changes. So, when it comes to Agile, it's flexible and adaptable. We can make changes throughout the project lifecycle, like in between any time. Since it requires... in Waterfall, only the initial part of the project, starting with the project, the customer provides the detail or the requirement, and at the end, when the project is delivered, he requires it. Right? In Agile, throughout the project, there is contact or maybe follow-ups or feedbacks from the customer that we keep getting, and we can keep on improving the project. See, for an example, we can take an example of a social media application, for example, Facebook. Initially, when Facebook was introduced, we only had the option to connect with people, update status, and just to like any status, right? However, as the requirement grew or it kept growing, Facebook introduced us to connect or you can say sync your Facebook with your WhatsApp as well as your Instagram. You have different emojis, like button. So, for example, earlier it used to be only a thumbs-up like button. Now it has heart emojis and laugh emojis.

Very good. Can you clap for Nihal, guys? Very good answer, Nihal. You know how to answer it. I'm really happy how beautifully she mentioned that social media is an example of Agile. This is very good to actually understand. See, whenever Facebook came first time, remember, hardly Facebook also could not have thought that much feature they will be launching, correct? They're like, "Hey, let's... at that time, you remember few people orkut, anyone from orkut world? Lot of people." Correct? So, Facebook was like, "Hey, let's make it better than orkut where we can kind of people can connect, message them," kind of, you know, they can get a better UI/UX, kind of better user experience. They came up with this. But while developing it, while they start connecting with the user and start launching something, they got to know, "Hey, users want this also." They come up with two new features, correct? Again, two new features, again two new features, again to this. This is what Agile is. While complexity was there initially, they only knew few requirements, but after once they start doing it, they got to know more requirements, and they keep adding those requirements. Their features start getting evolving. They've also added Memories. Yes, yes, yes. So, any new feature, any new app, or anything comes, mostly they come in Agile because while doing, you learn, and we understand the customer behavior also. We keep getting the feedback; we keep improvising it. This is what is called Agile. Why I became happy with Nihal's answer because this example was apt. For a Waterfall, any banking application where you're just copying and pasting, some migration project you're doing, every single thing. For example, City Bank, Access Bank... how many of you know City Bank now? Almost sold to Access Bank, correct? So, they are migrating all those City Bank to Access Bank. For example, City Bank, they're telling, "Hey, City Bank customer was like, 'Hey, customer ID,' they like... they are not... Access Bank might be telling, 'Not customer ID,' they will be telling 'Consumer ID' for the same customer, but the nomenclature is getting changed. Everything is the same." Are you getting my point what I'm trying to say? So, migration project, copying or something... building... the example she has given... anything you are copying and pasting. And mostly 100% requirement... you can have some example of some banking application, not all banking application, banking where you're just copying and pasting, migration project.

But to start the answer, "What kind of project do you use Waterfall for?" Use Waterfall for a project where the requirement is 100% clear, no ambiguity on a short-term project. These three you have to tell: requirement is 100% clear, no ambiguity, short-term. Example can be this. What kind of project you use Agile for? Where the new feature development or where the requirement is complex, you don't know the 100% requirement at once, but while doing it, you'll keep learning. This is for those kinds of projects, and this keeps going on. Those kinds of projects, you use Agile for. Making sense? Yes.

Tanisha, recording... I think, you know, for Waterfall model, I think, as you gave the banking example, I think banking systems all go with Agile because it's... no, in banking... in banking, see, banking... I'm telling you, I'm working with the banks, so that's why I was telling. Though it's just... I think now everybody, every bank is using an Agile model because the user response is so much that they can't go with the Waterfall. I think the insurance domain is good for Waterfall model. I'll come to that. I got your answer. See, you are not wrong. What I'm trying to say, I just... I just not written banking application. I also written "just copying and pasting." 90% of the banking projects go with Agile only because the requirements are not clear. But few where, you know, kind of a migration thing or where you're just copying and pasting, there you can use Waterfall as well. That's what I'm... I'm not telling that the whole banking should go. Whole... if you go to multiple companies, they're hiring a Scrum Master where they're looking for banking experience in Agile. Are you getting my point what I just said? Yes.

Siddharth, hi. Along with banking, can food ordering application? Yes. Anything you are copying and pasting, for example, Zomato—same thing you are doing, or something you are not changing anything—then... and sometime, I give you the concept of Hybrid also: what is Hybrid? Waterfall plus Agile. Waterfall plus where the requirements... you're just copying... so far it will go to the Waterfall, and then where the requirements keep getting... you can go with this. For example, BallyFun which I want, few functionalities which I want as per my competition, and then I need to change as per my requirement in some of the functionalities, that goes into Hybrid. Correct. Correct. Correct. That's what I told, and a lot of... even in the banking, if you go, a lot of projects will say, "Here, they're working on a Hybrid model." A lot of projects will say they're working on an Agile model. A lot of projects will say they're working on a Waterfall model. All mixed you will see. But you should understand the concept: where do you use Agile, where do you use Waterfall, where do you use Hybrid? Got it? Yes.

________________________________

Explaining Agile to a Five-Year-Old & Slicing

Can you explain Agile to a five-year-old kid? Anyone try to explain Agile to your five-year-old kid if anyone has here, or you're just explaining me only? Please explain to your five-year-old kid or grandmother today if you have one.

Last question: What do you mean by horizontal slicing and vertical slicing? Imad. I think Imad is not there. The B... yes, yes, please. Sorry, I was unable to unmute. So, horizontal slicing divides work based on... not scaling, not scaling, slicing. Sorry. Horizontal slicing like it divides work based on technical layers. Like, you can say for the front-end or back-end without delivering complete features. Example, I can say like in an e-commerce platform, we first build the UI for the "Add to Cart" features, then work on the back-end APIs, and finally connect it to the database. So, each layer is developed independently and tested in isolation. Whereas the issue in Agile, I can say, horizontal slicing delays user value because the feature isn't functional until all the layers are completed. Whereas I can say in vertical slicing, vertical slicing divides work into smaller pieces, like end-to-end, like I can say user-focused increment that delivers functional features across. Let me give you an example, like, you know, the "Add to Cart" example, where the front-end team develops a UI button for "Add to Cart," then connects it to the back-end API for updates, and then ensures that the database records... records are in the cart item. So, this you can say... and the approach... why to use Agile? I can say it's incremental delivery, like functional features are released faster, and user validation is early. Where do you use vertical slicing? Vertical slicing is used in Agile. Horizontal slicing is in Waterfall. Yes, great.

Whatever Imad has answered, that is also good. The best answer is: go through... there are different layers of a software development life cycle in Waterfall. Until this is not completed, you can't move to the second stage. Until the second is not completed, you can't move to the third stage, and all this. And give the example of a cake, what I just explained to Sonam also. Clear? Simple example. The best example Imad's answer is also good.

________________________________

Agile Manifesto Values & Principles

Agile Manifesto: four values, twelve principles. Anyone would be able to say four values without even saying the notes or anywhere? Anyone remembers the four values? Yes. Who, who is that? Ashutosh, please. Four values... come on, video, I'll see otherwise I'll notice whether you are seeing the notes or not. Yes, yes, yes, yes. I'm already here. So, "Individuals and interactions over processes and tools." Working software over comprehensive documentation... Oh, sorry. One second, one second, one second. These are individual interaction over process and tools, working software... Don't change those names. Okay, okay, okay, okay. "Customer collaboration over contract negotiation." And the last one is "Responding to change over a fixed plan." Responding to change over following a plan. These four need to be remembered, guys. What I used to do, I will share my experience because I also, somewhere down the line, no one is born as a Scrum Master, correct? What I used to do: I used to remember these four honestly because they ask the question. But these twelve values... no one will be able to remember these twelve values, twelve principles. Four values, you're able to remember. What I used to do, I just copied and pasted on my wall wherever I'm appearing for an interview. And I know that only I will be knowing a few Qs, even I will be able to answer. Are you getting my point what I'm trying to say? Because you don't have to remember. Only thing what you have to do in these twelve principles is Simplicity, satisfy the customer, no, Simplicity is the question they ask, but satisfy the customer, continuous delivery, welcome changing requirement. These keywords, just understand and make your story. No one... "Hey, I don't remember those twelve... twelve values," but twelve values are mostly surrounded by that: "In Agile, customer is the king. We try everything to satisfy the customer. We keep delivering work continuously, iteratively, incrementally way. We welcome changing requirement. We respond to change over following a plan. We deliver working software frequently." Like these keywords, that is enough. You don't remember. But four values, you have to remember them. And this one, I have given as an assignment. I'll be asking in the next class. Clear? You have to go through one. And if you're really a good cheater, please paste it on your wall, whatever you want to do. I used to do this. I want to be very honest. Clear?

Now, this we discussed. Now, what we're going to do today... everyone clear? Four values of Agile Manifesto: remember. Twelve principles: no, just remember a few keywords. Clear? Now, yes. Here, we are going to start Scrum, Agile, and all this. What about the question there? Now, I'm going to give you an overview, and we'll discuss in detail. Let me go to the Scrum. Here is my screen visible? Yes. Very high concentration. One second. Let me stop sharing and re-sharing, then this will work. Very high concentration for the next half an hour. You just listen to me, and whatever the question, you just keep writing. I will discuss all those questions. Clear? It's visible to everyone?

________________________________

Scrum Framework: The 3-5-3 Rule

Okay, now Scrum. What is Scrum? One of the Agile frameworks. Under Agile, there are multiple frameworks like Scrum, SAFe, Kanban, and there are other frameworks like Crystal, Extreme Programming, and all these. Scrum is one of the frameworks under Agile. Clear?

Now, how does Scrum work? Let's take the example of WhatsApp. Now, there are three accountabilities in Scrum: one is Product Owner, second is Scrum Master (which you have to become), and third is called Developers. There is no more called "Development Team" now; they are called as Developers. Accountability number one, accountability number two, accountability number three.

We have five Scrum events: all I'll be explaining; you don't have to worry. First Scrum event is the Sprint itself, like it should be of one month, one week, two weeks, three weeks. Second Scrum event is Sprint Planning. Third Scrum event is Daily Scrum. Fourth is a Sprint Review, and fifth is a Sprint Retrospective.

And there are three artifacts: one is the Product Backlog, second is the Sprint Backlog, and third is the Increment. So, these are called the 3-5-3 rule of Scrum: three accountabilities (Product Owner, Scrum Master, Developer), five Scrum events (Sprint, Sprint Planning, Daily Standup, Review, Retrospective), and three artifacts (Product Backlog, Sprint Backlog, Increment). Clear?

________________________________

The Scrum Process Flow (WhatsApp Example)

Whatever I am going to teach today, this we are going to do for 1.5 months. So, if you'll try to like, "Hey, I will become an expert today," that is not going to happen. Clear? But I'll be giving you the overview. Please, very high concentration.

What happens? Let's take the example of WhatsApp. WhatsApp will have multiple requirements. For example, requirement number one, requirement number two, requirement number three, requirement number four, requirement number five, and so on and so forth. There will be multiple requirements. Product Owner, Scrum Master, and Developers are part of a Scrum Team—three accountabilities.

Product Owner's job is to hear the business. Be there; WhatsApp business will be there. Product Owner's job is to go to the business and ask, "Hey business, what exactly you want to develop?" For example, Infosys is building WhatsApp. The Product Owner will be from the Infosys team or any place. This person will go to the WhatsApp or Facebook because WhatsApp is owned by Facebook, ask, "Hey, what exactly you want us to build?" He will tell... the business will tell: "You know what you want? Registration. We want sending and receiving messages. We want audio calling. We want video calling. We want blue tick. We want this, we want that, we want this, we want that." Great.

Now, this Product Owner has an assistant, that is called BA (Business Analyst). Some companies tell them SA (System Analyst). System Analysts are more technical in nature compared to Business Analysts. But as of now, just for the sake of understanding, understand that there will be a BA. What will happen? BA along with the Product Owner both will go to the business. See here, there will be a call called Requirement Gathering Call, which we have to get the requirement by what exactly they want us to build. Please mute yourself. I'll give you a chance to ask all those questions. These people, Product Owner along with the Business Analyst, will go to the business, ask you what exactly you want us to build in a WhatsApp. They will say all the requirements one by one. Now, whatever the requirements they will tell, that will come here: one, two, three, and there can be four, five, and there can be 100, 200, 500. There is no limit. That is called the Product Backlog.

So, what is Product Backlog? Please mute yourself. What is... what is Product Backlog? So, we can see it as a list of tasks, yes, a list of all the requirements at one place. For example, the first requirement can be user registration. Second requirement can be audio calling, video calling, sending/receiving messages, blue tick. All those requirements one by one, whatever you need to do as part of a WhatsApp as a product, every single thing will be in the Product Backlog. Correct? And who gets the requirement in the Product Backlog? PO with the help of a BA. Who owns the Product Backlog? Product Owner, because this person goes to the business and gets the requirement. All those requirements. And whether this will be a static document or a live, dynamic document? Dynamic. It will be dynamic because you're working in Agile. At one time, all the requirements... even the business will not tell, like how Nihal gave the example of social media, correct? Again, you'll keep going to the business, keep adding the requirement again and again. So, this is a Product Backlog is always dynamic, and there is no hard and fast rule like there can be 10 items, 20. As much as items to build a great WhatsApp as a product. Correct?

Now, every product will have a Product Goal. "Hey, what exactly if you're building a WhatsApp, what exactly you want to build?" What can be the Product Goal? Product Goal in a WhatsApp case can be making more efficient communication for people sitting across the globe by various means like chatting, audio calling, video calling, and all those things. Simple, like what exactly you want to achieve. So, where is my cursor? Okay. So, this will be every product will have one Product Goal, and in order to achieve one Product Goal, you will have a lot of Product Backlog Items (PBIs). PO and a BA will go to the business, get all those requirements from the business, and you'll add in the Product Backlog.

Now, let's assume there are 100 items in the Product Backlog. Very high concentration. 100 items in the Product Backlog. Now, this might take 3 months, 4 months, one year, two years to do. What Scrum suggests? Scrum just simplifies the things. What Scrum suggests? "Hey, there are 100 items, no team..." Because there will be one Scrum Team. Try to understand, that is called here Scrum Team. In a Scrum Team, hardly will have around 10 to 12 members, around 10 members. In those 10 members, one will be the PO, one will be the Scrum Master, and the remaining eight will be called as Developers. I'll discuss more on this throughout the Scrum training; you don't have to worry. These eight people will be called as Developers.

Now, try to understand: there will be one Scrum Team. There will be a lot of items to do. What Scrum suggests? If it will take 6 months, one year, two years, why can't we do... why can't we divide into a concept called Sprint? There will be a concept called Sprint, Sprint, Sprint. "Hey, if there are 100 items, we'll not take all 100 items. We'll ask the business, 'What do you want us to build first?'" Business will tell, "Hey, first I want to build these two features or these four features." For example: sign up, sign in, sending/receiving messages, or for example, audio calling. For example, these features we want first out of 100 requirements. Our first priority is this. Who prioritizes it? PO with the help of the business, because the business ultimately will give the call.

What will happen? The PO team will first take those items into a Sprint Backlog. This is Product Backlog; there will be a meeting called Sprint Planning. In the Sprint Planning, the team will take items from the Product Backlog to the Sprint Backlog based on team capacity. There are only... remember, there are only 10 members, eight developers. So, they can't do all the work in two weeks because you'll have a Sprint called... it can be one week, it can be two weeks, it can be three weeks, it can be four weeks. Mostly, in the real world, 99% of the organizations follow a two-week Sprint.

So, two weeks, eight members—they will have some bandwidth; they can do some number of work. They will be taking those number of work from the Product Backlog to the Sprint Backlog. For example, they have a bandwidth to take only four work. So, from here to here, for those two-week duration, they will be taking those four works. How? For example, if a Sprint is two weeks, what will be... for example, today's date is January 19th. So, the Sprint will go till how much date? Two weeks, means 14 days around, first of February, something kind of... I might be wrong in the date, but try to understand. That means two weeks, that means 10 working days if you have Saturday/Sunday off. What will happen? On January 19th, we'll have the Sprint Planning: what are the items the team can do in this period, and how many team members are there? 10 members, out of which eight developers are there, one is the Scrum Master, one is the PO. The remaining all are called as Developers. I'll come to this in detail. Remaining all are called as developers. So, there will be some bandwidth: "Hey, we can only do four items," "We can only do two items," "We can only do three items." Based on the bandwidth, we'll be taking items from here to here. When? Which meeting? Sprint Planning. What is a Sprint? A Sprint is a duration, a cadence. For example, if it is a two-week duration, it will be starting on January 19th, closing on February 2nd. Then again, the next will be starting on February 3rd, again it will be going for two weeks, for example, February 16th something kind of. Again, another Sprint will be starting on February 17th, again we'll be going... We are talking about this Sprint. What will happen? During the Sprint Planning meeting, we will be taking items from here to here based on how much the team can take. There will be a lot of concepts coming: capacity, velocity—I'm not using it; we'll use later on. We're just understanding the basics.

Now, for example, you have taken four items. What exactly you want to achieve by completing those four items? That will be the Sprint Goal. "Hey, what exactly you want to achieve in this Sprint?" See, there were 100 items. What you did? And there you will have a Scrum Team. You divided into two-week periods. "Hey, this will take 6 months to do or one year to do? Let's divide into two-week Sprint. Two-week Sprint, another two-week Sprint, another two-week Sprint, another two-week Sprint, another two-week Sprint." What we're doing? So, the team will have limited bandwidth; that much you'll be taking from here to here. But based on what the business wants first. Who prioritizes the Product Backlog? PO with the help of the business. Now, when you will be discussing the first day, obviously you'll be working on January 19th: "Hey, what do we have to do for the next two weeks?" And you'll be taking those items. Now, once you take those items, what exactly you want to achieve in the Sprint by implementing those items? That will be part of a Sprint Goal. For example, you took sign up, sign in, sending/receiving messages, audio calling. What will be the Sprint Goal? "As part of this Sprint, we want to deliver user registration, sending/receiving messages, audio calling, and video calling feature." This is the Sprint Goal. What exactly you want to achieve?

Now, you have done the Sprint Planning. Out of a lot of items, we have taken four items. Now, the whole two-week period, January 19th to February 2nd, the team will be concentrating on those four items to develop it and make sure they are able to complete it. So, all the developers in the team, they will be... what they will be doing? They will be concentrating on those four items. Developers means actual developers will be doing the coding; testers will be doing the testing, and all this. All are called as per Scrum as Developers only. Correct? What will happen those two weeks, January 19th to February 2nd? These developers will work on only these four functionalities and try to complete it. But how would you get to know whether they are on track or not on track? We'll have a Daily Scrum call every day for 15 minutes at one location—either it can be Zoom, Microsoft Teams, or if the team is at one place, for example, Hyderabad location, they'll be sitting at one location. And then we'll be having a Daily Standup. What they will be discussing in a Daily Standup? "Hey, we have committed this four work, and you have to complete by the end of the Sprint, and you have set the Sprint Goal." They will inspect the progress towards the Sprint Goal. "Hey, are we on track to achieve the Sprint Goal by the end of the Sprint? Are we lagging? Are we leading? Is there any blocker?" Because at the end of the day, what they have to do? They have to achieve the Sprint Goal, correct? They will be discussing all this. If any blocker or any risk or anything, they will try to come up with a solution. Who joins the Daily Scrum? Developers are mandatory. Scrum Master and PO are optional. Scrum Master is also optional. Developers are mandatory. Why? Who committed? Who took the work from the Product Backlog? Who committed the work here? For example, you took four items from here out of the hundreds of items in the Product Backlog. During the Sprint Planning, you took four items, and you told that, "Hey, within two weeks, we'll be working on four items and will be achieving the Sprint Goal." Whose job is to complete this? Developers or Scrum Master? Developers. So, who owns the Sprint Backlog then? Developers. Developers own the Sprint Backlog. Product Owner owns the Product Backlog. Correct. Correct.

That means whose duty is to make sure that we are able to complete the work by the end of the Sprint? Developers. So, who will be attending the Daily Scrum call? Who will be mandatory in Daily Scrum? Developers. Scrum Master and PO are optional; they can join. Apart from this, no one is allowed. But mostly 99% of the organizations, the Scrum Master facilitates that call. I'll come to that later on. So, Daily Scrum: whole developers will join, and what they will discuss? "Hey, we committed four. We have a Sprint Goal set. Out of it, are we good to complete by the end of the Sprint? Are we good to achieve the Sprint Goal by the end of the Sprint? If any blocker or any risk and all this, they will be discussing and try to come up with a solution. If any blocker they are not able to resolve themselves, they can ask the Scrum Master for assistance: 'Hey, Scrum Master, this is the place where you're getting stuck. Can you help this?'" We'll be discussing how it happens later on.

So, Daily Scrum happens daily. For example, January 19th, 20th, 21st, 22nd, every single day till February 2nd, it will happen. That's why it's called daily. By the end of the Sprint, February 2nd, is the last date of the Sprint. By the end of the Sprint, what will happen? They will be completing this work, correct? Yes. There are four items; they will be completing the work. Those works, whatever they completed, that will be called an Increment. Increment is plus one. Initially, sign up was not there; sign up happened. Now, sign up is there, plus one. Sign in was not there; sign in is there, plus one. Audio calling was not there; audio calling is there, plus one. Sending and receiving message... not they haven't done it. So, all this they will be completing. So, all this will be called as Increment or a working feature because now they have developed. Now, that will be in a workable condition, correct?

But whatever they have developed here, here, here, here, here, here, here, whatever they developed here, how would you ensure whether they developed rightly? Whether the business is happy or not happy? Any feedback? You'll have a Sprint Review call. In a Review call, what happens? Business will be joining the call. Stakeholders will be joining the call. Who is a Stakeholder? A stakeholder's basic definition is the person who is directly or indirectly involved as part of the product is called a Stakeholder, and mostly we refer to the business because they are also involved as part of the product. A stakeholder can be your team also, whoever is developing. Your business can also be the stakeholder. Your leadership team can also be a stakeholder. Those who have a stake, all are a stakeholder. For example, Papa—all the sons and daughters of the Papa are the stakeholders for this. They claim a stake: "This is my Papa's land." Correct? Same way, what is a stakeholder? The person who is directly or indirectly involved as part of the product is called a Stakeholder. During the Review meeting, whatever the increment they have produced, the business will be reviewing those features. Hey, and what exactly they'll be doing? What about the sign up, sign in, sending/receiving messages, audio calling, video calling? They will be reviewing, "Hey, this is how it is working. This is how it is working. This is how it is working." If any feedback from the business... for example, initially the business told, "Hey guys, please mute yourself." Please mute yourself. Who is that? Let's not disturb the class. Please. Now, for example, in the review, what happened? Initially, the business told, "Hey, we just want sign in using mobile number and OTP." But later on, while reviewing, the business comes up with the idea, "Hey, can't we add email ID and OTP option also?" Initially, the requirement was not this. Those four requirements. Now, they can say, "Hey, we want email ID and OTP." What happened? The business came up with the idea that can be much better. That means that is a separate requirement. Those whatever the new enhancements they will come up with, that will go to the Product Backlog again. Because, "Hey, now the business also wants what? Email ID and OTP combination." And once those ideas will again... Product Owner with the help of the business... see, when they want, for example, if they want... first, the Product Owner prioritizes first. And again, during the Sprint Planning, we'll be taking those items in the next Sprint. Every Sprint will have a Sprint Planning. They'll be taking the Sprint, and again, we'll be repeating the same cycle.

So, in the Review, what happened? Review is basically a call where the Scrum Team, your business stakeholders, join the call, and whatever the increment you have produced, whatever the development, testing you have done, those increments—the review—working feature, not the documentation. The review. And if they come up with any feedback, those feedback will be taken as a form of a requirement, and that will go to the Product Backlog again. And once it will go to the Product Backlog, obviously there will be some other requirement already plus that will be again another requirement, and the PO again will work with the business, and whatever the sequence the business wants in the priority, the same sequence again, the next planning will happen. Again, you'll be taking a few work. Again, developers will be doing. Again, Daily Scrum, and all those things will be happening.

________________________________

Sprint Retrospective

But in the last, there is another event called Retrospective. This, I keep telling, this is a proper Hindi word, those who understand: Atma Chintan Shivir. What is Atma Chintan Shivir? The team worked for two weeks; they might have done a lot of mistakes; they might be having a lot of problems, a lot of here and there conflict. They were not able to understand Scrum in a proper way. They were not able to commit the dependencies. A lot of things, like how India and Australia border... a lot of things happened. And you remember, after the match, the whole team with Gambhir and all this, they kind of do the Manan/Atma Chintan Shivir. In the end, on the last day of the Sprint, they will have a Retrospective: "Hey, what went well? What didn't go well? How can you improve?" And they will come up with Action Items. Action Item can be, for example, "Hey, the team was not suitable; they didn't understand Scrum in a better way." Can be: Scrum Master will be giving a Scrum training to them. They were not more efficient in JIRA, and because of this, the work got delayed. JIRA training... a Scrum Master or anyone can give. For example, the collaboration was not that good. The team was kind of... a lot of infighting was happening, a lot of conflict. You come up with a Work Agreement to the team; the team has to follow that Work Agreement, correct? There can be N number. So, why are they doing the Retrospective? That the next time they should not be again doing the same mistake, because we have to keep improving, correct? And everywhere this Atma Chintan Shivir will happen. Congress lost the election—Atma Chintan Shivir. BJP lost the election—Atma Chintan Shivir. After a lot of Atma Chintan Shivir, now they are ruling the country, correct? So, they come up with the action item: "Hey, where are you going wrong?" And they come up with some action item, and those action items move to the Sprint Backlog just to as a tracker.

________________________________

Scrum Review vs. Retrospective Summary

Whatever the tracker... see, again, I'm repeating how the process works. Please, next time. And this is the last time. Please... Here, what happens: What is Scrum? Under Agile, we have multiple frameworks; Scrum is one of the frameworks. And what Agile says: we deliver the work incrementally and iteratively. How is Scrum satisfying this? See, for example, you have a two-week Sprint. Every two weeks, you're delivering some Increment, and every two weeks itself is an Iteration, correct? So, that means Scrum is following exactly what Agile says.

Now, in Scrum, what happens? There are three accountabilities: Product Owner, Scrum Master, Developers. Accountabilities, I'm telling, not roles. Roles are now changed to accountability. There is no role in Scrum now. Three accountabilities: one, Product Owner; two, Scrum Master; three, Developers.

Five Scrum Events: The Sprint itself is one Scrum event. And what is a Sprint duration? It can be one week, two weeks, three weeks, or four weeks. We are saying that "Hey, our Sprint duration is two weeks." We are just assuming. Some companies, it can be one week, two weeks, three weeks, or four weeks.

Second is Sprint Planning. Third is Daily Standup. Fourth is a Sprint Review. Fifth is Retrospective.

Three Artifacts: One is the Product Backlog, second is the Sprint Backlog, and third is the Increment.

How it happens in Scrum? For example, WhatsApp is one product. Every product will have one Product Goal: "Hey, what exactly you want to achieve out of the product?" For example, in WhatsApp's case, can be, "Hey, we want to have some application where customers can have end-to-end communication, enhanced communication through multiple means such as audio calling, video calling, sending/receiving messages, and all those things." In order to achieve the Product Goal, there can be a lot of Product Backlog Items.

PO with the help of a BA reaches out to the business. "Hey BA, tell me what is the requirement? What exactly you want us to build?" They will tell all those requirements one by one. They will be adding all those requirements here: one, two, three. There can be a lot of requirements. That is called the Product Backlog. What is the Product Backlog? A place where all the requirements will be there. Correct? And who owns the Product Backlog? PO, because he gets the requirement from the business. All those requirements. And whether this will be a static document or dynamic? Dynamic. Because you're working in Agile, all the requirements will not be told at one time. The business might keep adding the requirement during the Sprint Review also if there is any enhancement. They will keep adding the requirement again and again. So, this is dynamic; it will keep changing, keep having additions, keep having removals. What if the business told earlier, "Hey, we want this," but later on, "Hey, we don't want this?" So, this is dynamic; this is not fixed.

Now, Product Owner owns the Product Backlog, holds the vision of the product, gets the requirement every single thing, and the BA is just a supporting assistant to help them in gathering the requirement. Clear?

Once that gets done here, now this can go for 6 months, one year, two months, whatever it is. What Scrum suggests? Divide the bigger work into smaller work. They're like, "Hey, go with the concept called Sprint." One week, two weeks, three weeks, four weeks. I'm just assuming two weeks for example. This is starting on January 19th and closing on February 2nd. So, what will happen? On January 19th, the first day of the Sprint, we'll have the Sprint Planning. What are the items the team can take from the Product Backlog to the Sprint Backlog? Correct? But there are a lot of factors here: "Hey, what the business wants first? Second, is this groomed? Do the developers know what exactly they have to do? Third, how much work the developer can take, because they have only so much time, and they are only, for example, 10 members as a Scrum Team?" There can be a lot of questions here; we'll be discussing those questions later on. For example, developers can take only four works. And I am just assuming that those first four works are prioritized, and this is what the business wants. During the Sprint Planning, we'll be taking those works from the Product Backlog to the Sprint Backlog.

Once we take it, what is the job of the Scrum Master? The Scrum Master will be facilitating this call during the Sprint Planning. Now, for example, those four works we have taken. "Hey, what exactly you want to achieve out of this?" That will be the Sprint Goal. "What exactly you want to achieve?" See, there were 100 items. What you did? And there you will have a Scrum Team. You divided into two-week periods. "Hey, this will take 6 months to do or one year to do? Let's divide into two-week Sprints." Two-week Sprint, another two-week Sprint, another two-week Sprint, another two-week Sprint. What we're doing? So, the team will have limited bandwidth; that much you'll be taking from here to here, but based on what the business wants first. Who prioritizes the Product Backlog? PO with the help of the business. Now...

Once you take the work, these people have to make sure that from January 19th to February 2nd, they have to complete that work, and whatever the work you have taken, what you want to achieve—what exactly you want to achieve by the end of that—will be the Sprint Goal. Now, the developers will meet on a daily basis, and hey, they will inspect progress toward this Sprint Goal. "Are we on track to achieve the Sprint Goal by the end of the Sprint? Are we lagging? Are we leading? Is there any blocker?" Who is mandatory in Daily Scrum? Developers. Scrum Master and PO are optional. But in most of the organizations, 99% of the cases, the Scrum Master facilitates that call. Correct? Now, that is time-boxed to 15 minutes.

Now, for example, they will be doing this. Now, at the end of the day, daily they will have a Daily Scrum. On the last day or the second last day, February 2nd, the Sprint is getting closed. Now, they'll be completing the work, correct? Yes. There are four items; they will be completing the work. Those completed items will be called an Increment. Increment means initially, the sign-up feature was not there; now, sign-up feature is there. Plus one. Sign in was not there; sign in is there. Plus one. Audio calling was not there; audio calling is there. Plus one. Sending/receiving message... All this increment will happen. Now, who is building this? The Scrum Team. For whom? The business. So, whatever they have built, they will have a review with the business stakeholders in a Sprint Review. The business and all this, they'll be reviewing the working feature, not the documentation. The review. And if they come up with any feedback, for example, sign-in... I gave the example, they said initially, "Hey, we want sign-in using mobile number and OTP." But later on, while reviewing, the business comes up with the idea, "Hey, can you have the email ID and OTP option also?" Initially, the requirement was not this. Those four requirements. Now, they can say, "Hey, we want email ID and OTP." What happened? The business came up with the idea that can be much better. That means that is a separate requirement. Those whatever the new enhancements they will come up with, that will go to the Product Backlog again. Because, "Hey, now the business also wants what? Email ID and OTP." And once those ideas will again... Product Owner with the help of the business... see, when they want... for example, if they want... first, the Product Owner prioritizes first. And again, during the Sprint Planning, we'll be taking those items in the next Sprint. Every Sprint will have a Sprint Planning. They'll be taking the Sprint, and again, we'll be repeating the same cycle.

________________________________

Sprint Retrospective & Summary

But in the last, there is another event called Retrospective. This, I keep telling, this is a proper Hindi word, those who understand: Atma Chintan Shivir. The team worked for two weeks; they might have done a lot of mistakes; they might be having a lot of problems, a lot of here and there conflict. They were not able to understand Scrum in a proper way. They were not able to commit the dependencies. A lot of things, like how India and Australia border... a lot of things happened. And you remember, after the match, the whole team with Gambhir and all this, they kind of do the Manan/Atma Chintan Shivir. In the end, on the last day of the Sprint, they will have a Retrospective: "Hey, what went well? What didn't go well? How can you improve?" And they will come up with Action Items. Action Item can be, for example, "Hey, the team was not suitable; they didn't understand Scrum in a better way." Can be: Scrum Master will be giving a Scrum training to them. They were not more efficient in JIRA, and because of this, the work got delayed. JIRA training... a Scrum Master or anyone can give. For example, the collaboration was not that good. The team was kind of... a lot of infighting was happening, a lot of conflict. You come up with a Work Agreement to the team; the team has to follow that Work Agreement, correct? There can be N number. So, why are they doing the Retrospective? That the next time they should not be again doing the same mistake, because we have to keep improving, correct? And everywhere this Atma Chintan Shivir will happen. Congress lost the election—Atma Chintan Shivir. BJP lost the election—Atma Chintan Shivir. After a lot of Atma Chintan Shivir, now they are ruling the country, correct? So, they come up with the action item: "Hey, where are you going wrong?" And they come up with some action item, and those action items move to the Sprint Backlog just to as a tracker.

________________________________

Scrum Summary & Next Steps

So, whatever the tracker... see, again, I'm repeating how the process works. Please, next time. And this is the last time. Please... Here, what happens? What is Scrum? Under Agile, we have multiple frameworks; Scrum is one of the frameworks. And what Agile says: we deliver the work incrementally and iteratively. How is Scrum satisfying this? See, for example, you have a two-week Sprint. Every two weeks, you're delivering some Increment, and every two weeks itself is an Iteration, correct? So, that means Scrum is following exactly what Agile says.

Now, in Scrum, what happens? There are three accountabilities: Product Owner, Scrum Master, Developers. Accountabilities, I'm telling, not roles. Roles are now changed to accountability. There is no role in Scrum now. Three accountabilities: one, Product Owner; two, Scrum Master; three, Developers.

Five Scrum Events: The Sprint itself is one Scrum event. And what is a Sprint duration? It can be one week, two weeks, three weeks, or four weeks. We are saying that "Hey, our Sprint duration is two weeks." We are just assuming. Some companies, it can be one week, two weeks, three weeks, or four weeks.

Second is Sprint Planning. Third is Daily Standup. Fourth is a Sprint Review. Fifth is Retrospective.

Three Artifacts: One is the Product Backlog, second is the Sprint Backlog, and third is the Increment.

So, and that is called the 3-5-3 rule of Scrum. If you go to the interview, prepare this: "What are the 3-5-3 rule of Scrum?" I have already explained what are the 3-5-3 rule of Scrum. Clear?

This is what we discussed. And apart from this, we also discussed other questions of the people: how the Scrum Team looks like. I have explained what are the three accountabilities and how this team gets formed. There will be different, different names of the team. And now, roles have been changed to accountability. Development Team is no more a term; we call Developers. And we get the roster from the leadership team based on the skill set. They decide the project based on the project and all this, and you have to accordingly function. And you also discussed Scrum suggests you should have 10 or less than 10 people in a Scrum Team because there will be more collaboration, and all... But in the real world, you can find anything. This is should have, not mandatory.

And then you also discussed: there is a Scrum Team, and sometime they call it a Squad. This term is not covered with the Scrum Guide. Only Scrum Guide is the source of truth. Apart from this, nothing is a source of truth. Making sense?

Otherwise, Scrum Team... and we also discussed nowadays there is a concept called Pod structure. Where they are aligning every team in such a way that they have equal team members, like same, for example, 10 team members, 12 team members—equal team members and equal skill set also. Why? Why are they doing it? For example, in a Pod, there are five teams: Team number one, Team number two, Team number three, Team number four, Team number five. What they will do? Every team, they will keep equal 10 members, 10 members, 10 members, 10, 10, 10, or for example, they want to keep 12 members, 12 members, 12 members, 12 members, 12 members. Plus, those 12 members also, they will keep one lead who has all that much skill set, test lead, and that means for example, four developers. This team, this team will also have four developers, four developers. And their skill set kind of also be the same because they want to compare them on their performances. Otherwise, what will happen? If one team has 12 members, one team has 10 members, one team has 8 members, do you think we'll be able to compare? No, because they want to compare them on their performances. And what is performance? All is Scrum Metrics: "Hey, how much... how much they are delivering the work?" And all those things we'll be discussing. So, three concepts: Scrum Team, Squad (is a team), Pod structure (is also a Pod where there can be multiple Scrum Teams), but they have the same team size, same skill set so that they can compare based on performance—how much work they are able to deliver, how much defect is coming, what you are doing on the defect improvement, and there are a lot of factors. Making sense?

But one thing you have to remember: at the end of every Sprint, at the end of every Sprint, we should have minimum one Increment. You remember this example? Minimum Scrum suggests you should have minimum... See here, the example you have taken, we took four functionalities here, so you can have four increments also. But what Scrum suggests? Minimum one Increment you should have at least one working feature. You remember the Agile Manifesto: "Working feature over comprehensive documentation." Here, "Working Software over comprehensive documentation." Where is it? If you go to the four principles, if you go down here, so at least minimum one Increment will be there, one working software will be there so that the business can review it and you can get those feedback. What Scrum suggests? Making sense?

So, how the Scrum Team looks like? Everyone understood? Questions, please.

________________________________

Summary of Today's Discussion

Now, what we discussed so far today: First, we discussed like, "Hey, what are the interview questions related to SDLC and all this?" Then we come to the Scrum basics. Next 20 classes, we are going to build upon the same here. What is the Product Goal? What exactly it looks like? How the Product Owner gets the requirement from the business? There will be one class there. There will be two to three classes here: how the Backlog Refinement happens, how the Capacity Planning happens. Because see, even the developer's Sprint Backlog... developers are taking the work from the Product Backlog to the Sprint Backlog. Today, we just considered they will be taking four works or five works. On what basis are they deciding they will be taking four works, five works? There will be concepts of capacity, there will be concept of velocity, there will be concept of how they're prioritizing the Product Backlog—which items the business wants first. All those techniques... Product Backlog Prioritization. When this whatever the requirements they are taking, when this requirement will get groomed? Backlog Refinement. There can be a number of questions: how the estimation happens, User Story estimation—all those. There are a lot of topics in between; those we'll be discussing. So, there will be around 20 classes on this.

Now, what we learned today: Under Agile, you have a framework called Scrum. So, whatever Agile does, Scrum also has to follow. Agile has four values, twelve principles; even Scrum, because Scrum comes under Agile, Scrum has to abide by those values and principles. That means Scrum also has to deliver the work iteratively and incrementally. Iterative means time by time, like Sprint by Sprint, and incremental means one feature by another—sign up, sending/receiving, and all that. That's what Scrum is also doing.

What you understood is that Scrum will have three accountabilities: one is Product Owner, second is Scrum Master, and third is called Developers (not Development Team, because the nomenclature has changed). Five Events: one will be the Sprint itself, then Sprint Planning, a Sprint can be one week, two weeks, three weeks, four weeks. Sprint Planning happens on the first day of the Sprint, for example, January 19th to February 2nd. Daily Scrum daily. Sprint Review in the last, whenever you are able to build the Increment. And Retrospective, kind of Atma Chintan Shivir, where the team will be introspecting: what exactly... how this Sprint went, what went well, what didn't go well, how can we improve? A lot of things.

Now, what happens? For example, let's take the example of WhatsApp, and you have to build the WhatsApp using the framework called Scrum. How will you be building it? WhatsApp as a product will have one Product Owner. The Product Owner of WhatsApp will have every product will have a Product Goal. Product Goal means what exactly you want to achieve out of the product. For example, as part of this product, we want to have an end-to-end communication from users sitting across the globe through various means such as sending/receiving messages, audio calling, video calling, and getting a better experience to the user. Any product goal can have.

Now, in order to achieve that Product Goal, under this product, you can have a multiple requirement. Product Owner with the help of a BA reaches out to the business. "Hey business, tell me what exactly you want us to build." They will give all the requirements. "Hey, we want users should sign up, sign in, sending/receiving messages, audio calling, video calling, blue tick." There can be a lot of requirements. Whatever the requirements will come, the Product Owner and Business Analyst will be grooming, adding all those requirements in the Product Backlog. What is the Product Backlog? A place where all the requirements will be there. Correct? Simple language. There can be... and this is dynamic. Dynamic means business, because you are working in Agile, all the product items will not be... all the Product Backlog Items will not go in one call. Business might keep adding the product during the Sprint Review also if there is any enhancement. They will keep adding the product again and again. So, this is dynamic; this will keep changing, keep having additions, keep having removals. What if the business told earlier, "Hey, we want this," but later on, "Hey, we don't want this?" So, this is dynamic; this is not fixed. Now, Product Owner owns the Product Backlog, holds the vision of the product, gets the requirement, every single thing. And the BA is a supporting assistant to get help them in gathering the requirement. Clear?

Once that gets done here, now you have a lot of requirements here. Now you have to build it. What Scrum suggests? If you're building using the Scrum, you have to build Sprint by Sprint. A Sprint is a duration; it can be one week, two weeks, three weeks, four weeks. I'm just assuming two weeks for example. This is starting on January 19th and closing on February 2nd. So, what will happen? On January 19th, the first day of the Sprint, we'll have the Sprint Planning call. During the Sprint Planning call, the team will be discussing what items they can take from the Product Backlog to the Sprint Backlog. Correct? But there are a lot of factors here: "Hey, what the business wants first? Second, is this groomed?" Groomed means, "Do the developers know what exactly they have to do?" Third, "How much work the developer can take," because they have only so much time, and they are only, for example, 10 members as a Scrum Team. There can be a lot of questions here; we'll be discussing those questions later on. For example, developers can take only four works. And I am just assuming that those first four works are prioritized, and this is what the business wants. During the Sprint Planning, we'll be taking those works from the Product Backlog to the Sprint Backlog.

Once we take it, what is the job of the Scrum Master? The Scrum Master will be facilitating this call during the Sprint Planning. Now, for example, those four works we have taken. "Hey, what exactly you want to achieve out of this?" That will be the Sprint Goal. "What exactly you want to achieve?" For example, sign-up, sign-in, audio calling, video calling. What will be the Sprint Goal? "As part of this Sprint, we want to have a user authentication and sending/receiving messages and audio and video calling feature." One liner or two liner.

Now, you have taken this work, four works. You have a Sprint Goal set. Now, January 19th, you have started the Sprint. After the Sprint Planning, we start the Sprint. Now, January 19th to February 2nd, what you'll be doing? You will have to complete all the work and you have to achieve the Sprint Goal. What is the purpose of a Daily Standup? Daily, the team will be coming and seeing, "Hey, are we on track to achieving the Sprint Goal? Are we lagging? Are we leading? Is there any blocker?" Exactly what they will be... any blocker you are facing, the team will be discussing in the Daily Scrum. This is the second event. This is the third event. Sprint was one event. Sprint Planning another. Daily Scrum is the third event. In the Daily Scrum, developers are mandatory. Scrum Master and PO are optional. But in most of the organization, 99% of the cases, the Scrum Master facilitates that call. Correct? Now, that is time-boxed to 15 minutes.

Now, for example, they will be doing this. Now, at the end of the day, daily they will have a Daily Scrum. On the last day or the second last day, February 2nd, the Sprint is getting closed. Now, they'll be completing the work. Obviously, you'll have the... obviously, if they will be completing the work, there will be an Increment. Increment means initially, the sign-up feature was not there; now, sign-up feature is there. Plus one. Sign-in is not there; another increment. Sending/receiving message, audio calling, video calling... all this Increment will happen. Now, who is building this? The Scrum Team. For whom? The business. So, whatever they have built, they will have a review with the business stakeholders in a Sprint Review. The Scrum Team, business stakeholders join the call, and they will review your working software or your Increment. And based on the review, might be they can have some feedback. For example, sign-in... I gave the example: they said initially, "Hey, we want sign-in using mobile number and OTP." But later on, while reviewing, the business comes up with the idea, "Hey, can you have the email ID and OTP option also?" Or whatever you build, for example, they have some other enhancement idea, "Hey, UI/UX design, can you put this button at that place?" Anything. Those things will be taken as a new requirement. We will be adding into the Product Backlog, correct? And again, the next Sprint will start on February 3rd. Again, other work will be taking the same fashion. And whatever the business, whatever the team bandwidth is there, accordingly, we'll be repeating the same Sprint.

In the last, on the last day of the Sprint, we'll have a Retrospective. Atma Chintan Shivir. Where the team will be introspecting: "What went wrong in the Sprint? How can you improve?" And we'll come up with Action Items. Like, "Hey, the team was not familiar with JIRA; they were not able to move the ticket on the right time." "Hey, JIRA training." That can be one action item. JIRA... Whatever the action item comes, will come to the Sprint Backlog just for the tracking purpose. And the same cycle will keep repeating. Once one Sprint gets ended, the next day again another Sprint will start. Again, two weeks. Again, this will end. Next day again, a Sprint will start. Same cycle will keep repeating.

So, what will happen? A few works you deliver in one Sprint. Again, another Sprint will start; a few works will deliver. Again, another Sprint will start; a few works will deliver. Again, another Sprint will start; a few works will deliver. What is happening? Then, in a product, there are a lot of items, one product goal, and every Sprint will be delivering some items. So, we will have a Sprint Goal. So, multiple Sprint Goals together lead to one Product Goal. That's what we learned.

We also learned that what is the role of a Product Owner? Product Owner's role is to hold the vision of the product, owns the Product Backlog, gets to the business, gets the requirement from the business, all those things with the help of the BA. Scrum Master's role is to facilitate all the Scrum events: Sprint Planning, Daily Standup, Review, Retrospective. If the team has any problem, any blocker they are facing, the Scrum Master helps them in resolving the blockers. Scrum Master coaches them on the right implementation of Scrum. Like, it's a process. From start to end, there will be a process that has to happen. The Scrum Master makes sure that is happening. Scrum Master also publishes multiple Scrum Metrics which we'll be discussing in the future to the leadership team or the business on a need basis. And what are those metrics? We'll be discussing a lot, like burndown, burnup, velocity, capacity utilization, commitment reliability, defect leakage. There can be a lot, but we will be discussing defect leakage and many more. That is again a Scrum Master responsibility. Fifth, as a Scrum Master, will also be a part of the Agile CoE (Center of Excellence). Every company will have a community. Sometimes they say CoE, sometimes they say CoP (Community of Practice). What is the difference? No difference. As a Scrum Master, every company, they will have different, different names. As a Scrum Master, will also be a part of the Agile CoE, where lots of Scrum Masters will be, Agile Coaches, and all those parts. Like there will be a community where they come up with multiple improvement ideas, training schedules, rules, etc. And apart from this, there can be other responsibilities as well, which you'll be discussing later on. Clear? Scrum Master roles and responsibilities... you don't have to worry. That's why companies are paying them money, correct? Yes.

Next, we have Developers. Their accountability is to develop it, test it, because under the developers you can have actual developers, designers, testers. Their job is to make the Increment—produce the Increment by the end of the Sprint. And you also discussed by the end of every Sprint, we should have a minimum one Increment. Correct? This is what we discussed.

We also discussed: Out of these, these are the three accountabilities, five Scrum events: a Sprint (its duration can be one week, two weeks, three weeks, four weeks), Sprint Planning (another event, time-boxed to a maximum of 8 hours for a one-month Sprint, but in the real world, it happens for 1.5 to 2 hours, and happens on the first day of the Sprint), Daily Scrum (15 minutes time-boxed, real world it even goes beyond that, we'll discuss how to solve the problem, and who is mandatory? Developers; Scrum Master and PO are optional), and then we have a Sprint Review (a Scrum team, business stakeholders join, review the time-boxed to 4 hours for a one-month Sprint... for a two-week Sprint, you can have 1.5 to 2 hours), and Retrospective (time-boxed to 3 hours for a one-month Sprint, but here only the Scrum Team joins, and in the real world, it happens for one to 1.5 hours). So, five events.

And there are three artifacts: one is the Product Backlog, second is the Sprint Backlog, and third is the Increment. How every artifact will have a commitment: Product Backlog has a commitment called Product Goal. A Sprint Backlog has a commitment called a Sprint Goal. And Increment has a commitment called Definition of Done (which we'll be discussing). The three artifacts and everyone will have a commitment. So, and that is called the 3-5-3 rule of Scrum.

________________________________

Recap of Scrum Team Structure and Process

This is what we discussed. We also discussed other questions of the people: how the Scrum Team looks like. I have explained what are the three accountabilities and how this team gets formed. There will be different, different names of the team. And now, roles have been changed to accountability. Development Team is no more a term; we call Developers. And we get the roster from the leadership team based on the skill set. They decide the project based on the project and all this, and you have to accordingly function. And you also discussed Scrum suggests you should have 10 or less than 10 people in a Scrum Team because there will be more collaboration, and all... But in the real world, you can find anything. This is should have, not mandatory.

And then you also discussed: there is a Scrum Team, and sometime they call it a Squad. This term is not covered with the Scrum Guide. Only Scrum Guide is the source of truth. Apart from this, nothing is a source of truth. Making sense?

Otherwise, Scrum Team... and we also discussed nowadays there is a concept called Pod structure. Where they are aligning every team in such a way that they have equal team members... like same, for example, 10 team members, 12 team members—equal team members and equal skill set also. Why? Why are they doing it? For example, in a Pod, there are five teams: Team number one, Team number two, Team number three, Team number four, Team number five. What they will do? Every team, they will keep equal 10 members, 10 members, 10 members, 10, 10, 10, or for example, they want to keep 12 members, 12 members, 12 members, 12 members, 12 members. Plus, those 12 members also, they will keep one lead who has all that much skill set, test lead, and that means for example, four developers. This team, this team will also have four developers, four developers. And their skill set kind of also be the same because they want to compare them on their performances. Otherwise, what will happen? If one team has 12 members, one team has 10 members, one team has 8 members, do you think we'll be able to compare? No, because they want to compare them on their performances. And what is performance? All is Scrum Metrics: "Hey, how much... how much they are delivering the work?" And all those things we'll be discussing. So, three concepts: Scrum Team, Squad (is a team), Pod structure (is also a Pod where there can be multiple Scrum Teams), but they have the same team size, same skill set so that they can compare based on performance—how much work they are able to deliver, how much defect is coming, what you are doing on the defect improvement, and there are a lot of factors. Making sense?

But one thing you have to remember: at the end of every Sprint, at the end of every Sprint, we should have minimum one Increment. You remember this example? Minimum Scrum suggests you should have minimum... See here, the example you have taken, we took four functionalities here, so you can have four increments also. But what Scrum suggests? Minimum one Increment you should have at least one working feature. You remember the Agile Manifesto: "Working feature over comprehensive documentation." Here, "Working Software over comprehensive documentation." Where is it? If you go to the four principles, if you go down here, so at least minimum one Increment will be there, one working software will be there so that the business can review it and you can get those feedback. What Scrum suggests? Making sense?

So, how the Scrum Team looks like? Everyone understood? Questions, please.

________________________________

Final Summary and Next Steps

Yeah, one last question... maybe not relevant at this point of time... so, how many teams or the products the Scrum Master works in parallel? Only one or more? Very good question, very good question, guys. Guys, guys, guys, here again, what I have just told two to three lines, I have told, and I will answer you in this question. First thing, I told: one Scrum Team will have one Scrum Master, one Product Owner, and the remaining people will be called as Developers. Correct? That is what I have told. Everyone agree with me? Yes. That doesn't mean that a Scrum Master will be handling only one team, correct? No. Both lines are different. So, if you go to the real world, you'll find Scrum Masters are handling one... a Scrum Master, for example, Ashutosh, a Scrum Master can be handling one team also. I have seen two teams also. I have seen some people handling three teams also, four teams also, and somewhere down the line, I have heard that they are handling six teams also. It depends on the organization. But I'll guide you: if they ask you in the interview, "How many teams are you going to handle?" you have to say two. But there are only 8 hours in 8 hours; how can anyone handle six projects in a company? Ask companies how they're making them handle. They want you to kind of... like they're paying you much. They're giving you... Your question is correct: "Hey, how come they will handle?" Correct. Your question is 100% correct. That is wrong because they will not be able to focus. They will only be taking the calls, even if they will be available for all those calls or not. But I have heard this, and it happens in the real world. Mostly, you have to say two teams. Clear? Yes.

Ranjit, thank you. My question is, as you mentioned, the team should play multiple roles... team should play multiple roles? Yes. Under the team, there can be multiple people. Everyone's role will be different, but their accountabilities will be only three: one is Scrum Master, one is PO, and the remaining people are developers. But their roles are different. Yes. So, a developer can also handle the role of a Scrum Master if he has understanding? Or yes. This line you remember: one team, one Scrum Master, so that means if this person is a developer and a Scrum Master also, for example, Fose, and this person is again, for example, this person is for example, Dev, correct? Yes. And this person is again, for example, this person is for example, QA, and these are the QA, QA tester, or QA lead, QA, or tester, whatever you name it. For example, one BA, for example, you want... this person is a BA. If designing is part of your team, for example, this is a designer, for example. Correct? For example, what Scrum says is that Scrum has only three accountabilities only. Three accountabilities. Scrum has. And what are those accountabilities? One accountability is this... this is Accountability number one: Scrum Master is one accountability, as per Scrum. This is Accountability number two. PO is another. The remaining people all together they might have different different roles. The remaining people all together as per Scrum are called as Developers. These all three are called as the third accountability called as Developers, not Development Team. Now, initially, there is some nomenclature change. Initially, in the last Scrum Guide, they used to say roles; now they say accountabilities. Initially, if you come to me, two or three years back or three years back of the training, I could have said, "Hey, now Scrum has three roles." Now, they have changed the name. That's why I'm telling the accountabilities. Developers. Initially, they were called as a Development Team. Now they are called as Developers. So, I'm using the right name, so you please start using the right name. They are called Developers. All these together are called as Developers, but they will have their different, different roles.

Now, how do we form the Scrum Team? First question: How do we form the Scrum Team? What happens here? Mostly what the Scrum Guide suggests is that the team should be self-managed, self-organized, and all this. What happens? You will get a roster whenever you work as a Scrum in an organization. You'll get a roster from your top management team, from top leadership team, based on the project, whatever the skill set needed. What they do? They kind of include in one team, and you'll just get the information like, "Others say you are the Scrum Master of this team, Ashutosh. Lizzy will be the PO, and these people will be..." They identify who has what kind of a skill set and whatever is needed to build the project, correct? And there can be multiple Scrum Teams. And how they keep the nomenclature? One team can be named as Lions, for example. The another team they form can be Tigers. Another team can be Innovators. Fourth team can be... these are the Scrum Team names. In the real world, fourth team can be Challengers. Fifth team can be, you know, Masterminds. Sixth team can be, you know, Antilops, Balu Beers... any name they can give. Are you getting my point? And every team will have some... Some team can have 10 members, some team can have... Real... if you see, some teams I have seen they have 15 members also, which is... Scrum suggests you should have more than... what Scrum suggests is you should have 10 or less people in a Scrum Team. Why? Because the collaboration will be more. More people, collaboration is less. Because the collaboration will be more. This is what Scrum suggests. But in the real world, if you go, I have seen in the real world and practical world there are teams which have 15 members also, there are teams which have 20 members also, there are teams which have 16 members also. All these you'll be seeing it. And you'll obviously be seeing less than 10 also. Making sense? But whenever... tell me, less than 10... 10 means 7 to 10 or any... what is the like? Less than 10 means 9, 8, 7, 6, 5... all like they form the team, but every team... for example, there is a five-member team. This... there can be one SM, one PO, one... one developer or two developers, one tester also. There can be... like they form the team... please mute yourself. Okay. So, there will be a 10... Scrum suggests there should be 10 or less than 10. But they can have more team members... less... less team members? No, kind of a... no strict rules, but in a practical world, you have seen 16, 8... but whatever the team you are forming, that should be a cross-functional team. What do you mean by cross-functional team? Should have enough skill set, people to build the Increment out of a Sprint. It's not like, "Hey, you're having every time dependency that, 'Hey, whatever is needed to build the Increment, you should have those members in the team.'" For example, Indian Cricket Team is a great example of a cross-functional team. We will have the bowlers, we will have the batsmen, we will have the all-rounders. Hardik Pandya, we have the spinner Ravi Chandra Ashwin. We have the batsman Virat Kohli, all those things. We have a bowler and all this. Even if one person is not there, for example, Virat Kohli, other people can bat and win the match for Team India. If any all-rounder is not there, other person can come and win. That is called cross-functional. Cross-functional means you should have enough skill. The team together should have enough skill to build the Increment. So, whenever they form a team, they make sure whatever the project needed, those kinds of skills the developers have. Are you getting my point? And how will you get to know? They will send you the roster. In the roster, what will happen? Roster, every team will have these details. "This team, Lions team." The moment you get, Ashutosh will get to know that "I as a Scrum Master will work with these people." Whatever the positive... Tiger team, for example, Sameer. That person will work in the same team. Member size... their size will be more... their size will be more. And sometime this Scrum Team, if you go to the interview, sometime this Scrum Team is called a Squad also. It's not like... "Hey, what you're telling?" What is a Squad? Indian Cricket Squad. You have heard different names. And nowadays there is another concept called Pod structure. What they're doing in the Pod? No... every team, they're aligning every team in such a way that they have equal team members. Like, same, for example, 10 team members, 12 team members—equal team members, and equal skill set also. Why? Why are they doing it? For example, in a Pod, there are five teams: Team number one, Team number two, Team number three, Team number four, Team number five. What they will do? Every team, they will keep equal 10 members, 10 members, 10 members, 10, 10, 10, or for example, they want to keep 12 members, 12 members, 12 members, 12 members, 12 members. Plus, those 12 members also, they will keep one lead who has all that much skill set, test lead. And that means for example, four developers. This team, this team will also have four developers, four developers. And their skill set kind of also be the same because they want to compare them on their performances. Otherwise, what will happen? If one team has 12 members, one team has 10 members, one team has 8 members, do you think we'll be able to compare? No, because they want to compare them on their performances. And what is performance? All is Scrum Metrics: "Hey, how much... how much they are delivering the work?" And all those things we'll be discussing. So, three concepts: Scrum Team, Squad (is a team), Pod structure (is also a Pod where there can be multiple Scrum Teams), but they have the same team size, same skill set so that they can compare based on performance—how much work they are able to deliver, how much defect is coming, what you are doing on the defect improvement, and there are a lot of factors. Making sense?

But one thing you have to remember: at the end of every Sprint, at the end of every Sprint, we should have minimum one Increment. You remember this example? Minimum Scrum suggests you should have minimum... See here, the example you have taken, we took four functionalities here, so you can have four increments also. But what Scrum suggests? Minimum one Increment you should have at least one working feature. You remember the Agile Manifesto: "Working feature over comprehensive documentation." Here, "Working Software over comprehensive documentation." Where is it? If you go to the four principles, if you go down here, so at least minimum one Increment will be there, one working software will be there so that the business can review it and you can get those feedback. What Scrum suggests? Making sense?

So, how the Scrum Team looks like? Everyone understood? Questions, please.

________________________________

Final Wrap-up and Assignments

Yes. Ranjit, thank you. My question is, as you mentioned, the team should play multiple roles... team should play multiple roles? Yes. Under the team, there can be multiple people. Everyone's role will be different, but their accountabilities will be only three: one is Scrum Master, one is PO, and the remaining people are developers. But their roles are different. Yes. So, a developer can also handle the role of a Scrum Master if he has understanding? Or yes. This line you remember: one team, one Scrum Master, so that means if this person is a developer and a Scrum Master also, for example, Fose, and this person is again, for example, this person is for example, Dev, correct? Yes. And this person is again, for example, this person is for example, QA, and these are the QA, QA tester, or QA lead, QA, or tester, whatever you name it. For example, one BA, for example, you want... this person is a BA. If designing is part of your team, for example, this is a designer, for example. Correct? For example, what Scrum says is that Scrum has only three accountabilities only. Three accountabilities. Scrum has. And what are those accountabilities? One accountability is this... this is Accountability number one: Scrum Master is one accountability, as per Scrum. This is Accountability number two. PO is another. The remaining people all together they might have different different roles. The remaining people all together as per Scrum are called as Developers. These all three are called as the third accountability called as Developers, not Development Team. Now, initially, there is some nomenclature change. Initially, in the last Scrum Guide, they used to say roles; now they say accountabilities. Initially, if you come to me, two or three years back or three years back of the training, I could have said, "Hey, now Scrum has three roles." Now, they have changed the name. That's why I'm telling the accountabilities. Developers. Initially, they were called as a Development Team. Now they are called as Developers. So, I'm using the right name, so you please start using the right name. They are called Developers. All these together are called as Developers, but they will have their different, different roles.

Now, how do we form the Scrum Team? First question: How do we form the Scrum Team? What happens here? Mostly what the Scrum Guide suggests is that the team should be self-managed, self-organized, and all this. What happens? You will get a roster whenever you work as a Scrum in an organization. You'll get a roster from your top management team, from top leadership team, based on the project, whatever the skill set needed. What they do? They kind of include in one team, and you'll just get the information like, "Others say you are the Scrum Master of this team, Ashutosh. Lizzy will be the PO, and these people will be..." They identify who has what kind of a skill set and whatever is needed to build the project, correct? And there can be multiple Scrum Teams. And how they keep the nomenclature? One team can be named as Lions, for example. The another team they form can be Tigers. Another team can be Innovators. Fourth team can be... these are the Scrum Team names. In the real world, fourth team can be Challengers. Fifth team can be, you know, Masterminds. Sixth team can be, you know, Antilops, Balu Beers... any name they can give. Are you getting my point? And every team will have some... Some team can have 10 members, some team can have... Real... if you see, some teams I have seen they have 15 members also, which is... Scrum suggests you should have more than... what Scrum suggests is you should have 10 or less people in a Scrum Team. Why? Because the collaboration will be more. More people, collaboration is less. Because the collaboration will be more. This is what Scrum suggests. But in the real world, if you go, I have seen in the real world and practical world there are teams which have 15 members also, there are teams which have 20 members also, there are teams which have 16 members also. All these you'll be seeing it. And you'll obviously be seeing less than 10 also. Making sense? But whenever... tell me, less than 10... 10 means 7 to 10 or any... what is the like? Less than 10 means 9, 8, 7, 6, 5... all like they form the team, but every team... for example, there is a five-member team. This... there can be one SM, one PO, one... one developer or two developers, one tester also. There can be... like they form the team... please mute yourself. Okay. So, there will be a 10... Scrum suggests there should be 10 or less than 10. But they can have more team members... less... less team members? No, kind of a... no strict rules, but in a practical world, you have seen 16, 8... but whatever the team you are forming, that should be a cross-functional team. What do you mean by cross-functional team? Should have enough skill set, people to build the Increment out of a Sprint. It's not like, "Hey, you're having every time dependency that, 'Hey, whatever is needed to build the Increment, you should have those members in the team.'" For example, Indian Cricket Team is a great example of a cross-functional team. We will have the bowlers, we will have the batsmen, we will have the all-rounders. Hardik Pandya, we have the spinner Ravi Chandra Ashwin. We have the batsman Virat Kohli, all those things. We have a bowler and all this. Even if one person is not there, for example, Virat Kohli, other people can bat and win the match for Team India. If any all-rounder is not there, other person can come and win. That is called cross-functional. Cross-functional means you should have enough skill. The team together should have enough skill to build the Increment. So, whenever they form a team, they make sure whatever the project needed, those kinds of skills the developers have. Are you getting my point? And how will you get to know? They will send you the roster. In the roster, what will happen? Roster, every team will have these details. "This team, Lions team." The moment you get, Ashutosh will get to know that "I as a Scrum Master will work with these people." Whatever the positive... Tiger team, for example, Sameer. That person will work in the same team. Member size... their size will be more... their size will be more. And sometime this Scrum Team, if you go to the interview, sometime this Scrum Team is called a Squad also. It's not like... "Hey, what you're telling?" What is a Squad? Indian Cricket Squad. You have heard different names. And nowadays there is another concept called Pod structure. What they're doing in the Pod? No... every team, they're aligning every team in such a way that they have equal team members... like same, for example, 10 team members, 12 team members—equal team members, and equal skill set also. Why? Why are they doing it? For example, in a Pod, there are five teams: Team number one, Team number two, Team number three, Team number four, Team number five. What they will do? Every team, they will keep equal 10 members, 10 members, 10 members, 10, 10, 10, or for example, they want to keep 12 members, 12 members, 12 members, 12 members, 12 members. Plus, those 12 members also, they will keep one lead who has all that much skill set, test lead. And that means for example, four developers. This team, this team will also have four developers, four developers. And their skill set kind of also be the same because they want to compare them on their performances. Otherwise, what will happen? If one team has 12 members, one team has 10 members, one team has 8 members, do you think we'll be able to compare? No, because they want to compare them on their performances. And what is performance? All is Scrum Metrics: "Hey, how much... how much they are delivering the work?" And all those things we'll be discussing. So, three concepts: Scrum Team, Squad (is a team), Pod structure (is also a Pod where there can be multiple Scrum Teams), but they have the same team size, same skill set so that they can compare based on performance—how much work they are able to deliver, how much defect is coming, what you are doing on the defect improvement, and there are a lot of factors. Making sense?

But one thing you have to remember: at the end of every Sprint, at the end of every Sprint, we should have minimum one Increment. You remember this example? Minimum Scrum suggests you should have minimum... See here, the example you have taken, we took four functionalities here, so you can have four increments also. But what Scrum suggests? Minimum one Increment you should have at least one working feature. You remember the Agile Manifesto: "Working feature over comprehensive documentation." Here, "Working Software over comprehensive documentation." Where is it? If you go to the four principles, if you go down here, so at least minimum one Increment will be there, one working software will be there so that the business can review it and you can get those feedback. What Scrum suggests? Making sense?

So, how the Scrum Team looks like? Everyone understood? Questions, please.

________________________________

Final Summary of Today's Class

So, this was the summary of today's class. Whatever we discussed: First, we discussed the interview questions related to SDLC and all this. Then we came to the Scrum basics. The next 20 classes, we are going to build upon the same here. What is the Product Goal? What exactly it looks like? How the Product Owner gets the requirement from the business? There will be one class there. There will be two to three classes here: how the Backlog Refinement happens, how the Capacity Planning happens. Because see, even the developer's Sprint Backlog... developers are taking the work from the Product Backlog to the Sprint Backlog. Today, we just considered they will be taking four works or five works. On what basis are they deciding they will be taking four works, five works? There will be concepts of capacity, there will be concept of velocity, there will be concept of how they're prioritizing the Product Backlog—which items the business wants first. All those techniques... Product Backlog Prioritization. When this whatever the requirements they are taking, when this requirement will get groomed? Backlog Refinement. There can be a number of questions: how the estimation happens, User Story estimation—all those. There are a lot of topics in between; those we'll be discussing. So, there will be around 20 classes on this.

Now, what we learned today: Under Agile, you have a framework called Scrum. So, whatever Agile does, Scrum also has to follow. Agile has four values, twelve principles; even Scrum, because Scrum comes under Agile, Scrum has to abide by those values and principles. That means Scrum also has to deliver the work iteratively and incrementally. Iterative means time by time, like Sprint by Sprint, and incremental means one feature by another—sign up, sending/receiving, and all that. That's what Scrum is also doing.

What you understood is that Scrum will have three accountabilities: one is Product Owner, second is Scrum Master, and third is called Developers (not Development Team, because the nomenclature has changed). Five Events: one will be the Sprint itself, then Sprint Planning, a Sprint can be one week, two weeks, three weeks, four weeks. Sprint Planning happens on the first day of the Sprint, for example, January 19th to February 2nd. Daily Scrum daily. Sprint Review in the last, whenever you are able to build the Increment. And Retrospective, kind of Atma Chintan Shivir, where the team will be introspecting: what exactly... how this Sprint went, what went well, what didn't go well, how can we improve? A lot of things.

Now, what happens? For example, let's take the example of WhatsApp, and you have to build the WhatsApp using the framework called Scrum. How will you be building it? WhatsApp as a product will have one Product Owner. Every product will have a Product Goal. Product Goal means what exactly you want to achieve out of the product. For example, as part of this product, we want to have an end-to-end communication from users sitting across the globe through various means such as sending/receiving messages, audio calling, video calling, and get a better experience to the user. Any product goal can have.

Now, in order to achieve that Product Goal, under this product, you can have a multiple requirement. Product Owner with the help of a BA reaches out to the business. "Hey BA, tell me what is the requirement? What exactly you want us to build?" They will give all the requirements. "Hey, we want users should sign up, sign in, sending/receiving messages, audio calling, video calling, blue tick." There can be a lot of requirements. Whatever the requirements will come, the Product Owner and Business Analyst will be grooming, adding all those requirements in the Product Backlog. What is the Product Backlog? A place where all the requirements will be there. Correct? Simple language. There can be... and this is dynamic. Dynamic means business, because you are working in Agile, all the product items will not be... all the Product Backlog Items will not go in one call. Business might keep adding the product during the Sprint Review also if there is any enhancement. They will keep adding the product again and again. So, this is dynamic; this will keep changing, keep having additions, keep having removals. What if the business told earlier, "Hey, we want this," but later on, "Hey, we don't want this?" So, this is dynamic; this is not fixed. Now, Product Owner owns the Product Backlog, holds the vision of the product, gets the requirement, every single thing. And the BA is a supporting assistant to get help them in gathering the requirement. Clear?

Once that gets done here, now you have a lot of requirements here. Now you have to build it. What Scrum suggests? If you're building using the Scrum, you have to build Sprint by Sprint. A Sprint is a duration; it can be one week, two weeks, three weeks, four weeks. I'm just assuming two weeks for example. This is starting on January 19th and closing on February 2nd. So, what will happen? On January 19th, the first day of the Sprint, we'll have the Sprint Planning call. During the Sprint Planning call, the team will be discussing what items they can take from the Product Backlog to the Sprint Backlog. Correct? But there are a lot of factors here: "Hey, what the business wants first? Second, is this groomed?" Groomed means, "Do the developers know what exactly they have to do?" Third, "How much work the developer can take," because they have only so much time, and they are only, for example, 10 members as a Scrum Team. There can be a lot of questions here; we'll be discussing those questions later on. For example, developers can take only four works. And I am just assuming that those first four works are prioritized, and this is what the business wants. During the Sprint Planning, we'll be taking those works from the Product Backlog to the Sprint Backlog.

Once we take it, what is the job of the Scrum Master? The Scrum Master will be facilitating this call during the Sprint Planning. Now, for example, those four works we have taken. "Hey, what exactly you want to achieve out of this?" That will be the Sprint Goal. "What exactly you want to achieve?" For example, sign-up, sign-in, audio calling, video calling. What will be the Sprint Goal? "As part of this Sprint, we want to deliver user authentication and sending/receiving messages and audio and video calling feature." One liner or two liner.

Now, you have taken this work, four works. You have a Sprint Goal set. Now, January 19th, you have started the Sprint. After the Sprint Planning, we start the Sprint. Now, January 19th to February 2nd, what you'll be doing? You will have to complete all the work and you have to achieve the Sprint Goal. What is the purpose of a Daily Standup? Daily, the team will be coming and seeing, "Hey, are we on track to achieving the Sprint Goal? Are we lagging? Are we leading? Is there any blocker?" Exactly what they will be... any blocker you are facing, the team will be discussing in the Daily Scrum. This is the second event. This is the third event. Sprint was one event. Sprint Planning another. Daily Scrum is the third event. In the Daily Scrum, developers are mandatory. Scrum Master and PO are optional. But in most of the organizations, 99% of the cases, the Scrum Master facilitates that call. Correct? Now, that is time-boxed to 15 minutes.

Now, for example, they will be doing this. Now, at the end of the day, daily they will have a Daily Scrum. On the last day or the second last day, February 2nd, the Sprint is getting closed. Now, they'll be completing the work, correct? Yes. There are four items; they will be completing the work. Those completed items will be called an Increment. Increment means initially, the sign-up feature was not there; now, sign-up feature is there. Plus one. Sign-in was not there; sign-in is there. Plus one. Audio calling was not there; audio calling is there. Plus one. Sending/receiving message... All this increment will happen. Now, who is building this? The Scrum Team. For whom? The business. So, whatever they have built, they will have a review with the business stakeholders in a Sprint Review. The Scrum Team, business stakeholders join the call, and they will review your working software or your Increment. And based on the review, might be they can have some feedback. For example, sign-in... I gave the example, they said initially, "Hey, we want sign-in using mobile number and OTP." But later on, while reviewing, the business comes up with the idea, "Hey, can you have the email ID and OTP option also?" Or whatever you build, for example, they have some other enhancement idea, "Hey, UI/UX design, can you put this button at that place?" Anything. Those things will be taken as a new requirement. We will be adding into the Product Backlog, correct? And again, the next Sprint will start on February 3rd. Again, other work will be taking the same fashion. And whatever the business, whatever the team bandwidth is there, accordingly, we'll be repeating the same Sprint.

In the last, on the last day of the Sprint, we'll have a Retrospective. Atma Chintan Shivir. Where the team will be introspecting: "What went well in this Sprint? What didn't go well? How can you improve?" And we'll come up with Action Items. Like, "Hey, the team was not familiar with JIRA; they were not able to move the ticket on the right time." "Hey, JIRA training." That can be one action item. JIRA... Whatever the action item comes, will come to the Sprint Backlog just to as a tracker. And the same cycle will keep repeating. Once one Sprint gets ended, the next day again another Sprint will start. Again, two weeks. Again, this will end. Next day again, a Sprint will start. Same cycle will keep repeating.

So, what will happen? A few works you deliver in one Sprint. Again, another Sprint will start; a few works will deliver. Again, another Sprint will start; a few works will deliver. Again, another Sprint will start; a few works will deliver. What is happening? Then, in a product, there are a lot of items, one product goal, and every Sprint will be delivering some items. So, we will have a Sprint Goal. So, multiple Sprint Goals together lead to one Product Goal. That's what we learned.

We also learned that what is the role of a Product Owner? Product Owner's role is to hold the vision of the product, owns the Product Backlog, go to the business, get the requirement from the business, all those things with the help of the BA. Scrum Master's role is to facilitate all the Scrum events: Sprint Planning, Daily Standup, Review, Retrospective. If the team has any problem, any blocker they are facing, the Scrum Master helps them in resolving the blockers. Scrum Master coaches them on the right implementation of Scrum. Like, it's a process. From start to end, there will be a process that Scrum suggests, correct? The Scrum Master makes sure that is happening. Scrum Master also publishes multiple Scrum Metrics which we'll be discussing in the future to the leadership team or the business on a need basis. And what are those metrics? We'll be discussing a lot, like burndown, burnup, velocity, capacity utilization, commitment reliability, defect leakage. There can be a lot, but we will be discussing defect leakage and many more. That is again a Scrum Master responsibility. Fifth, as a Scrum Master, will also be a part of the Agile CoE (Center of Excellence). Every company will have a community. Sometimes they say CoE, sometimes they say CoP (Community of Practice). What is the difference? No difference. As a Scrum Master, every company, they will have different, different names. As a Scrum Master, will also be a part of the Agile CoE, where lots of Scrum Masters will be, Agile Coaches, and all those parts. Like there will be a community where they come up with multiple improvement ideas, training schedules, rules, etc. And apart from this, there can be other responsibilities as well, which you'll be discussing later on. Clear? Scrum Master roles and responsibilities... you don't have to worry. That's why companies are paying them money, correct? Yes.

Next, we have Developers. Their accountability is to develop it, test it, because under the developers you can have actual developers, designers, testers. Their job is to make the Increment—produce the Increment by the end of the Sprint. And you also discussed by the end of every Sprint, we should have a minimum one Increment. Correct? This is what we discussed.

We also discussed: Out of these, these are the three accountabilities, five Scrum events: a Sprint (its duration can be one week, two weeks, three weeks, four weeks), Sprint Planning (another event, time-boxed to a maximum of 8 hours for a one-month Sprint, but in the real world, it happens for 1.5 to 2 hours, and happens on the first day of the Sprint), Daily Scrum (15 minutes time-boxed, real world it even goes beyond that, we'll discuss how to solve the problem, and who is mandatory? Developers; Scrum Master and PO are optional), and then we have a Sprint Review (a Scrum team, business stakeholders join, review the time-boxed to 4 hours for a one-month Sprint... for a two-week Sprint, you can have 1.5 to 2 hours), and Retrospective (time-boxed to 3 hours for a one-month Sprint, but here only the Scrum Team joins, and in the real world, it happens for one to 1.5 hours). So, five events.

And there are three artifacts: one is the Product Backlog, second is the Sprint Backlog, and third is the Increment. How every artifact will have a commitment: Product Backlog has a commitment called Product Goal. A Sprint Backlog has a commitment called a Sprint Goal. And Increment has a commitment called Definition of Done (which we'll be discussing). The three artifacts and everyone will have a commitment. So, and that is called the 3-5-3 rule of Scrum.

________________________________

Final Review and Next Class Preview

This is what we discussed. We also discussed other questions of the people: how the Scrum Team looks like. I have explained what are the three accountabilities and how this team gets formed. There will be different, different names of the team. And now, roles have been changed to accountability. Development Team is no more a term; we call Developers. And we get the roster from the leadership team based on the skill set. They decide the project based on the project and all this, and you have to accordingly function. And you also discussed Scrum suggests you should have 10 or less than 10 people in a Scrum Team because there will be more collaboration, and all... But in the real world, you can find anything. This is should have, not mandatory.

And then you also discussed: there is a Scrum Team, and sometime they call it a Squad. This term is not covered with the Scrum Guide. Only Scrum Guide is the source of truth. Apart from this, nothing is a source of truth. Making sense?

Otherwise, Scrum Team... and we also discussed nowadays there is a concept called Pod structure. Where they are aligning every team in such a way that they have equal team members... like same, for example, 10 team members, 12 team members—equal team members, and equal skill set also. Why? Why are they doing it? For example, in a Pod, there are five teams: Team number one, Team number two, Team number three, Team number four, Team number five. What they will do? Every team, they will keep equal 10 members, 10 members, 10 members, 10, 10, 10, or for example, they want to keep 12 members, 12 members, 12 members, 12 members, 12 members. Plus, those 12 members also, they will keep one lead who has all that much skill set, test lead. And that means for example, four developers. This team, this team will also have four developers, four developers. And their skill set kind of also be the same because they want to compare them on their performances. Otherwise, what will happen? If one team has 12 members, one team has 10 members, one team has 8 members, do you think we'll be able to compare? No, because they want to compare them on their performances. And what is performance? All is Scrum Metrics: "Hey, how much... how much they are delivering the work?" And all those things we'll be discussing. So, three concepts: Scrum Team, Squad (is a team), Pod structure (is also a Pod where there can be multiple Scrum Teams), but they have the same team size, same skill set so that they can compare based on performance—how much work they are able to deliver, how much defect is coming, what you are doing on the defect improvement, and there are a lot of factors. Making sense?

But one thing you have to remember: at the end of every Sprint, at the end of every Sprint, we should have minimum one Increment. You remember this example? Minimum Scrum suggests you should have minimum... See here, the example you have taken, we took four functionalities here, so you can have four increments also. But what Scrum suggests? Minimum one Increment you should have at least one working feature. You remember the Agile Manifesto: "Working feature over comprehensive documentation." Here, "Working Software over comprehensive documentation." Where is it? If you go to the four principles, if you go down here, so at least minimum one Increment will be there, one working software will be there so that the business can review it and you can get those feedback. What Scrum suggests? Making sense?

So, how the Scrum Team looks like? Everyone understood? Questions, please.

Ranjit asked: "As you mentioned, team should play multiple roles..." Yes. "One product will have one Product Owner, one Product Goal, but under the Product Backlog, there can be a number of requirements, and to develop this product or achieve the Product Goal, the team will be working in multiple Sprints, and every Sprint will have its own Sprint Goal." That means multiple Sprint Goals together should lead to one Product Goal. Yes or no? Clear? Yes.

This is what we discussed. Once you come to the next class, we'll be building one product, a to-do list app, and how a Scrum builds that product, how the Product Backlog looks like, how the Sprint Backlog looks like. That whatever we discussed, we'll be explaining in the next level way. All those calls who attended today, I just gave you the basic, and then we'll be seeing how the Product Goal looks like, how the Sprint Goal looks like, all those we'll be seeing in the next class.

Apart from this, in the notepad also, we discussed a few things: what are the time-boxes and all those things. Here, whatever the questions you guys asked here: Scrum Master roles and responsibilities, what Product Owner does, what are the different time-boxed events—these things we discussed. This was the summary of today's class. Any question before closing the call?

________________________________

Assignments and Closing Remarks

This assignment question... one person, can you take this and make sure that... can you paste in the group fast? These questions are the next... See, the next class assignment is this, plus the Udemy course completion 100%. Everyone promised. Everyone told, "No, 26 or 25 something kind of." Course completion 100%. This has to be done, and how will I believe? If you submit the certification, that will be there. Guys, those who will start assuming, "I know things," you are gone. I'm again telling you, you might be knowing a little bit about Scrum, but the moment you start assuming, "I know things," you are gone because what you know but whatever is coming from my mouth is gold. How much learning you have in this three-hour class, you know now so much. But if you start assuming, "I know a little bit," you are gone. Please don't assume. Listen to the class very carefully. To crack the interview, a small, small thing is needed. Make sure you are doing it. Don't assume anything. You don't know. That's why you are here. You are not able to crack the job, that's why you are here. You have a problem, that's why you paid the money, correct? Make sure you are not living in a false paradise. Work hard. Whatever I'm going to tell you.

So, this Udemy course 100% certification, and by Friday, I should not be sending the reminder. And the Scrum Guide with the right affirmations... I reach people's homes if they don't work hard. You should have at least one room for me. I'll be taking the class from there, and you should have to serve me dinner, breakfast, juice, and all this. Make sure I like this, okay? So, work hard. I'm literally going to a school. You have seen my positive side. Negative side, you'll see after a few classes if you don't work hard. Okay? Any other question before you... Lizzy, someone pasted here. Someone pasted in the group. Yes, yes, yes. Lizzy, oh, very basic question. Today you took notes on the Excel sheet. So, will that... I'll be... I'll be explaining. I'll be pasting this Excel sheet also. I'll be pasting the notepad also, and I will be uploading the recording also. Sure. Thank you so much. Very good. Yes, Ishwarya. I'll be asking the question after the class. It's like... of the... Yes. Samir, okay. Yes. This Udemy course is... I don't know. I'm not getting it for 500; it is showing me 4,000. Try... You don't have to do it for 4,000. Open with a different email ID. See, there are a lot of... open with different email IDs, and just... you know, no, don't follow the link. Just go and search here. See, I'll show you. Go here... Let me stop sharing. Go here and search here. For example, you go here, just search here. What is the course name? Tell me the course name: Agile. This one, this one... You just take the name. Don't... you don't even go through the link. One second. You don't even go through the link. Just go with this... you know... It is showing 3,999. What you have to do... I am following the link. Don't follow the link. Just go to a new browser like this. Just copy this and search on Google. For example, I'll go to the Incognito tab, a new Incognito window, and I'll search on Google. Different different probability you have to provide. And if not, you can wait for one day. They keep rising up and down. For example, here you go here... Udemy came. This is the course, correct? Yes. One second, one second, one second. If it will come like this, then great. If not like this, then you'll have to say 599. You saw this just now it was showing 3,999, correct? Yes. What I did: don't follow the link. Sometime, just take this, search on Google. You'll get it in 599. Got it, Samir? Okay. I'll try doing that. Great. Yes, anyone else have any question? Okay, work hard. Make yourself proud. This seven-day daily, you have to work for two hours a day, one hour a day, whatever you promised. Work agreement, don't forget it. Okay? Hope you guys liked the class. Okay. Thank you. Bye-bye. Bye-bye. Bye-bye. Take care. Night. Bye. Good night. Good night. Good night. Thanks all. Thank you. Thank you.