 So, first thing is that first question was about your project manager experience. Okay. And the sequence of events that you know, as a product, you have to when you've been asked that question, you have to consider that the main backbone of the project manager Okay, project planning and then project execution. Okay, two terms, you have to keep those in back of your mind to answer like, you know, next. So planning is What, what is the planning resource planning, as well as, you know, the project timeline planning resource planning. It's basically like, you know, checking out what resources needed, how many developer tester and all that those needed checking out their estimates from their respective, you know, stakeholders. Okay. And then jotting down those estimate and then based on those estimates usually, you know, you take and also like, when you're answering answer from your experience, like I did I took I did I, you know, from your experience that would be basically like you know, the right way to answer. So as you did gather that you need these much like this number of resources with that many hours needed for each resource and based on that you would develop it, you know, timeline of the project. Okay, and with the timeline you will put all that milestones with the each phase of that project. Okay, so preparing all and then you will work with the stakeholders and stakeholders and then again stakeholder for the project and the stakeholder for the requirement are different. Okay. Yeah. Stakeholder for the project and the stakeholder for requirements, they are different. Okay. They might be shared between, but they are different stakeholder of the for the project or who are the stakeholder for the project, who are the people who are funding that project. Okay, and who are basically interested to get that completed and though some of those stakeholder might be the business stakeholder, and if the project is impacting some of the, you know, architecture are changing bringing some big change then there might be technical stakeholders to Okay, so all those folks would be and then definitely they're the stakeholders who are going to provide the workforce for for the project. Okay, and from where you're getting the estimates. So as you get that all the information jotted down then you share with them. Okay, all right, this is what basically I got. So this would be like this is the number of resources I need and this is all the others and these are the estimates that basically resource resources cost and then this is the timeline and these are the milestones and all that so get that basically bring that all that visibility to stakeholders and then get everybody's consent and input if anybody has like any concern they can basically let you know that then and that is the planning part that before the execution start you are as a project manager doing that planning and and when that is done then basically you know you would acquire the resources definitely you know if it is a traditionally you are working in a traditional environment you will basically acquire a business analyst and then from the be a you will start be able to start working but as a project manager you will be having your like status meeting every week so updating the status managing the risk and all that you know stuff. So only that is what you will describe in your project manager role nothing about right I planning execution you have nothing to do with the requirements, you have nothing to do with anybody else role. I think I see the I see the mistake I think on project manager instead of project planning, I said requirements because exactly so that I see the mistake yeah all right so that's that's why you have to then you have performed two roles like as a project manager you work as a business analyst but don't mix up those roles. Yes, and you never basically work both two roles in a project. Yeah, you are either working as a business analyst either working as a project manager so if you're working on a, you know, and with the same company you might have like you know five projects to as a project manager three as a be a so that then that is a real life, you know scenario, but your role with the you know the project as when you're working as a project manager you just have to emphasize on that. Okay, don't mix up your be a role in it. Okay, so that is basically like you know and when you are talking about your be a role. So with the be a from the onboarding and how you did the stakeholder analysis little bit information on that and how you basically understood the project how you build your understanding. Okay, and that happened basically before the requirement and what you did what what you did before the requirement elicitation or requirement gathering activity and then how you gather and documented the requirement how you handle your stakeholder you address those questions and then when the requirement was done how you was working with the solution team to get that solution what documentation they prepared how you participated and how you as a be a help them emphasize on that and when then development start with the development team as a be a how you help the development team and what was your basically interaction with them and what you was doing when the development happening and then similarly like you know with the testing team, what you did focus on your role, like what you contributed and what you helped. Okay. Okay. They asked me a question like how do I help the development team. Okay, yeah, go ahead answer. How do I help the development team. I can be like, I schedule meetings with them to see how they are moving forward with the project and then make sure I answer all their questions if they have any questions. As a be a you did that or as a project manager you did that. No, that's not that's wrong. Okay, so as a be a usually like when the development starts if they the maximum that you do you schedule a meeting and go over your business requirement document with them go over the requirement that you have gathered so that they will be get familiarized with the what developing the team needs from you, you're a be a what they need the need to understand the requirements. Okay, so that's that's what they need your help with. Okay, because you wrote the requirement, so they, you would be the right person to help them understand to give them understanding what you do you go give them overview. Okay, that these are the requirement and this is this is and if they have any question about the requirement you give the get them the answer. Okay, that's all you do with the development team. Okay, okay, so is the project manager that goes through and see where they are with the project and how is it going. That's project manager invite everybody project manager invite everybody there are developer tester all all the team team members are either they like he invite or he she go to the teams like in individual to understand that you know, hey, what's going on and you know, where we are at and all that so that project manager have to do a status meeting, which includes all the stakeholders of the project manager. Okay, and that are the primary like a participant of that meeting and then optional or the team members like team member don't have to attend the status meeting until unless like asked by the project manager, they can be just like as a as an optional, but the project manager job is to keep that project status updated and see that if there is any risk to deliverables or timeline or any of the plan the project manager has, you know, drafted in the start if there is any like risk to that then addressing that risk and mitigating doing all those like stuff that is project manager job. Yeah, make sense. Yes, that makes sense. Okay, so that's what you have to basically explain. Yeah. Okay, so right now, there is like, and that's why I usually ask that you know, write your response. And then basically send it to me. And if there will be anything wrong with that response or any sequence of event is missing, I can certainly like help you with an identified and then practice that response and don't lose the basically like the sequence of events. Okay. Okay, because if you are losing if you're doing something that will be kind of a mistake and that will mess up. Okay. Okay. All right, so today we are gonna basically quickly go over our BA role in traditional environment, and then role, BA role in agile environment. Okay, that's what we will be like going over today quickly will be very quick. So in traditional environment, we just was discussing that that traditionally when a BA work on a BA start with the project. And after the onboarding have happened, then do a research about the project go over the existing documentation and then identify the stakeholders. Build a kind of a powerful presentation four to seven slides to kick off the requirement sessions. Okay, and then formally kick off the those requirement sessions and invite all the stakeholder primary and secondary everybody and then go over that slide that be prepared that you know, that usually like explain high level requirement and start the discussion from their ask questions and get answers noted don't own the requirement document template and then ask for the questions. Get the answer keep updating the requirement every time scheduling meeting with the stakeholder going over what we have previously done, and then starting from the next, so that we will have that like updated if there is a any conflict in requirement or a repetitive requirement we can, we would have addressed that. Okay, and then as the requirements are done completed. Then, working with the solution team help them understand the requirement, and maybe scheduling a meeting if they require request with the stakeholders, so that they will present their solution options, and then they will write down their solution document, and basically participating be being a partner with the solution team or a solution analyst or system architect or system analyst whoever is doing that you know solution to ensure that all the requirements are have are integrated in the solution the solution is catering all the requirements. And then, as the solution is done development will start development team needs to understand the solution as well as the requirement. As a BA you help the development team to understand the requirement and solution analyst to help them understand the solution, both of your team up to answer all the question about the requirement and the solution. And then the development when proceeding as going at the same time you as a BA work with the QA team help them understand the requirement and then help them basically like with any question about the requirement they have, they will write the test cases and test scripts sometime you partner them and you know help them write some of the test cases mostly like user focus test cases. And then testing when the development complete testing starts a lot of the effects they will they will find participating in those meetings ensuring that they are testing all the requirements that are there in the in your basically requirement document. So, do also kind of a keep a traceability metrics means that you know what from the requirement to solution to development to testing. All those are being there is a like a one to one relationship in those basically items so that you can trace that each requirement is being developed and tested. Okay, and then when testing is complete you work with the stakeholder to identify the users and who is going to be you at testers and work with them to get the uat testing done. And then basically after the uat testing for before deployment, participating in change management process. So that's what you do as a be in a traditional environment. Okay, and any questions so far. No. Okay, all right, maybe when we when we go through. Okay, all right. Now, next, we are going to be in agile environment. Okay, so agile is a method to develop the software just like we have a waterfall method. Okay, but the only difference in the agile is agile is a creative method in waterfall. We take up all the requirement with done with the requirement then go for design done with that design for whole product then go for you know testing done with testing and then go for user acceptance testing. Okay, and that may take like kind of maybe three months four months like requirement and then five months like to three months for design and five months for, you know, development and then four months for testing and you know, two, three weeks for uat and then deploy so whole process may take like one one year plus to complete. Okay, so in other methodology agile, what we do we like build, we do build in form of kind of iteration. Okay, in chunks. So, we take up like a whole product split it down into, you know, multiple features, and then we build those features in kind of a time box of two weeks to sometime three weeks to but mostly two weeks. Okay, so we call that two weeks sprint or iteration or time box. Okay, and then in two weeks basically those are 10 days like day one to day 10 to two weeks working weeks Monday to Friday, 10 days. Okay, and we do same thing. Like, you know, this requirement design development testing. Okay, but everything we do within these, you know, two weeks till kind of, you know, final uat, you know, tested product. Okay, but everything we do within two weeks. So that's why we divide that if there are like 10 features, maybe we divide those 10 features into like, you know, those 20 weeks are, if there are 10 features, we might divide those into basically like 20, 20 different features and then take up one feature each sprint and then build build it. Okay. So, and in agile, there are three roles, like here we have a role team roles basically, you know, there is a BA, there is a system analyst, there are developers, there are QA, and then there are basically architects and all those, all those are traditional, basically role in our traditional project. Okay. And here we have three roles. There's a one role product owner and other role we have scrum master and then third role that is like basically development team. You know, those are, you know, developers. So usually product owner is a one person scrum master is a one person and the development team is five to seven people. Which include QA, data analyst or a BA, so BA, so all those like will be part of that development team. Okay. So, so, so product owner, here we have only one stakeholder. Okay. And only one stakeholder is the product owner. So one person. So there is a no like kind of a big stakeholders that they have to, you know, go for the requirement. So business product owner is a stakeholder representative product owner has authority to give work that basically define the features define what the business need is and also accept the work that you know this development team does. Okay. So one person that has authority to give the requirement and accept the work scrum master scrum master is a leader who make sure that the team has everything they need to meet the expectation of the this sprint. These 10 days, whatever the team take up that we will do this feature to make sure team will have everything to build that feature and protect the team from any external influences and also provide if there is any roadblock team will encounter to work on that roadblock and all those risk for the team. So team will have a safe and smooth environment to do the development testing and making the product a product shipable ready by day 10 of the sprint. Okay. So making that one of the future team committed shipable ready by day 10 of the sprint then the development team development team is a cross functional team. It has a VA and the key way up all that you know technical expertise that needed to build that software they have that you know, within the team. So that is basically development team. So these are the technical folks. Okay. So who have to actually code with their hand or test that code. And sometimes they they're like are kind of just programmers means they can code and test together. One person said there is a no differentiation between like the developer or the key way, but still because they are coming from the mostly teams are coming from traditional environment and in the traditional. There's a differentiation of developers and tester Q is so still in the team they have like, you know, in five to seven people they have, you know, three to two ratio of development and the key way means if a five developer, then two testers. Okay, something like that are four developers, you know, to test or one data analyst or a system architect or something. Okay. Make sense. Yes. Okay. Well, I have a question. Mm hmm. So hold that hold that. Okay, let's like, finish it. And then you will like, you know, note down the that question and let me finish. And then you will ask that question. Okay. So, we have three role in basically agile product owners come master and development team product owner one person's come after one person development team, like five to seven folks with who are which are comprises of developer testers, or any other technical expertise the need. Okay, and they work in form of like iteration and time box. Okay, so then how the work basically starts. So work start starts with the product owner and the be a working together. Okay, so be a work with the product owner and prepare product backlog. Okay. All right. So this is the their first step. So as the product project basically start so in here we have a, you know, product on it. That is probably the first person who start like in a pro like agile project and the be a so be a product work together and be a note down basically the product owner and note down all the features. Like, they usually start with 10 important features there that the, you know, the product owner needed to be included in that basically product. Okay, so a wish list, usually you can say that, you know, to build the product, what the be a does. There are wish list. Okay. And there is a high level feature and then be a with PO be a prioritize those wish list with the PO means like say these high level requirement. They documented say 40 features. All right. So those are basically 40 user stories, which are basically you can say one sentence requirement. Like in one sentence, those features will be, we need this feature, we need this feature, we need this, this, this, we need this capability, we need to view this, we need to do this, we need. So all those wish list about that project be a prepared that wish list. And then prioritize that wish list of them like, you know, hey, out of these 40, what are the 10 most important feature. So basically identify those 10 with the PO, right. And as those are 10 identified, then the third is work with work with PO to break down those capabilities into features and then into unit level functionality. Okay. And that will, that will be called our product backlog. Okay, so that list and that document, documented user stories will be called our product backlog. Okay. Work with the product owner, product owner is one person to first prepare the wish list, which is definitely high level features that you know, just ask that okay, what features you want in it, what capabilities you want in this product. Okay. So what you guys, so ask those questions and then keep noting down those like features are capabilities that they mentioned, and then secondly, when they have that all those documented, then prioritizing, okay, are out of these for, you know, 40 or 50, whatever the number. What are the 10 most important that you want to, you know, see first. And then have that 10 most important, and then working, taking those 10 out of those 40, and then one by one working with the on those item working with the product owner to break that down that you know what in this feature, what do you want to see. What do you want to view why you need it. So basically that is again using the requirement gathering capability, you grill that basically with that the PO, break that down using different techniques either it's like, you know, root cause analysis or maybe like, you know, SWAT analysis. So break that those like down into smaller features and functionalities, and to basically a unit level functionality. Okay. And write those down in form of user stories, and that will become your product backlog. Okay. So any questions so far. Brilliant. So the question I had to ask. So it means in the agile environment. The product owner is the stakeholder right. Yes. Okay. Is it possible for you to work in a company and you still do all those rules. I didn't understand your question. Is it possible. Is it possible for you to put up on a scroll master. Why you're a BA in a company. So first thing is that this is these are the you have to understand these are the methodologies. So the companies. Okay, it is a company wide policies to basically do the way they are doing the development. Okay. Yeah, right now, the companies, some of the, you know, business section or some of the projects they are doing in waterfall. Mostly they are doing in agile. Okay. And they already have that base, basically those role defined and the people in there. Okay, you just have to as well when you don't. With this project I will be working on, you know, who's the product, product owner. So they will have that, you know, product owner identified. And then you meet with that that product owner and start your work. Okay. My final question is, so is a traditional way of the traditional way to use than the agile way, or they just mix the two. Oh, that's a good question. So right now, so traditional way is the way that companies are doing for decades. Okay. So that is and that that way use the basically stakeholder can only view or have the product after everything is done. Okay, basically, if they are starting some project with the in waterfall, they can see the product, maybe after nine months, 10 months, 11 months, 15 months, whatever that, you know, but here you are the product. The stakeholders are, you know, the user, they can see some features functionality every sprint. Yes. Okay. So that's why now most of the company are transforming from traditional to what agile. Okay. So in the company, you will sometime, you know, see both happening, you know, side by side. But usually like either the project they are doing in waterfall, or they are doing in basically agile. Okay. And yeah, so if they are doing in agile, they are just doing in agile. Okay. So some companies do have they do some of the stuff in waterfall way, maybe, you know, they do the requirement gathering and all that pre pre like, you know, development work in the waterfall, and then development they do in basically agile. That happens to. Okay. So in that case, still, you will do the same. For that you have a basically maybe a requirement document or something. And then you work with, you know, the product owner. Okay. And BA is also called product owner proxy. Okay. Okay. So most of the companies know they are have a role, you know, the product owner do the BA job. Okay. So if you will say like what is the product owner role. So if the BA will get authority that he can also accept the work what the development and testing team is doing, then that BA becomes product owner. Okay. So my next question is, if you go in for an interview right and it's an agile company, do you necessarily need to start explaining all the traditional way of doing things or we just go straight to the agile way of doing the job. Right. First, when you will apply for some, you know, job based on the job requirement, you will know, either they are doing in waterfall or agile. Okay. And there is a no agile and waterfall company like every company may be implementing both. Okay. So this is again a methodology to basically implement or you can say software development methodology that is nothing like an else and for companies have both methodologies going on. Okay. And you as a, you know, BA, either it's agile or waterfall, it's doesn't matter for you. You are kind of doing the same thing here. But instead of like seven different stakeholders, you just have one product owner. So your job is kind of easier over here. Yes. Okay. Yes. You don't have to do the stakeholder analysis and all that. That's my exact question. So you have one person, you who will. And here you have to prepare a business requirement document and in agile, you have to just build the backlog. Yes. Write down the document user stories and backlog and basically, and who is the owner of the backlog product. Yeah. Right. So basically you are a support role to the product owner in agile. Yeah. Okay. So that's what, you know, basically do. And then your job is basically document the requirement in form of user stories and update the user stories, if there will be any change happening during the, you know, whole project. So that's what you do basically. Okay. Thank you. I have a quick question. Sure. So this was for BA in waterfall or the traditional, they do all the requirement, Godrain and stuff, but in agile, they don't do or that because they just have only one stakeholder, they have the appeal. So when it goes to project management, is there something like an agile project management and water. Right. Yes. So agile project manager, they do like kind of, you know, mostly in the agile project manager role, their role is based on basically resource planning, because you still need product owner and the BA scrum master and seven people in the team. Okay, so you need to plan there. Basically, like, you know, do the planning and all those budgetary estimates and all that budget budgetary management and risk management that you have to do. So that's what that's what the project manager does. The project manager does the same thing. Right. But not, not the, you know, the project planning and all that, like, you know, but just the resource planning and budgetary planning and budgetary planning. Yes. Okay. Yeah, yeah. Okay. And we doesn't do that, you know, the project planning part are, you know, they build like kind of timeline and all that know only resource planning and budgetary planning, and they manage the basically budget and resource and any risk related to that. Okay. Nothing to the project. The risk to the project managed by that scrum master. Whoa. Okay. All right. This is a project like, you know, with the development and everything that is managed by the scrum master. So project manager. So usually in the project manager have like five company in a company the project manager usually have five, six projects they, you know, manage, because their role kind of, you know, shrink in a their role is now shrink to basically like, you know, resource management and budgetary management. Okay. Yeah. So you have to, you know, if you are working as a project manager, where the adult and you have to understand that you know what was your role down there. So you cannot, you know, start explaining that, you know, I did that, you know, the project planning and, you know, timeline and all that that doesn't happen. You know, it doesn't happen because the product owner knows like what what the product is, and usually they start and then keep extending the backlog based on the business. So for example, 40, you know, features they identify initially, and with 10 features they started working on it by identifying and explaining 10 features they started. And then as the project is going on every sprint, they keep working on and maybe like there will be 100 features later on. Okay, so the backlog keep extending. Okay. So that's like how it's like, that's why project manager doesn't need to do that. Project planning. Okay. Any, any questions so far. No Shazad, but can you send me the. I had a, like a lot of problem with my internet connection today. So, I will share to this like. Yeah, basically, because I got to go through like the whole thing. Yeah. Sorry about that though. Nobody's nobody. All right, so in a jail, we have three goals, and we have a time box sprint day one to date and then we have a certain events that happen from day one to date and. Okay. That events that happens that is on the day one of the sprint or iteration or time box, these all three are kind of, you know, the same thing name and usually most popular is a sprint. So we will be using sprint most most of the time on day one of the sprint the first event that happened is the sprint planning meeting. Okay. And in that meeting scrum master hold that meeting product owner and the dev team and the be a everybody they participate. So, product owner, there is like no defined role of a be in that meeting, except to sit back and update if there is any change in any user story. So product owner take, you know, some of the feature from the product backlog and ask the team that he wants the team to build this feature in this sprint. That becomes the sprint goal, then the team pick up in during the sprint planning meeting team pick up that feature and start asking question and see if it is like. Basically do a brainstorming session on that features that you know what what that feature is what would be the design and what would be the basically solution and what is the acceptance criteria of that feature on what criteria the product owner would be accepting that features that. So all those nitty gritty details that discuss, and then basically they log task with that feature. And with that task, the log task in form of like others like, for example, developer one say like I need a 20 hour work to for development to do this task. Then, you know, I need all those like developers put their hours, and then Q is put their hours, whole team put their hours on that and the whole teams mean dev team. Okay developer Q SDA who are doing coding designing testing. Okay, so they put their hours and in it and scrum master then see the team capacity because each five to seven members have for, you know, 80 hours total. To spend and 20 hours of kind of analysis gaps so basically like 60 hours of, you know, coding time or testing time they have. So based on that capacity will see that you know what task they have mentioned and if any resource has kind of, you know, overloaded. Okay, so then based on that negotiate with the product owner that what the team can come, you know, complete within that and if the team can complete the whole feature or a part of that feature. Okay, then the basically after that team commits to that work that okay, all right, we can, you know, take up this feature or this part of feature and finished in this 10 days. Everybody agrees and that is the end of screen planning meeting and that happens first meeting on the day one of the split. Okay, then team breakouts and they start working on their tasks and on day two scrum master do like daily stand up that is 15 minutes meeting in which each team members like a discuss three questions that what they have basically, you know, done. Yesterday, and if there is and what they will be doing today and if there is any roadblock or issue they are having or anticipating. Okay, and then each one by one everybody like speak about that and if they have any question to the product owner they can ask and if they have any roadblock then scrum master work with them. With that particular member to ensure that they have everything but that resource needs. Okay, and then from day two to day nine every day this 15 minutes meeting. And as the team start completing their user story they schedule demo with the product on basically they show that you know hey this is what we have done this is what we have done they show them working software. Okay, and based on that demo product owner accept the user story and on the day 10 they are the whole team give end to end the like a review of those that product or that feature they have built and we call it sprint review meeting on day 10. By midday there is a sprint review meeting and by day and there is a sprint retrospective meeting in with the whole team they sit down and they retrospect themselves they review that how they have done and how they can improve in the next spring. What the what is the they what did they did wrong and what would be the strategy that in next print they will like them do better and scrum master take that basically and put a improvement plan for next print and keep tracking that plan. Okay, so this is basically whole gameplay that is happening you know every sprint to sprint and each sprint they are building some feature and at the end those features are basically like you know becomes a product. Okay, and either based on the business they they can release like whenever the feature is like ready or they can wait and release all the features together so it is a decision of the basically like you know the stakeholders or whoever sponsoring that project. Or you can say product owners decision. Okay. Make sense. Yes. Okay, alright so any question then. No questions for now. Alright, I will send you this like a two day session recording. Okay, tomorrow come with the question and right now I want you guys to basically get your, you know project manager role stories, a line that you know as a project manager when you work what project you work and what was your role and what you did. Write that down in like on paper and send it out to me so I can basically review them and then guide them if the there's anything missing in your response. Oh, you said project manager role project manager role and then second be a in traditional environment. Okay. Okay. And then after that now also add be an agile project. Okay, so we should come with all that tomorrow. You prepare that and send that to me and tomorrow we can basically discuss those like one by one. Okay, but you have to write it down on like either on Microsoft Word. Okay. And then send it out so that I would be able to like assist you that where you are making mistakes and then you will perfect those answer and will practice for your interview. Okay. Thank you. All right. And we also have a new member today join Siri. Hey Siri, how are you doing? Can you introduce yourself with everybody. You're, you're new to so I don't know like. Okay, yeah, go go ahead. Still be unable to hear you. Is it just me or everybody. Yeah, I can hear either. Okay. My mic is not working. Okay, no worries. So we can, you know, if you can have your mic working tomorrow, then we will basically get you introduce it very. So just a short introduction city is like he has worked as a developer and programmer, and then he worked as a, like a business analyst, business system analyst. So he has almost 20 plus year experience, but he was out for like taking vacation for last three years. So he's going to get back to the market now. So he would be kind of preparing his interview and going over and also kind of helping other team members with his experience. Oh, that's good. All right. And his market is he, he will is going to get his marketing, basically that for the job finding a job so in the process of that, you know, I will be helping him and we can basically share ideas and answers and questions on the team members. So that's it. So with that said, any further question anybody. I have just a quick question. Do you also like resume market sense also. So that's like for that Zuri Zuri is the department she is a representative for the, like, you know, the company that you know epic for whom we train, but provide support basically interview support training support. And like post job support. Okay. Okay, but the job they will be finding, you know, job for you guys. Okay. Yeah. So for any job related question check with Zuri. Okay, thank you. Okay. I'll see you guys tomorrow. Thank you very much.