Agile Project Management Full Course | Agile Course | Agile Training | Intellipaat

[Music] hello everyone and welcome to today's session on agile project management full course by intellipad the meaning of agile is swift or versatile agile process model refers to a software development approach based on iterative development agile methods break tasks into smaller iterations or paths that do not directly involve into long-term planning the project scope and the requirements are laid down at the beginning of the development process itself plans regarding the number of iterations the duration and the scope of each iterations are clearly defined in advance in this session we will learn all about agile and all its properties so without further ado let's check the agenda for the session before we talk about age oil we first need to understand what is sdlc so within a software organization software development lifecycle or sdlc is a detailed strategy and adaptability an agile or iterative strategy strives to deliver benefits throughout the process other than just at the end trust adaptability empowerment and cooperation should all be essential ideals and behaviors in asia initiatives with that being said let's move on to our next agenda the tenets of an agile approach the age ideology emphasizes empowered individuals and their relationship as well as early and consistent value delivery into an organization when the pressure to perform is greater than the risk agile project management focuses on providing maximum value against business priorities in the time and money allotted the following are some of the principles the project divides the requirement into smaller chunks which the team then ranks in order of importance collaboration is encouraged in the agile project especially with the customer at frequent intervals the agile project reflects learns and adjusts to guarantee that the customer is always satisfied and that the benefits are delivered agile approaches combine planning and execution allowing a company to develop a working attitude that enables a team to adjust quickly to changing needs now let's take a look at the key components of an agile approach adria project management primarily has six key components and they are user stories simply put a user story is a high level description of a task it gives just enough information for the team to come up with a credible estimate of the time it will take to complete the request this brief straightforward explanation is written from the user's point of view and focuses on describing what your client wants and why do they want so next we have product roadmap creation a roadmap is a list of features that will be included in the final product because your team will construct these specific features throughout each sprint this is an important part of an age oil planning cycle you will also create a product backlog at this time which is a list of all the features and deliverables that will go into the final product your team will extract tasks from this backlog when planning sprints later next we have sprint planning before each sprint begins the stakeholders must attend a sprint planning meeting to identify what each individual will do during the sprint how it will be accomplished and assess the task load it's critical to equally distribute the workload among team members so that they can complete their assigned duties during the sprint for team openness shared understanding and detecting and reducing bottlenecks you will also need to visually describe your workflow next we have sprint sprints are short iterations of one to three weeks in length during which teams focus on tasks set out at the sprint planning meeting as time goes on the goal is to keep repeating these prints until your product is future ready after this print you analyze the product to see what is working and what is not make improvements and start a new sprint to improve the product or service next we have the stand-up meetings daily stand-up meetings often known as daily scrum meetings are an excellent approach to keep everyone on track and informed these meetings are usually short and to the point last component that we have here is backlog project requests become outstanding stories in the backlog as they are added through your intake mechanism your team will estimate narrative points for each task during agile planning meetings stories from the backlog are added into the print to be performed during the iteration that is done during sprint preparation in an agile context managing your backlog is critical for project managers with that being the last component let's move on to our next agenda that is the methods involved as agile became a popular topic at the turn of the century numerous frameworks jumped on the bandwagon and quickly rose to prominence like scrum etc many firms pursuing true business agility on the other hand discovered that overly prescriptive frameworks and agility are diametrically opposed kanban scrum and scrumban are the most prominent age oil project management frameworks or approaches that are present today let's start with kanban it is a method that was developed over a decade ago it focuses on ongoing process improvement and evolutionary development the six key practices of the technique are as follows improve cooperation by visualizing work limiting work in progress managing flow making process policies explicit implementing feedback loops and improving collaboratively next up we have scrum many people mistake scrum for an agile methodology although it is essentially a prescriptive framework it is an iterative approach that divides projects into set periods called sprints and uses time-boxed intervals the primary goal is to assist teams in delivering high-value products in a productive and creative manner there are three roles that cannot be changed in a scrum owner of the product the scrum master and the team customers and other stakeholders are represented by the product owner he or she organizes and manages the product backlog which is a priority task list of all the products work items the scrum master on the other hand is a servant leader of the team who focuses on leadership and assist everyone in understanding and applying the rules appropriately and lastly we have scrum ban as kanban became increasingly popular individuals in the age oil community recognize an opportunity to create a system that allows crumb teams to focus on continuous improvement and evolutionary change while moving forward scrumban was born as a result of this it's worth noting that 81 percent of scrum masters use kanban in addition to scrum scrum man applies kanban's concepts and practices to scrum while also removing some rules now let's move on to our next agenda that who are the users or who uses age oil project management the azr project management approach which was originally developed for software development is increasingly being adopted by more than just id teams marketers universities the military and even the automobile industry are using it agile methodologies and frameworks to develop creative products in difficult circumstances agile project management may help a wide range of enterprises and it's simple to set up and use when deciding to establish or improve as existing technology in the software sector the ultimate product can be difficult to describe age oil allows for this ambiguity since it enables project direction to alter as work progresses into the future while agile software books and coaches can help you put together an agile methodology that works for you and your team each age oil team is unique and understanding the basics can help you build together an agent methodology that works for you and your team now let's move on to the benefits of agile working the first benefit that we have here is asil methods empower people involved hence increasing accountability promoting a variety of ideas allowing early benefits release and promoting ongoing improvement second benefit is age oil can be effective in promoting cultural change which is important to the success of most transformation projects because changes are progressive and evolutionary rather than revolutionary as a result it can assist in creating client and user involvement agile permits decision gremlins to be tried and rejected early whereas the waterfall model does not agile's tight feedback loops bring benefits that again the waterfall model does not but before we begin the session make sure to subscribe to our channel and press the bell icon so that you'll never miss any update from us so understanding and identifying the right development life cycle model is essentially important for any application development successful it's not only about how technically are we strong but it is equally important to understand the right development life cycle models so whatever are we going to discuss about agile at all everything is connecting to that so let me explain you in a high level note about the different different models which are available wherein you can see on the screen here so there are different different models of software development life cycle i'm just naming a few i'm not going in detail so one the first model we call it is waterfall mode waterfall is a kind of model which is also called as linear sequential model so where we have whatever the analysis planning design implementation testing or whatever we have everything will happen one after another so that there will be of no deviation so once the analysis is completed we go for a planning and design followed by this we go for implementation of the project testing all that stuff one after another this is a kind of model which is a traditional on its approach using bias for a very long time at the same time this is a kind of model which is having its own success rate in application development but make sure the requirements whatever customer has given should not have any kind of changes in between right so when there is an assurance given by the client that no changes in requirements taken place this waterfall model is highly useful this is the first model so this model of course even nowadays even waterfall model underline we use because when someone are new to agile or someone are new to application development this is the model which is rightly useful for everyone the next model we call it as v model this v model will also called as verification and validation model here both verification and validation happen sequentially means whenever we have limited time because in the first model of v model we don't have any when there is no time restriction no duration restriction that model is highly useful which one waterfall because sometimes customer has approached us to develop the project to complete and provide the whole project assume that it is taking eight months to one year assume that right roughly i'm saying when customer is accepting you at the same time when customer is accepting you that that no changes will be taken place in between waterfall is the best one the second model is called as remodel v model means verification validation where whatever the development activity followed by the testing activity happens parallelly means testing team will start working right from the requirement analysis space itself usually right because whenever we have taken the requirements from the ba ba will take all the requirements right so we try to analyze the requirements we try to identify why are these requirements are important how to understand the requirements so whenever in this process even testing team will also work parallelly means what requirements we have taken and what must be the output that is what generally testing team will prepare this is all happens through manual process because in testing there will be two different things one is manual second is automation manual testing means they prepare different different test cases test plans desk scripts all that whereas automation testing means using different different tools something like selenium and all everything code will be tested accordingly so based on the code whatever they are tested if they have identified bugs that will be prepared as a report again on the document again this will be submitted to the implementation team so that they will do the corrections accordingly this is how generally the process will go on so this v is a model verification and validation model majorly used when we have a limited time means when we have a limited uh amount of time we have whenever we want to completely complete it as a list this way model is highly useful where both development team development as well as testing happens parallelly means whatever the work we do in the development phase even before coding starts even because before coding start there are lot many things right so we need to understand the requirements once we have understood the requirements we have to classify them we have to prioritize the request after prioritization we have to understand the requirements whatever the prioritization we have made we need to understand whether the requirements were right or not right so is this requirements for sufficient so once the requirements we have identified everything was finalized then requirements communication this is where generally this prd srs all these things comes into picture so after that we do the designing part followed by the design coding will be done so whatever the activity from the development perspective as well as the testing perspective happens sequentially this is what we call it as v model so whenever we have a limited time v model is something highly useful and desirable this is the second model the third model rather than the model third and fourth are considered as incremental iterative approaches rather than the model the best part of the thing i tell you is that incremental and as less iterative are the approaches because underlying whenever we are working on agile environment this incremental iterative will be used because these are the approaches the best part of saying these two things are approaches so what is incremental model incremental model means in each and every phase each and every build of the application we do we are adding new things into that i'll give you best example i think last time i have given i hope let me repeat the scene if not let's say there is a customer page a login page which was created whatever we have created whatever the login page we have created so far login page was created we have given all the user id password all the details is given now in between customer wants you to add some second level verification means second level verification process is what customer is expecting means first level verification process done login id password was given customer wants to have an additional security for that reason they want a two-step verification process again the second step verification process either we get a password otp number to our registered mobile number so that we have to give so that it will be logged in right so assume that this is the second way of second step of verification in terms of the security this is what generally the customer is planned so where are we doing these add-ons this we are doing these add-ons and all everything on the second bit it means each and every phase of development phase means once the implementation everything done wherever in the second build we are adding new more things into that this is what generally incremental stands for means each and every phase of implementation we are adding new increments into the existing ones this is what we call it as incremental model stands for followed by incremental model the next is iterative model or iterative process or approach i can see iterative approach where we are working on something giving it to the customer as long as customer is not accepted we don't go to the next level this is what iterative process means we are providing more value services to the customer by adding some new things doing some changes and all everything into that so this is how generally iterative process is so these are the traditional ones whatever we have discussed so far either it is a waterfall model or it may be v model or it is incremental or iterative all these processors are the traditional ones traditional ones which we are using for a very long time now due to the changes and volatility and requirements taken place nowadays because nowadays as you know any enterprise especially everything is competitive right so whatever the services they are providing today may not be by tomorrow right so tomorrow they have to come up with a new thing this is how the market and industry has changed evolved so we have to run along with that right so then then only existency will be there for any enterprise so customer requires lot of changes to be made into the existing one sometimes or as they may require to add some new things and all everything into the existing ones or else to develop a new application or a new technology they want to implement so this is a continuous process for any enterprise nowadays they are expecting means they are expecting an application to be completed in very less time that to a quality out because quality they don't want to compromise but they want things to be completed within less time but the practical difficulty is as it's a human intervention because end of the day whatever the coding we do whatever the testing design part diagrams we prepare architecture everything is being connecting with human rights manpower people has to do it it's not by robots remember so human intervention is involved more so there will be some desired timelines which are essentially required for us to complete but unfortunately some people customers doesn't have the time to wait due to multiple reasons maybe they have their own reasons for that so there are possibilities that they may not have that much time to wait that extent possible so they require some kind of approach which can suits their condition means what are their condition one is they want their application to be completed in very less time that to any quality output they have to expect they are expecting right this is these are the major things which they're expecting but the traditional ones what we have discussed so far doesn't have that provision to do that that's a reason why agile is the model or agile is a methodology apart from all that i can say agile is a way of approach which was introduced nowadays of course nowadays means not now recently from past eight to ten years agile was there of course in very limited in percentage not more aggressively but nowadays of course everybody understood the importance of agile and slowly adoption in their processes is taking place that's a different story name anyway right so slowly the implementation and as well as the importance of agile has increased agile is something suitable for the present condition which customers are expecting that's the reason why importance of agile is more novelis right so i am going to discuss about agile because whatever we have completed so far about the waterfall model incremental iterative all that we have completed and now i am going to discuss about agile so what is agile is all about why agile for what reason we are using agile all that so this is these are the three different points we need to discuss here the first point is why agile for what reason agile is second point for what agile is being used for and the third is it agile is confined only to i.t companies or not right these are the three points we need to discuss first then we go for what are the different different values and principles of agile we have followed by this y scrum right so what is the difference between scrum and xp excrement kanban right so all that will be discussed in the lateral stage now let us discuss about why agile as i told you earlier customer wants the project has to be whatever the solution let us understand from the perspective of a solution has to be completed in very less time that too delivery should have a value quality delivery has to be done for that reason hp is being used in application development nowadays means whatever the requirement customer is having whatever customer is expecting us to complete we are completing in very less time and we are delivering it to the extent possible whatever the quality we can provide to the client but the advantage in agile is whatever the implementation we do whatever the release we do everything is under small iterations because in agile we do small iterations assume that for example do we have a clear and simple understanding and tell you to complete a project called a core banking let us understand the core banking is an application we are developing right from analysis to deployment delivery followed by follow till delivery assume that it takes to 12 months time for you to complete now what is that we are doing we are dividing it is to make you simple and giving this example making it more simple so what is that we can do we can divide into three different parts every four months there is a release or every three months there is a release hence there will be four different releases so four threes are twelve or three into four one right this is how it is so every three months there is a release we are planning for every four months we are planning a release whatever is required for the particular release is what the parameter hence we are not focusing on the whole application the advantage in agile is especially in reference to the team mca whoever is involving in agile they need not be focusing on the whole application so their focus must be only for the particular time timeline which is somewhere around near to about three to four months of time right so assume that if it is three months time of release whatever is required in the first coming three months is what the plan of action team will be focused more on so once it is done then next again we plan for the second release third release fourth reason so on right this is how generally the process will happen so this is possible when we want to implement agile because the structure as well as the value system which visual is having whatever the principle and as well as the structure of agile is something suitable to that this is one advantage at the same time the other advantage is that if there is any kind of changes to be made in between because in the beginning itself i told you volatility requirements will be more because whatever the offer whatever the changes and whatever the process they were implementing or whatever the strategy they were implementing today may be outdated for the next couple of days sometimes right due to the different different domains it varies so there is a constant changes on the existing requirements which might be taken required in between this is not possible something in the traditional way of approach because every requirement is being whatever the functional and non-functional requirements we are developing everything was interconnected at the same time whatever the requirements we are writing everything will be written in a documentation format and we are implementing the say the same way as this but whereas in agile the approach of writing down the requirements and all everything in a different format that is how generally user story we call it yes user story format it is means each and every user story is having independent on its nature so that there is no connect with other user story so that whatever the implementation whatever the changes we want to make out of it can be changed accordingly so that this is how generally one example i'm saying so these are the ways where agile is more extensively using nowadays in implementation of the projects so this explanation i am giving you irrespective technology in the domain and saying this in reference to the i.t projects now the third question important question for most of the people who are from non-iit should understand this is this agile way of approach or agile methodology or a process whatever we say is it something relating only for iit organizations or is it relating to other assets see agile provides you delivery for the value value for the delivery right so whatever the delivery we have delivery of work we are providing we are giving it to the client it should have a value should have a quality that is what generally the aim of eject so this can be incorporated anywhere this is need not be variety because whereas we are working on it projects development we are talking about agile for example when you are working on operation sector right operations to mine cooperation side for any of the organization in order to streamline our processes and all agile agile can be incorporated now for example healthcare in process of healthcare agile can be incorporated even in hr agile can be incorporated even in sales and marketing agile can be incorporated so agile is a way of approach where you can provide a quality of services to the customer in phase wise within the limited time that is what the approach of agile is so agile is not something confined only for id project development his is useful everywhere because there is a connect here because every process whatever process we follow for any of our organization everything is connecting to id without technology nothing right so for example if you want to manage your customers and all we have an application called cr customer relationship management we are using you want to integrate all the departments all the processes all that we have an application called erp where you are connecting with different different departments to streamline your business process all that stuff right so even production all that can be incorporated if you want to manage your employees their payroll and all that payroll management system to manage back end operations of your bank by using core banking so every organization to manage their operations business operations technology has become an integral part of it so understanding it incorporating i.t has becoming has become inevitable in every organization and every process even hr marketing operations everywhere so agile has a connect to that extent so agility is not something relating to it companies because i t process is involved even in 180 also right even you can take any healthcare organization or a retail or a banking insurance all that stuff everywhere right is involved because whatever the process they were following everything is connecting to the machine technology id all that hence agile can be used anywhere right this is the introduction about agile so why is a for what reason agility being used so is it agile is only used only for iit or not yes it's not no it is known because agility is not completely to yt organizations companies even agile can be incorporated even in non-iit also so this is all about the introduction about agile at the same time comparing this with the traditional models we are using for all time so whatever the focus we do now is completely into it project development not relating to nominating subject to terms and conditions this is what generally we have to so our focus will be majorly to agile towards id this is what generally our focus is so this is what whatever i have given so far about the introduction about hr id now great agile now i am going to explain you in terms of the manpower because you can see that traditional way of approaching because this is what you must be knowing first before i am going for values principles or else before i am going for scrum right so if you'd like to know about all that so first of all let us understand the difference between the teams when we are comparing from traditional to ajax this is not the comparison one more difference which you need to understand is this because if you take a traditional team let's say we are using waterfall model or v model whichever the model are we using when you take a traditional teams into consideration there are a lot of people will be involved the major difference between traditional agile a lot of people will be involved right you'll be having a project manager who will be taking care of project planning budgeting all that stuff you have architects these people will be involved in developing architecture for the project at the same time you have development team technical testing team user interface designers documentation team business analyst right so these many people so if you want to develop an application or if you are providing solutions for one customer at least minimum 20 to 30 people required for you to complete the whole thing why because project manager is the one who is exclusively focusing more on project planning business analyst takes care of business requirements architect takes care of architecture of the project remaining implementation teams take care of coding testing all that right this is how generally the traditional teams are so the team size is very very big at the same time everybody have their own individual responsibilities so the focus is only on the responsibility which was given to them this is what generally traditional teams work if you are a developer your responsibilities and whatever the work you do everything is confined only to your coding part so you don't take care of other things unless if it is assigned to you which is compulsory you do it otherwise end of the day we don't do it right so we are only for that particular work we are belongs to so we do only that part we don't do any anything else apart that is what generally traditional teams wants but whereas when you are comparing traditional to agile agile has a different approach agile is a self-organizing team self-organizing team means whatever the decision whatever the implementation they are doing what are the decisions they are taking everything is self-organized means companies and organizations making everyone accountable on the deeds or the work what they are working on because in traditional way if you are taking project manager project manager is the responsible to complete the project on time right normally project manager is the responsibility only for the whole project whereas the same responsibility you don't see that to the developer because developer is only responsible for the work which was assigned to them right so once the coding is complete enough so they don't go for anything else apart just a quick info guys intellipaat provides agile training mentored by industry experts the course link of which is given in the description below now let's continue with the session but whereas when it comes to the agile environment that is not something like that because the major difference is this because in agile the advantage in agile underlying point because being in this organization industry for a very long time as i could i could see uh closely i could see and i'm interacting with a lot of entrepreneurs right business owners when i'm transforming the themes all that so what i closely observed is agile implementation not only for quality of services providing all that stuff we should also they want to make each and everybody accountable for the deeds what they are doing so they are making everybody accountable so when there is an accountability there is a responsibility right so responsibility and accountability were interconnected so they want to make each and everyone interconnected and responsible to one another that's the reason why this is all a self-organizing theme this is what we call a self-organizing team where it is being connected interconnected self-organizing nothing but interconnected so it is all interconnected so whatever the work we do everything was interconnected self-organizing teams are interconnected so each and every person who is working in agile environment is responsible for each and every deed which is happening means if you are a developer you cannot claim yourself that you will be only for development even the work allotment when given to you if there is someone is absent the other team members has to complete that work within the limited timelines because agile is completely into short iterations and specific timeline so there must be an team effort right team management team coordination team effectiveness is important then only that agile way of approach is successful otherwise not that's the reason why there is a difference between that we are working in agile environment and as well as working effectively in eject because there is there are two differences because most of the people say that we are working for agile environment people say that they're working on agile environment but practically speaking when we're talking about this when we talk about this hundred percent are they implementing agile is a million dollar question because there are a lot of parameters takes into consideration one they must be having prior experience to implement agile right if not they need to hire someone or they have to provide some training to someone and they need to implement start implementing but when there is an implementation taken place majorly especially in agile based on out of my experience what i have seen is what they have understood is what we called as a channel this is how generally few people of course i am not generalizing this point for every or every team all that but most of the teams feel what i understood is what the mod approaches right this is how generally they are this is because of ignorance not by intention again this is because of ignorance whatever the understood the way what how they understood this is what generally agile so this is how people most of the people feel that's the reason why 100 agile implementation is not happening for all the projects the reason why even though we say agile 100 they don't go for agile way because agile way of approach have different different values principles which everybody must be abide to that that's it what they do is that they say agile practically these are the practical things because on a note of understanding about agile we say so many but in practical reality hundred percent reject are they implementing no because agile combination of traditional models will also be incorporated because due to the comfort because they are that it's first of its kind they are implementing they want to make they don't want to make it so confused right so they don't want to make it more troublesome when they are implementing so what is that they do 100 percent they don't follow agile agile they follow to some extent when there is a difficulty they have understood so far they go for traditional model and the traditional approaches will be used end of the day what is important we need to deliver according to the timelines what customer has given right so that is the ultimate motor but they have started with the intention of implementing agile but hundred percent digital implementation i don't say it is not possible it is difficult because we have to travel all the people should adopt all the people has to understand what is that we are doing how are we doing and each and everybody has to understand the value systems principles and they have to follow that accordingly for a very long time as long as they are working on it everybody has to do it at the same time it's all about mindset hygiene is all about mindset mindset normally human reality is that i don't want to give my credit i don't want to share my with others so this is a human name nothing wrong in it but whereas in agile it doesn't it doesn't work so right so no individual responsibility or no individual capacity or performances will be taking into account our configuration end of the date is all about team effort and team success that is what generally agilities agile never tells you that no individual responsibility will be recognized as a level never encourages this and of that it's all team effort and whatever the success or a failure will be applicable for every team member so self-organizing self-organizing means people who are working under the team are self-organized people whatever the analysis they do whatever the planning and design interacting with the client understanding the requirements taking up the decisions to work on something everything will be looking after by the these team members itself that's the reason why the team size of agile will be very limited this is hardly i can say roughly we will be having not more than 10 members right one team if you say one team one team consists of 10 people right this is how generally the team sizes but whereas in traditional teams it's not like it may go up to 20 30 people total right one project manager maybe two three business analyst maybe one or two architects right one major one and other next level architects will be there data is designing you may be having other people development in couple of developers couple of testing testers couple of user interface designers even for documentation you'll be having a separate person this is how generally the traditional teams will be having so the team size is also very big but whereas in agile it's not that agile is completely confined to the limited people means only limited people not more than 10 so these people has to take care of each and everything so there will be no other people apart but here there means there may be an question by someone from you group from your side maybe there may be some question you may arise a question here raj is this possible practically to complete the whole thing with the limited of 10 people right is it practically viable because is it possible that because it's the human intervention end of the day people are working not robots they cannot work for 24 by 7 right so is it practically viable and possible to complete the whole project let's say if you can take a core banking project which is taking an year and half time for example understand to make it very simple and same right the whole thing now is it practically possible can you expect that the team of 10 people will be completing all these stuck with standard and strict timelines because the timelines were very clear and very strict because everything is in these normally whatever we implement of course all these comes in the next so whatever the implementation in terms of the sprint everything we do everything is confined only to two weeks three weeks four weeks and so on so the durations were very limited and very tiny in terms of the first intervals of the size so do you really feel is it possible practically to some extent yes to some extent no again there is there are two answers yes to some extent possible to some extent no when it is when you are going for enterprise level transformation this is where a concept called a safe normally we call it a safe transformation means called a scale design that's a different story again that's a different thing where we are transforming the whole organization to the agile environment where you are working for large and complex projects so the time what is that we require is we require multiple agile teams in different different locations working for the same project whatever the piece of work will be given to you is entirely different than other people that is how the work distribution will be done but make sure there must be a proper coordination among all these teams to make that application successful in long run finally that is a difficult and challenging task so for that there are different different principles for safe will be having safe principles are there spotify different different things are there so we go to that so agile is not something that only limited people will work for a project to some extent yes because for some projects we do the same for small projects when there is a limited requirement all that yes we do follow but not to the full extent because when we are going for large scale projects where there is lot of complexities in not only the complexity we don't see only the complexity here not only the complexity apart from the complexity we have to see how big the project is so based upon that whatever the team members we have and all everything will be varied there are a lot of team members are involved lot of teams will be involved not even not a single team different different teams will be there right multiple three to four teams will be there there must be a proper coordination with these people in regular intervals that's what we call it as scrum of scrubs the concept is different so that is there so agile so what i am trying to say is that agile is a self-organizing team even though it is limited in terms of the size of the people on its percentage 100 agile implementation may not be effective for all the projects depends on the size of the project depends on the complexity sometimes when you want to transform the enterprise level means enterprise level transformation means you're transforming the organization to an agile way of approach so for that there are lot of people required for you a lot of team collaboration is something essentially needed for you to manage so that is also needed so different different things are involved in this so agile is not 100 possible means a single team i'm saying right not possible for every project multiple teams also required so this is the understanding you need to have so again coming back to our this thing so this is what generally they see the differences if you can see the traditional team traditional team members whoever the members we have and all everything will be different at the same time when we talk about agile at all agile is something entirely different it's a self-organizing team where team people will be limited on its percentage and that to agile is role specific there are different different roles will be there in agile where depends on the role whatever the role will be given to you will be assigned to you there will be some responsibilities will be given to you as well so based upon the roles and responsibilities which was allotted to you so you have to work accordingly this is what generally agile tells you but whereas in traditional way of approach and all it's different but whereas in agile it's a self-organizing thing each and everybody is responsible for the deeds what they were working on so this is the difference you can see from traditional to agile now what is the pillar of implementation of agile means agile pillar this is what we call it as value or we call it as agile values what are the different different values do we have in a jail we call it as four different agile values we have so what are the different different values agile is had this values also we called as agile manifesto in other word for this is called as agile manifesto or values four agile values so what are the pillars fillers of agent this is what we were discussing here what are the four different colors because how it is different from the traditional one because traditional way of approach known to you guys well right so because implementation can be done anytime so there is no timing restriction even though you have time restriction there will be an extension of timelines which might be taken by us upon the request of the customer and we can request the customer and we can get that and individual capacity based on the individual capacity people are working 100 we try our best to make it successful but there are some cases where due to different reasons projects will be failed this project failure we need to understand in two different ways one is technical failure record second is financially failure budget level fail technical failure means we are not we haven't understood the requirements properly hence whatever the application or development we have done so far is not according to the expectation of the customer this is what we call the technical failure next project failure in terms of the budget budget means over enough budget there is an amount of budget that's educated for the project manager what is project manager is responsible project manager is not only responsible for project planning and execution but whatever the budget was allocated he has to complete it within that limited budget itself so there will be of no extension of budget will be given sometimes due to improper practices of agile project planning improper understanding about the technical expertise of the team or maybe lack of coordination of the management team managing of the teams or whatsoever reasons because some reasons will be in our control some are not in our control right anything so sometimes cost over means budget was allocated but when the project was landed up successfully to complete it's considered as a cost failure project project is successful but whatever are we going to get out of it is nothing it's a cost failure because whatever we have taken and what we have spent on this has a difference if the problem is from our end we have to put it from our side if the problem means in terms of the changes in any kind of requirements if this is happened customer has to pay it right so this is all depends on the sla what we have prepared this is what we called as sla sls stands for service level agreement means service level agreement should be given by the vendor to the client based upon the understandings what we have in all we have to provide an agreement to the client so this much duration is this is in this within this duration we are ready to complete the project with all the required deliverables on that stuff we have to provide everything so we have to write down a document and we give so apart from the financials what we have discussed right so because what because again the financials will be different we go for some time some people go for fixer costs some people go for fte pixel cost means fixed amount of money we are collecting from the customer client is paying us fixed amount of money and we must ensure that within that limited budget we have to complete this is one thing but we have to make sure that no changes in requirements should be taken place if any changes done by the customer again negotiations will be taken place with mutual consent this is what generally we do in fixes amount of money second is fte based we call it as full-time employment means for this project to complete how much manpower will be required based on that hourly calorific hourly billing right wherever how many dollars are we collecting from the client is what generally happens these are the two different once we have discussed all this so finally what is that we do is that so finally we have to provide and service level agreement to the customer so based on the service level agreement so we have to develop the project so the structure is entirely different but whereas when it comes to agile of course whether you are collecting a final a single amount or you are collecting ft whatever it is but the value system of agile is something different from the traditional way the values systems are for the first part especially agile is depending on the first part is that individual interactions over process and tools here the understanding is that it doesn't mean that there is no process or there is no tools process we follow agent we follow tools and all everything we follow but more than that we give importance to individuals and interactions this is what generally we call it as scrum meetings or daily scrum meetings or daily meetings with stand-up meetings or different different things so regular meetings and regular interaction among the people is people happens in agile environment normally in traditional way of approach if you see from a context of a ba when customer a business analyst wants to transform requirements or translate requirements or to communicate with the technical team how they do that normally they prepare some documentation they give this is how generally brd srs all these will functions if any changes happens in between in terms of the requirements again those requirements will be changed in the brd all that stuff this is how generally the process we follow in a traditional way there are difficulties sometimes we may fail in delivering the right thing on the document sometimes whatever has understood may understood may not be understood in the right manner so there are possibilities that communication gap in terms of written as well as the verbal might happen verbal or written might happen communication gap may happen for some reason so it is always helpful when we have a regular interaction facility with the team members so that the communication gap will come down at the same time we can have a closed look on the work what they are doing right so how they are doing what they are doing to what extent they have completed so far what is that they have completed so we will be knowing about the progress of work right how much work they have completed so far what is the balance everything can be known to us at the same time person who is managing the stream and all have an advantage to see as well as the listen the practical difficulties what they are facing so that corrections can be done with immediate effect this is an advantage you can see if you are going for individuals in interactions so individuals in interactions because of this reason because in traditional model you don't have a facility because in traditional model there is no much interaction happens of course there is a part of interaction happens in a way of jarred i hope people who are coming from business and list they'll be knowing about this well there is a concept called judd as a part of requirement solicitation and collaboration we conduct session stands for joint application and development session which is happens in the initial stages of the project where we invite all the stakeholders under one roof where discussion will be taken place and final conclusion will be given there means what they have discussed right what is their expectation what is that we have understood all that will be discussed on the platform that is what generally we call it as yard workshop which will be conducted in the initial stages of the project not not occasional because not in regular intervals it's not possible in traditional way so there are possibilities that due to the communication gap project understanding as well as the understanding of requirements or sometimes it may leads to failure of the project also happens so that problem won't be there okay so why because there are individuals interactions will be happening in regular intervals with the team members so that what are that we are going to do today right so what you have what we have done yesterday what you are going to do today what are our challenges could be how to overcome those challenges all this can be discussed in this interaction itself so that communication gap will be much lesser i say much lesser as you are comparing with traditional model so this is the first agile value system which is under agile first part is that individuals interaction is first next second is that working software working software over comprehensive document so what is working software working software means there is because most of the people have some misconception over that there is no documentation in a joint it is not no document i say it is less documentation because documentation is essentially needed even though we are working on agile environment because not everybody will be experienced in a gym right hundred percent there are some people who are new to agile environment due to the communication gap or due to lack of documentation they should not feel any confusion over the work what they are doing even though they are technically strong if you are not for providing that visibility there are possibilities that it may leads to confusion over the understanding level right there are possibilities that's the reason why i don't say no documentation yes there are documentation which will be prepared in agile but not in the form of documentation something like word documents all that of course practically speaking some people even will prepare documents also that's what i have told in the beginning hundred percent they don't follow a jack they follow the traditional way of approach because they are used to because i don't say that is wrong because end of the day as long as we are very clear on what we are doing nothing wrong in doing it i never say it nor wrong because because their team their understanding right so there are things like sit there as long as they are managing it successfully as long as their completing is successful without having any difficulties or the challenges and all of them it's fine so we can't comment on it it is their team and all that but here documentation will be of very limited in percentage in terms of it normally there is a concept called con influence you might have heard about it called conflicts because whenever you want to work this application whenever you want to manage projects and all in agile there are numerous tools there are n number of tools something like jira rally windows video a lot of lot of tools are there among all that there is a tool called jira jira jira jira is a kind of tool which is used to manage the project followed by bug tracking all that can be done using jirasoft so in jira when it comes to the jira software it is completely used for project management so that we can write down all the user stories epics creation can be done at the same time there will be a product back here before we are managing all the product backlog all that stuff we were doing so all these things we were doing in the project itself so whenever we are working on this normally whenever we are working on the on this process normally there is a tool called confluence confluence is a tool which is used for document collaboration document collaboration means where if you want to write down some product requirements for example what are the product requirements we want to write the product requirements to write there is a option for you in confluence let's say as i told you individual interaction through scrum meetings daily scrum meetings we connect that's what i have told you so whenever we are conducting the meetings we want to update the meeting notes because what we have conducted so far what are the points we have discussed where we have concluded which is accepted which is rejected which is deferred right that has to be documented so for that there is an option called meeting modes so where we can write down all the meeting notes there so that people can see because if as we are connecting this jira with conflicts so that whoever are there in the team because whenever we create the jira as a project management we add all the people who are relating to the project all that so we are whenever we are adding the people whatever the updations and changes are we making everything can be seen by all these people so meeting notes can be updated at the same time if there is any kind of retrospection we do in terms of the sprint retrospection all that that also can be done so what i am trying to say is that documentation is very limited in terms of the percentage but it is in a form of conflicts this is what generally widely we are using now because that is that gives a value addition to the team when they are working on real environment because in the traditional way we have a facility for documentation to prepare we have all these brds srs all that stuff is there but whereas in agile you don't have the facility in agile we have a facility called confluence where there will be less in documentation so when it comes to this rather than the documentation we give more importance to the software working on software means whenever we get the requirements immediately we start working on the software itself and if there is you could ask me one thing then raj if there is any changes to be made what is that right so how we are going to do the changes whatever the changes are we going to do everything will be done accordingly so based on that changes will be made right so because in between when there is any change customer is expecting us to do so with the team consent of the team members and all based on the possibility changes can be done accordingly so there is no i don't say there is no planning for project in agile yes there is a planning but this planning is short in terms of the percentage there is no long term planning so the planning is confined only to the particular release we plan so whatever the work we do whatever the planning we do everything is confined only to the particular release within that particular release we have to complete this is what generally the working software is means you are directly working on the software rather than you are depending on the documentation so there is no because in traditional model because every time i'm comparing with the traditional so that you'll be understood better so if you see the documentation if you see a traditional way of approach if you are a developer on what basis development will be taking place development will be taken place based on the documentation called brd srs what you have received from the ba because they are the one who is translating the requirements in a documentation format and the documentation will be given to you as well so you are taking up the documentation you are working on that and finally you are delivering it right this is how generally the process you will be following so based on the delivery what business analyst has been given technical people will go through that and they whatever the functionalities they are preparing whatever the non-functionalities features everything is based upon the documentation what va has given but whereas in agile environment you don't have that facility you don't have that process because there is no documentation everything through interaction because whatever we have interacted whatever we have decided and accepted that will be put it on the practice with immediate effect without any second thought we are implementing it to the next level this is what generally working software stands for means directly we are working on the software not having any documentation on that so whatever the documentation in terms of the confluence we have and all everything is optional because that is optional because not everybody uses confluence all that right it's an optional thing based upon the team what they have decided if they want to con connect the confluence involved with jira so that document collaboration can be done so that people will understand more effective and better but which is not compulsory right end of the day it is optional right so it is not compulsory as it is right so this is the second point working software the third is that customer collaboration over contract negotiation so what is customer collaboration over contract negotiation means normal and traditional way of approach if you see closely there will be no customer or customer representative will be there in the project because customer is an outsider always an external stakeholder where customer has given the requirements whatever the work we do everything is being confined to the development team development team itself is doing all that activities customer representative may be sms and all everything was supporting us from outside and whatever the necessary information they want to provide they will be providing us everything from outside this is how general that works but whereas here especially in agile the advantage is that customer collaboration means customer representative will also be a part of the project development whatever the work we do customer will also be a part of it who is customer here customer is not a business owner right because if you see large mncs multinational companies business owner means it's all runs sometime with consulting right so with group of people there will be board of directors right so they'll be taking a decision there is an organizational structure right you have a ceo you have a cf course you over all that so all these multinational companies there is an organizational structure we follow so even though we have an organizational structure there is no customer who will be coming and hitting us in the project in spite of it there is a role called pivo normally in agile there are three different roles in that one role called po what is po stands for p1 nothing but product owner that role will be called as fivo stands for product owner normally this product owner nothing but client representative how practically happens i'll tell you let's say you are planning to develop a project your all you guys were belongs to one project right so you are a team of people who are planning to work on agile environment you guys have decided now you want to implement the project in a jail assume that you are experienced or you may be new to so if you are experienced and few are new okay what it is now here there will be a role as i told you as we call it product on the road this product owner will be appointed by the client in some occasions normally practically they will choose a product owner they will recruit a product owner some person who is knowing about the who's no who knows about the requirements well in advance about the project everything that person will be called as product owner means what customer wants what are they expected output right so all that will be known to the product owner so whoever is knowing that that person will be called as po normally customer will provide this po to us in the first level normally po will provide customers this is the first level whereas in the second level sometimes customers won't provide us the product if customer is not providing us the po what we do is that company itself will recruit when people on behalf of the client so what is that this you do this product owner is the person who is responsible to provide a quality output of the project as per the expectation of the customer this is what generally the product owner responsibility majorly lies on plus project owner is responsible completely on to that project owners is completely responsible of what they are expecting because they themselves were treating as customers so what is that i want is what i am making team to develop that is what generally customer collaboration means so when there is a customer collaboration of course every every every process has its pros and cons this is no exemption right even this agile is also never exempted because practically there are some difficulties of course that's a part of uh process anyway right so we have to learn new things and we need to adopt new new strategies and we have to move further right so it's a continuous process so there is nothing to say hundred percent perfectional thing of that sort right so because agile is not something new agile has been derived from the world models what we are using successfully at one point in time but due to the practical difficulties what we have faced over a period of time and all slowly the practices and the values systems have changed and we have named it as a gen right agile is not born new right it's not a newborn instantly due to the challenges what we have faced based upon the models what we have used and all slowly we have refined to the texting possible slowly and based on the challenges and the practical exam difficulties what we have fixed just a quick info guys intellipaat provides agile training mentored by industry experts the course link of which is given in the description below now let's continue with the session a new system called agile has been derived from the old ones right so that is not 100 entirely new because this is purely depends on so the same way every process or everything will have its own pros that's a different that's a known thing so customer collaboration the advantage for you for customer collaboration is that what is that they are expecting will be known to each and every person who is involving in the project well in advance that is one advantage you can see in customer collaboration because there there are less percentage of communication gap you could ask me one thing can you expect there will be of no communication back in gap if a customer collaboration will be there but 100 is not guaranteed because there is nothing called 100 percent everywhere 99 is what the standard thing is nothing is 100 so there are chances will be very less that i can say practically speaking chances will be less because product owner knows everything so what is their expectation what is that they want as long as if they have a clarity but subject to determine condition terms and conditions that product owner should have a clarity first because you could ask someone then as if product is so clear about the one what is their course obviously there are some conditions but if the product owner is confused on something right if customer product owner is not to that extent possible if he is doesn't have a clarity on something obviously there is a communication gap might be raised so there is a percentage of probability of percentage that thing will be there but the major advantage collaboration is that customer will be there with us all the time as long as we are working on the project so what are their expectations demands everything will be known to the team members well in advance at the same time what we have what we are doing will be closely watched and observed by the product owner because in a way of conducting regular meetings review meetings all that customer will be knowing about what is that we have done how far we have completed what is that not it completed so far because any practical difficulties when people are working on even though we do the our own practice prayer but end of the day this is there are some practical possibilities and complexities of implementation might be taking place in between which is not something guaranteed sometimes it happens that practical difficulties team might be facing for different reasons which because 100 that cannot be identified so for negotiation purpose also it is you have an advantage because customer will be there with you all the time there are possibilities that negotiations can be taken place with the customer so whatever we want to make some changes out of it can be done accordingly so this is another advantage where you can see in terms of the customer collaboration here so customer is collaborating with you all the time in a way of the role called product owner but remember one thing this is a role of product owner you see only in scrum if you follow practice of scrum then only you see this but whereas if you go for kanban or something like that sort you don't see any this product owner even the team members who are responsible to complete the task they themselves have to take care of all the requirements and all directly from the client so there is no middleman called product owner if you call privo as a middleman there is no product owner in kanban the same agile remember the same agile value in agile if you follow scrum the approach will be different if you follow kanban the approach will be different if you following can that so you'll be having more of product owner all that if you follow a practice of kanban again you don't see any product owner something that with whatever the development team normally those people we call it as development team right so even in kanban there is a team team development team we called so the team is responsible for the all the ones right so even requirement gathering everything will be looking after by the team itself not by anyone as product owner as separate but this is possible only in traditional scrum all that stuff but the value system customer collaboration yes means customer is directly interacting interacting either way whatever the way customer is directly interacting and whatever the requirements they want us to develop can be done accordingly this is why this is how generally the third point called customer collaboration means customers directly involving in the work what we are doing so that whatever the necessary uh output they are expecting everything every day because it's a day-to-day activity because agile is something confined to limited ones if you have taken up some spreading to be completed it has to be completed in two weeks time one week two weeks three weeks and four weeks and so on within weeks it has to be completed again in weeks it is converting into days back backward you can say right weeks week to days days to hours this is how generally the calculation is so each and every one hour each and every each and every hour is important each and every working day is important because normally whenever we take the calculation we take working days not the week not the holidays even any national holiday something that will be taken out that will we don't consider that if it is for example if it is weak we take five days into consideration no saturday sunday even in this five days there is a national holiday something like public holiday we will we have to take it out we have to consider only four days so when when when it comes to the planning right when we are coming when we see like how much land cover we have how much time we have to complete right if you are calculating all that stuff this is how generally we do so customer collaboration is what we do here right so this is third point next responded to change over the following plan means there is no proper planning i don't say proper planning not in other sense there is no plan perfect plan for this if there is a change which is inevitable which has been requested by the customer how to make this change happens how is it possible to implement the changes what generally the perception of the team will be having so responding to change means whatever the changes customer is expecting we have a facility that we do as what we can but this is with the consent of team normally we do it is not that as i told you that there is possible there is a possibility of changing doesn't mean that we do the changes with immediate effect it is not practically viable to do because that's a practical difficulty because whatever the spread sprint we have created for the sprint there is a scope will be defined for that particular sprint so how that scope should not be deviated if scope has deviated obviously the sprint the total plan of spring focus will be deviated by the team members so it will be impact impacted on the particular sprint what we have initiated and what we have planned so far everything will get deviated because of this so end of the day that is the team responsibility team has to decide team members have to decide whether is there any deviation can be accepted here or not so it doesn't mean that responding to change is accepted doesn't mean that we are accepting with immediate effect again subject to terms and conditions that it has to be accepted by the team members and again negotiations will be taken in place with the interactions will be taken place with the product owner with the proper consent whatever we have and all finally implementation will be taken place further so otherwise there is no changes nothing will be done with immediate effect so that's not practically possible and we don't do that also so these are the four different agile values which normally we use in agile so one is individuals and interactions is what we do first because we'll be focusing more on individuals and interactions means day-to-day interactions will be there in a child this is what one value first point second working software we are directly working on the software as we are not following any kind of documentation as separate because interactions we have made so based on that we start understanding and start working on it that's how generally it happens third is customer collaboration customer is collaborating with us all the time so what are their expectations everything will be known to us so that we can do it no problem next responding to change whatever the changes you want to do response is based upon the responses and all that changes can be done according so these are the four major values this is also called as agile manifesto so this is basically agile is being focused more on if you're if someone is asking you how different from traditional to agile is this this is the difference you see from traditional digest on a high level note in terms of the agile manifesto is concerned this is these are all comes under the agile values or we can call it as agile manifesto also so this is all about agile introduction how it is different from the traditional agile itself at the same time what are the different different values as well as the manifesto principles which we following if you see agile see agile is an umbrella right if you can take hl as an umbrella right so if you see agile as a way of approach or emblem or a methodology whatever case there are different different framework frameworks processors will be there under ajay honeyscrum scrum is a framework remember right scrum comes in the framework chrome is a framework next xp we have xp stands for extreme programming extreme programming next we have one more called kanban right so kanban is a model is a development model especially this is a japanese model kanban which is something close to lean process all that stuff this is one thing handmade next we have other process called rup transfer rational unified process this has been powered by rational software corporation earlier it was their rational unified process right and next we have other process earlier normally this agile and all everything is derived from this dsdm stands for dynamic software development methodology right so these are the different different frameworks and processes which are there under agile somebody follow scrum somebody follow xp somebody follow kanban rup dsdm so normally they all not all these major ones are these these three i can say simply because i don't want to make you confused by putting all the information here major major things is scrum xp kanban these are the three major things which will be part of under agile some people follow exclusive scrum some people follow exclusive xp some people follow candidate sometimes scrum with calendar combination right that is what we call the scrumban scrumba in scrum ban scrumban is i'll give you an example for example your work you are providing a solution for a manufacturing unit automobile sector normally automobile people uses a process called lean lea and lean processes in the beginning in the first session i think i might have given this point if i remember i'm not sure lean forward lean process is the one which is being used to minimize the production loss in terms of the time right so they want to maximize the effort quality delivery all that within the life limited timeline they want to make utilization of the time quality of time will be used wastage of component spaces of time everything can be minimized using this lean process in the clean process there is a process called kanban which they will be using here customer right now whenever we are following a practice of scrunden what we do when we are implementing scrum we follow practice of scrum and canberra also sometimes crumb it can be sometimes crumb sometimes only xb right sometimes scrum with traditional model something like as i told you in the beginning right we follow agile underline normally we say that we follow but whatever the practice of development we do everything we follow the traditional way hundred percent agile won't be used traditional way of approaches will be the major part 60 percent traditional 40 percent design i don't say wrong right so depends on the team depends on the experience what they have so depends on the comfort this will be varied so whatever the frameworks processes and all everything part of agent somebody follow scrum somebody follow xp kanban it's entirely different depends on their experience what they have added layer at the same time what they believe for some people follow uh think that scrum is the right thing right some people feel that xp is the right one so end of the day that is their discretion team and management discretion with that whether which process they are following and all everything will be decided by the team itself they have to take the decision on it not by the anyone else apart right so they are the one who is taking the decision on that clear to you is it clear or not normally when it comes to the product owner rule customer will be giving you the person right the customer will appoint a product owner for example i am the one right so customer will give he's a product owner he'll be taking care of all the product requirements and all everything from here onwards he'll be organizing all that stuff right this is one thing for some projects this is how it happens customer will give you the product owner point number one in some cases there is no product owner given by the client so whenever the team management whenever the management has decided agile and all that so they recruit product owner as separate this product owner is the one who is working on behalf of the client that's how it happens that one or this one and whatever the principles i am explaining you here what are the call principles and all everything are behind under the agile manifesto the same points whatever the points we were discussing on the value system the same thing will be repetitive here the first point under agile principles is that we give high priority to the customer satisfaction so customers will be satisfied when we are delivering it on time followed by this whatever that they are expecting from us so whenever we are delivering customer will be happy so the major priority is machine and agile is to provide the value-added services to the customer within the time limits which was finalized so far right this is what generally the first priority second point is that changes can be done at any point in time whatever the changes we want to make in the process of application development even in late development normally in the traditional way of approach if you see changes whatever requires to do in between the project in middle of the project is difficult i don't say it is not possible it is difficult due to the again you need to go for analysis right so someone has to do the analysis part someone should do the planning and design part after that someone has to do the coding part so lot of people are involved right so different different people are involved for different activities so coordinating them again reworking on that takes lot of time and energy manpower automatically when manpower has increased automatically operational cost will also get increased at the same time we have to make sure there should not be any kind of technical complexity but whereas when it comes to the agile environment the approach of agile development will be in such a way where whatever the work we are doing everything is something relating to the user story because this is how generally user stories comes into play what is user story i will tell you sometime we'll start i'll explain about it so we will write it on a shorter format in simple terms i can say what are the requirements we have normally in the traditional way of approach we write documents like things like brb srs all that and whatever the functional non-functional requirements everything will be written on the document itself but whereas when it comes to the agile environments is concerned whatever the requirements we were writing everything will be written in a shorter format that is what we call it as user storage transfer so that user story has independent on its nature so whenever whatever the changes to be made into the existing one can be done accordingly so that is the second point advantage in agile is changes can be made at any time any point in time but there is a difference again if you remember yesterday i have told you whereas in scrum there is some difficulty means there are some challenges whereas when you follow kanban practices and all that can be done but still hundred percent as i said like hundred percent there is no other so there is but still it can be manageable right so that is the second point third is that whatever the delivery of the work we do normally it will be on the beach time usually in agile environment if you see the agile as in high level especially in reference to the traditional model when we are comparing first at least to complete project it will be taken not less than eight months to one year right so this is the this is the minimum thing for any project to start and to complete it but whereas when it comes to the agile environment as i stated earlier this is all focused more on the release because release planning is what will be done prior so based on the release planning implementation will be taken place so whatever is that we have started or whatever the release we have initiated so far based on that implementation will be taken place so when we talk about release release is not something full for the whole project right so we are not taking the whole project into an account whatever is required for the customer is what will be taken initially so that piece of work will be done so if you are dividing that into consideration assume that the release planning we are making in three months of time this three months can be divided into weeks right for example if it is three three months four into three and on an average twelve weeks right again these weeks will be converted into days days into hours so whatever the delivery of work we do especially in reference to the agile itself is concerned everything in short iterations when we talk about short iterations and it will be based on the weeks normally weeks are the one we consider weeks are the point we consider into we'll take into consideration weeks are the one we'll be taking into an account this is the third point under agile the fourth point is that even business people means business cross-functional tips in simple word i can say fourth point is that cross functional teams because there will be a difference between the business functional people as well as the technical people because functional people knows about the functionalities of the existing process all that stuff maybe a business analyst is one one of the person who knows about the functionality not only that even business users all that people right at the same time technical people technical people means development team testing team all that normally both all these people usually these two people will do different things right functional people who are externally supporting us except ba reminding other people will be within the project and they work accordingly this is how usually the structure follow everywhere but whereas when it comes to the agile itself is concerned even business people development people all these people works under the same platform this is what we called as cross-functional teams everybody works for the same course everybody's target is to complete whatever is being identified and finalized right so everybody works towards that hence there is nothing as that i'm only confined to this because especially in agile the major difference you see from traditional to agile is that you need to have a multitasking ability that is essentially needed of course even though you are a developer you may be expert in development or as a part of that you may be good at coding all that stuff so apart from that what else the what else is required for us is to know about the other aspects as well means you must be good enough to participate in a group and see right not as an individual in a group you may be required to work as in into analysis maybe you may be required to participate in planning and design not only to implementation testing if there is a requirement so we have to cross we have to do those points as well so that is one thing so multitasking is something essentially needed in agile because small iterations we are taking that to time frame it's completely based on the time frame so that if someone is absent on behalf of someone someone has to take that responsibility this is what generally the fourth point is the fifth point is that whatever the projects we were developing everything is based upon the motivation of the individuals all that so it's all a group of uh activity we do everything is depending on the trust as well as the motivation among group which is essentially needed especially happens in agile as well next sixth point is about sustainable development whereas whatever the work we do everything is in sustainable mode means you don't see any kind of gems and all anything which are huge in percentage right so because whatever the changes in all everything we were identifying those changes and we are doing it parallelly depends on the possibility whether are we keeping it in the present one or we are transferring it to the next one is what we are doing anyway as i mentioned earlier so there is a possibility of sustainable development especially in agile is possible when we are comparing with the traditional model because if there is any volatility in requirements taken place that is really difficult and challenging task here right so whereas that part won't be there in agile because we have an assurance that changes can be made at any stage so structure of agile will be something of that sort right so this is the sixth point at the same time whatever the work we do the seventh point when it comes to the seven point whatever the work we see everything is based upon the progress of the work right measuring the progress of the work is what measuring of the work is means whatever is promised what we have assigned what we have completed is what we see this is what generally happens in a jig at the same time eighth point is about face to face conversation if you can see the first point i have mentioned you individuals interactions where there will be lot of interactions because especially in agile if you if you are working on agile especially in agile teams all that stuff whatever the interactions we had and all everything is the major aspect means face-to-face interaction among the team members is what normally we do normally this kind of nature you don't see in other ways in the traditional model if i'm communicating for example if i'm being a business analystician right so i'm the one who is translating my requirements into the technical format or a business related format i'm preparing documentation my documentation speaks not me all the time i'll speaks when it is required but most of the times my documentation speaks you know on behalf of me what is that i want to present everything will be there in the documentation but there are some difficulties because sometimes people may find difficulty to understand what i have prepared it may be due to because of my mistake or sometimes maybe they may be in a position to may not be a position to understand those properly so these kind of problems might be arranged in long run because the projects will be of very uh very large in size right it will not be there for two three months all that stuff will be taken at least here year and a half to complete so it is always helpful especially in terms of the short-term deliveries it is always beneficial to have a face-to-face conversation among the team members which is essentially needed but because we don't have that much time even to prepare any documentation because for example if i am the one who has understood the requirements translating into document and again providing it to you takes lot of time for us so that much of facility you don't see in agile so that's the reason why it is always we are depending more on face-to-face conversation that will be that will happen in a format of normally we do like scrum meetings and all we call it as scrum meetings usually scrum meetings will be conducted day to day every day for about 10 minutes visit we discuss about the team members will discuss about what is that we are doing right how we are doing so what are our tasks to be completed for today right so what would be the challenges how to overcome that so everything will be discussed on day-to-day basis so there is less part of less chances of the complexity or less chances of the confusion over the team members due to this problem this addressing thing addressing mode right of conversation next continuous patient attention towards technical excellence is also there that is one thing at the same time part of maximizing the work which is not done so for that generally there are some report generations and all everything we do usually scrum masters are the people who normally prepare this velocity charts all that so using those velocity charts they come to know what is that promised and what is that we have completed so how many more how much more work is there for us to complete so for that what is that decision to be taken based upon the reality what we have understood all that will be done by team scrum masters usually they prepare different different charts that's a different thing next architectures requirements and all everything will be done by the team itself because you don't see any exclusive architects because if you see for any application development especially in reference to the traditional i'm comparing you might have heard about it in a role called solution architect solution solution architect means the person who developed architecture for the project who creates a roadmap to develop the project from the technical point of view unless until if there is no technology which is integrated because when you are developing an application application normally if you see from a high level mode will be of three different layers normally first layer me explain you on the word we understood better normally if you take any project project will be of three layers the first layer we call it as presentation layer we call it as business or logic layer third will be called as data there is a constant connectivity between these among these three is important presentation layer means what you see on the screen business and logic layer means whatever the code we write everything comes under business and logic for example oneplus 2 you have given whenever you press enter button you are getting a reply call 3 being a user are you doing an addition here no there is a program which was written by the developer in back of it for edition not for one plus two right it may be one plus two or it may be 500 plus 300 so a developer has written a program for addition so based on the program what they have written and all you can see the output there right that is what generally so the logic layer so where logic will be implemented here accordingly this is the second thing the third is data layer means whatever the data we are uploading right through we are presenting through presentation layer everything will be stored on the data layer itself of course for the database designing everything has to be done by that database designers all that further followed by this if you are extracting the data for report generations and all everything so there is a connect among these presentation business logic layer data layer all that stuff so which is something technically connecting with this this is where generally a solution architects are the people normally come from the technical background because architects are the people we consider them as technical people not the functional ones because functional ones never become solution architects because solution architecture is completely a technical thing whoever is having more than 10-15 years of experience in developing technological technical applications for different different clients whoever is having vast knowledge about the technology transformation programming coding part all that stuff so those people will become architects normally solution architects is highly recognizable and important role for any organization especially for project development it is one of it i don't say that remaining other other roles are not important but this is one of the important role like this is what generally the players and all about so there will be architects normally traditional model you can see the architects all that stuff but whereas in the application development in reference to ajax whatever the architectures we prepare everything will be done by the self-organizing team self-organization team need not be a developer even architect can also be a part of self-organizing team right so you don't see any person as separate even an architect whoever are there as separate right so that architect may also be a part of self-organizing team sometimes otherwise these people are well experienced in terms of the technology all that stuff these people can also become architects so they can develop architecture as what they understood so far all that so this is another point here at the same time whatever the uh requirements because behavioral attitude behavioral tendencies understanding about the team efforts teamworks regular intervals and all everything is also needed so these are the major 12 principles which are there behind agile manifest so whatever the points we have discussed in the agile manifesto the same thing will be reflected under the principles now we were shifting our focus from agile to the next clip so the next level is this you can see this umbrella whatever the umbrella you can see in an umbrella format you can see that because as i mentioned you agile is a process or a way of approach there are different different frameworks and processes will be there under agent there are some processes something like scrum kanban lean dstm at the same time rup rationally infinite process all that right so different different uh just a quick info guys intellipaat provides agile training mentored by industry experts the course link of which is given in the description below now let's continue with the session frameworks and processes will be there in agile depends on the expertise what the team is having depends on the requirements and the need whatever the model we were choosing and all everything will be varied normally when we talk about team one team and multiple teams you can see in this umbrella you can see for one team or for multiple team so the difference is very simple one t means the combination of product owner or developer tester all these put together somewhere around 10 people this is all called wanting sometimes one team is sufficient for you to complete the project so when the project size is very small in complexities also small usually one time is sufficient but it will not happen in all the cases because because all the cases are not something the same because the case will be different from one another it will not be the same so sometimes you require multiple teams to work on the project especially in large scale enterprise transformation level where whenever you are transforming the whole organization to the enterprise level format where you have to deal with multiple things the application will also be very large in size complex in percentage so you require multiple teams involvement at the same time you need to have a proper coordination among those things so this is what generally a concept called scale design framework we call so more than agile i can say in simple terms i can say more than a j we have other other thing next level is called safe safe scaf is safe safe stands for scaled agile framework this one scaled agile framework means agile square i can say right agile into agile so this is what generally is scaled agile is means for large scale transformations when you have multiple teams when there is a coordination is required so scaled agile framework can know everything use so you you are following skilled agile framework again there are different models for that spotify all that stuff that's a different story so different different frameworks agile is having so whatever and whatever the process and frameworks people follow they have to be abide with the value system what agile is having followed by the principles which was identified and defined so far everybody has to follow the same so there is no deviation here but the way of approach when we are dealing the project kind of depends on the kind of framework we have the process framework or the process we have identified or we have chosen at the same time the kind of experience what we are having or what we carry it depends on it it will not be remains same for everyone it depends on the kind of expertise what we have depends on the kind of team what we have in all everything these things will be varied here so but here is a question because yesterday also i have counted this point because most of the people will have it out here as we heard more about scrum than any other elsa part if you have if you have an idea earlier of agile i'm saying that somebody whoever is having a basic knowledge about agile can ask me a question that raj we heard more about scrum than other things other can ban xp we heard very less about this than scrum what could be the reason right this may be a question might be rise to the people who are already known about agile earlier the basic one i'm saying the answer is very simple agile in terms of the implementation of the project especially for the people who are new to agile especially people who are new from traditionally you are experienced traditional model you are used you are worked you worked as a developer tester and something of that sort earlier now team has initiated now organization has decided to implement a project in agile environment so the team is very new right so even though you may be having experienced people maybe you can count it on fingertips either you need to hire people from outside or you have to train your people from other external sources you have to do the either way but reminding other people who are working on the agile and all everything will be normally those people will be blind right so those people don't have any experience already so for these people scrum is a framework which is highly useful to them rather than xp can be because xp can bene even though it has its own popularity in terms of the complexity in terms of the addressing system all that has some difficulties difficult i don't say it is not technically strong it has its own difficulties something like development approaches will be there if you take xp something like extreme programming all that so there is an approach called programming test driven development so different different approaches normally we follow at the same time kanban is a model something development friendly developer friendly pair tasks boards everything will be designed at the same time whatever the work with everything has to be taken care of by the team itself so there is no specific person earlier but whereas in scrum it's not like because because why are we going because friendly as well as easy to people to understand as well as they know that's the reason why more prominence is there first at the same time success rate and as well as the usability is also more personal that's the reason why we have got a good system other than demanding things so our focus normally will be unscrupulous right so this is what one point means now especially in reference to the scrum when you're talking about scrub then as i told you if you remember when i explained about the comparison between the traditional and to agile teams as i mentioned you it's a self-organizing thing at the same time team size will be limited isn't it right that's what i have told you that's the reason why first of all let us understand what are the different different roles to be there in agile the first thing what you need to know because we have known about we have understood about agile but what is an agile case what are the value systems values manifesto principles everything we have discussed at the same time what are the different different frameworks and processes are there in the region we have discussed now we need to discuss about scrum why is gram for what reason all that so that also i mentioned but in reference to the scrub there are roles are there because if you see traditional model you can see like project manager business analyst architects developers testers all these people will be there but whereas when it comes to agile it is a different thing it's the process will be a different completely different instagram normally there are three different roles yeah so this is the diagram yeah so this right so especially in agile the roles will be three remember these roles you can see in scrum whereas in kanban explainer this kind of thing won't be there because the complete team only team will be there team will look after each and everything so that is one kind of uh i don't say drawback this is that that is that nature of the scrum xp will be that certain right so i am nothing more but this is something easy for team who are newly to trans newly transforming to agile it is more helpful to them because whatever the rules whatever the agile we have and all everything because people were adjusted to the rules right so earlier designation because you have a project manager who will be looking after that there will be an architect who is taking care of the solution architecture right so all that we have seen because people who are from the traditional model were experienced with that now when it comes to the agile itself is concerned agile is all rule specific as i mentioned so this is more connecting is it is because people can transform themselves easily here so that's the reason why people will be more about agile roles here normally in agile in reference to the sperm itself is concerned it is all role specific where roles will be divided for three different things the first role we call it as product owner you can see here on the screen second will be called scrum team followed by scrum master you can see three different roles in agile one is product owner second scrum team followed by scrum master three different roles now what a product owner and whose product owner is right so this is the first and foremost version we need to understand product owner usually the role will be played by an individual who maximum focuses on the what the customer expects means in what way we have to provide value-added services to the customer is what generally the perception for any product owner product owner never thinks from the team perspective there is a there is a clear difference between the role of a product owner and a scrum master in a high level note product honor always thinning from the customer perspective scrum master always thinks from the team perspective but he must make sure what is that product owner want he has to meet finally but at the same time he has to take care of the welfare of the team also scrum master so that is the fundamental difference apart from the remaining aspects the fundamental difference is that normally product owner is the person yesterday also we have discussed the same point let me repeat the same product owner nothing but client representative first point this will be this role will be recruited by the customer usually if you are developing a project server for example from xyz organization we are developing an application product owner will be their person their individual whoever they are sending it is immaterial to us but product owner will be there the fundamental thing is that product owner if he is a product owner he or she is a product owner they must be having a clear understanding about that what is they want what they want should have a clarity for them for sure first whatsoever reason they should have a clarity if they are missing in clarity then go on everything will be good everything will go away so a product owner should have a clear understanding about what is that they want what is that they are expecting from the people so that clarity should be there for a product owner that's the reason why most of these peoples and all everything comes from the customer side point number one if not if nobody is sending so we have to recruit a product now here is here we need to understand one more point there is a role called ba in in traditional way of approaches you can see actually business unless you can see so business analyst is the person who will be taking care of by the business requirements all that normally earlier used to have in the traditional in the beginning days when i started of course in the in the area of 2001 sometime even i could see i remember usually we used to have two different roles in application development when we worked on project we used to have two type of analysts earlier now it was changed anyway the transformation has been taken place earlier we used to have two different roles so one is business analyst second is system service is to have two different roles business unless means completely focusing on the business perspective business requirements all that system cell is completely focusing on the technicality means if you want to develop for example there was a point of sale system what is point of sale system point of sale system is a billing system the billing system we are using normally in retail store whenever we buy the products against to the billing all that stuff whatever the building happens that is what we call it as p wise point of sale system now a customer wants to develop a point of sale system because assume that there is an existing poise customer has some difficulties in using this poi assist because the application was very old they were using for very long time the present situation the volume of business has increased lot of features were involved a lot of services of the business services have increased so that existing application is not performing well so they want to have some solution to be taken into account right so they want someone has to provide solution for that usually if all these activities will be done by the ba whatever the business related thing functional related whatever the solution they were understanding so by understanding the existing process followed by proposed future all that by keeping all these in mind business analyst will give you the business solution now technical solution technical solution means how you are transforming from business to technology is what we call it is technical solutions transfer understood right business solution is different technical solution let me explain you that first so that you will be having a clear understanding what is business solution what is a technical solution let us say there is a poise application let's say there is a py certification customer is using for very long time now due to the configuration is very low because assume that they are using for since last 10 years the configuration was very less at that percentage of time because that time the volume of the customers were also very limited to them now the customer base has increased the amount of time for billing should be very faster but it is not happening due to the configuration issue because the configuration is very slow because old configuration second they want to generate reports online they want to see because they have multiple stores in different locations they want to see everything online but they couldn't do it that is second point third if there is any problem in terms of the technicality because end of the day point of sale system is an application under server system right so it's a hardware device if there is any problem someone has to come and troubleshoot it repair it till the time that system will get halted for some time right so pressure will be more in the other other rows this is how generally the practically the customer is facing the problem now customer wants a solution to be provided first so for this please address right so these are three problems one is configuration is very slow you want someone has to upgrade the configuration is the one thing second they want to generate reports online this is the second problem third problem is that if there is any kind of repair comes across coming across someone has to troubleshoot for that it is taking a lot of time so more pressure will be on the other other rows so this is the problem they are facing now a business analyst what would be a do a business analyst is the person try to understand this assume that developing a cloud-based poi system is what the solution a business analyst has been identified what is cloud-based replication cloud-based application means whatever the pos application we have will be developed on the cloud environment something like either by using like windows azure or something there are different different cloud service providers nowadays we got so they identified a cloud service provider and they want to develop an application on cloud because of the cloud system the advantage is that they don't require any kind of infrastructure even a small retailer or a mid-level retailers can use it what is that they require is a laptop or a desktop with a proper internet connection so they have to make sure that right they need to have a proper decent fast internet connection is required so that they don't require to maintain any data nothing everything will be uploaded on cloud whatever the reports everything will be uploaded in the cloud itself will be generated because there is there are templates available there if you give the figures numbers and dollar automatically reports will be generated is the assume that if it's a business owner wants to see all that so they can see anywhere online at the same time there is nothing for repairing everything right so there is no repair nothing because it's a cloud application management will be taken care of by them and that it's cost effective it will not be much faster for you right so what are the services customer is using for that they have to pay paper use kind of stuff now the developing cloud-based view point of sales system whatever business analyst identified is what we call it as business solution okay now to develop that how to develop this what technology is required so configuration related things even though it's a cloud we need to identify right so these things normally takes care of the system service i'm just giving an example this is how earlier was in the beginning days but now the slowly the transformation has taken place nowadays now we were we were calling this as nowadays you can see in job profiles we can call it as business systems and list this is how the transformation has been taken place in most of the profiles i'm staying somewhere other way you can say a business analyst also but normally because the point is that earlier you don't require any technology because technical expertise and all everything was not much required because when we started our careers in the year of two thousand one two three you don't require much technology required because there are technical people who will be looking after all that but now the situation was not that you must be i don't say that you must be expertise in coding development all that but the situation has changed in such a way person who is working as a business analyst should have a knowledge about the technology knowing about the technology transformation of the technology how it is changing so that sort of understanding is required so that is how generally the transformation so this is what generally the role of a ba in short right this is what b now most of the people will have a confusion here raj if i am a business working for for about five years or ten years in application development wherein i am experienced in traditional model but now in agile what is that my role will be right so what role will i be playing fundamentally one thing if you talk about agile environment or agility you don't see any role as project manager or a be no role as be a project manager nothing so whoever is working under agile environment must be there especially in reference to scrum again i'm repeating you'll be under these three rules either you will be as product owner you'll be a scrum team or elderly or else you will be under scrum master most of the times most of the times if you are a business analyst most of the times chances will be that you will be acted as a product why because if you see the responsibilities of a product owner comparing to va it is all all more of similarity right you can see the similarity between those two things that's the reason who are working under business and list chances are more that they become product owner why because product owner is a client representative the cellist is also a client representative hence product owner is a role but nowadays even we also see practically they were they are taking they are taking even business and list also because business project managers also people were taking for different different reasons because they require some additional manpower support that is the reason they are taking but if you are a ba when you are transform your kid to agile normally you will become a product owner because the roles and responsibilities for something similar hence product owner is the role so this is one thing i must tell you because i could see some persons who are relating to ba the reason why this is helpful to them i hope right so this is point number one next what product owner do right so as i stated and earlier mentioned product owner is the person who will be focusing more on about what is the customer what's and what customer requires this is what generally the product owner mentality will be so always things from the customer perspective right what product what customer wants what customer demands this is what generally so a product owner is the person who has to define the goal and vision of the product this is the first responsibility what is goal and vision goal and vision means what finally we want to achieve let us take our point of sale system assume that assume that let's let's because i have taken example of keyways right let me take the same example here we want to develop a point of sale system right this is what the customer required either it could be a cloud cloud base or a traditional whatever whatever it is but they want a point of sale system to determine so what should be the reason c developing a py system is not an individual entity in the organization because it's a part of the business to take a retail store point of sale system is a part of the retail store operations directly or indirectly this py system is supporting the business right so if someone is investing money to you to develop a point of sale system for their billing all that there must be some goal and vision without having in goal and vision nobody is investing money right so a business owner is investing money for what reason for example i am a business owner i am coming to you guys and i'm asking you to develop a point of sale system i'm ready to spend some amount of time on that right so i want to pay you this much of money so why am i paying because directly or indirectly this pois application is benefiting my business it's benefiting my business in what way it is benefiting it can be benefiting it could be benefiting for two different reasons either it will be a part of enhancing my organizational performance because of this my organizational performance will be increased this is one reason it could be one reason or it will increases my revenue cycle anyone right so whatever the solution we provide for any customer across the world you see any technical application you take these are the only two things one is enhancing the organizational performance at the same time increasing the revenue cycle you can see any organization any solution any application be developed end of the day it lands there either it is helpful to enhance the organizational structure and performance of the present this thing or else it will be helpful to increase the revenue of revenue life cycle either directly or indirectly to the client so if you are a product owner resume that if you are a product owner the very first thing you need to know is that you need to define the goal and vision of the product the first thing what must be the goal i want to reach followed by vision normally this goal is of two different types business goal project goal two different things being a product owner the focus must be a business goal not the project work because you have nothing to do with project implementation all that because you are a business owner or you are a product owner you have a business goal this is what i want to achieve or this is what i want to reach in coming years or in coming months or in coming days and coming in hours this is what your business goal is at the same time vision right so based upon the business objectives goal will be having a vision because every organization is depending on three things any organization you take inception of the organization will be depending on three different things because you take any organization goodwill of the organization will also be elevated on three three things they have to be withstanding on these three one is objectives and goals point number one second vision followed by the mission right mission means how they are performing vision what they want to become business objectives and goals means what they want to do so every organization whatever the decisions they take business decisions everything must be within this this thing then only the company has a good will because maybe sometimes organizations may lose financially sometimes but end of the day good will not we cannot count goodwill in each and every time relating to monetary right financially of course financials required for a new organization for sure i think there is undisputed fact disputed fact but if you are talking about the goodwill of the organization its completely depends upon the kind of activities they are performing and what kind of services they are providing end of the day right so without deviating their vision which are deviating their business course and object is followed by mission right so there are some policies principles all that which you have to bed with so that that should be the structure right so if you are a product owner first of all you need to understand you need to define the goal and vision of the product so what is that finally we want to achieve if someone is developing a product to us this is what the first point so that clarity should be there the clarity should not miss permiss should not miss for whatsoever reason point number one now once the goal and vision is done the product owner is the person who has to create epics followed by user stories all that normally let's say a point of sale system is what a customer is requirement customer requirement means pure requirement is that they want someone to develop a point of sale system developing a point-of-sale system there is a hidden goal right so there is a business goal and vision which was already clear for customers they have because they conducted waiting right so they have before because see you are for example you are a business owner you are giving in a project to some client so you are identifying some vendor to develop solution for your project problem what is that you do being a business owner your team will decide first to discuss right so what are our problems right so what kind of solution are we expecting so situation of the business everything so first of all you need to have a clarity otherwise you don't come you don't go for blindly we don't go directly to the vendor and ask to develop a solution right so we need to have some clarity because when you go to the vendor line vendor will ask you because what is that you want right so what is that you are expecting from me at least to that at least for that extent we need to know about this so goal and vision is required point number one developing a py system is what the thing they have decided assume that now if you want to develop a point of sale system point of sale system must be having some features and functionalities isn't it what are the features for example these are the features let me explain it for example these are the features let's say it's a cloud-based application right cloud-based payment my system these are the features crm and loyalty right franchising and multilocation hardware and cash registers inventory management system so these we call it as features right large scale of solution is what we call it as epic okay epic nothing but normally we call it as feature but in agile we call it as epic nothing but large scale of solution large scale of solution is what we call it as a big transfer epic means this epic nothing but feature you can understand that in simple terms you pick nothing but feature large scale of solution is what we call right this is first thing now if you want to develop a feature what is that you require you need to have some features and functionalities means you need to develop some functional and non-functional requirements if you talk if you speak about epic is nothing but a teacher for example right if you talk about this as a feature every feature should be having some functional and non-functional requirements functional and non-functional requirements because these functional and alternate functional requirements must be developed then only the feature will be useful otherwise there is no point of using the feature i'll give you a simple example which is relating to non-linking so that you guys will understand much better now you have bought a car you are driving a car where you have used this car to drive to the locations wherever you want to go right so this is for that reason you have bought a car now there was a device called gprs tracking device which was given by the customer manufacturer tree for what reason gprs tracking device is being used for dprs tracking device is a device which is used to show you the directions because there will be some locations which are known not known to you if you want to reach the locations and all there must be someone to guide who is going to guide you this is being guided by gprs tracking device assume that gprs tracking device is a feature among different features well this is one kind of feature which is there in the car car nothing but project right understand that now feature called gprs tracking device now you are driving a car you want to reach to the destination point right so for that this device you want to use this feature you want to enable right you have to use it if you want to use this feature what is that you require first first you have to enable the location where you are now you have to select the location where you are now first point number one point number two you need to select the location where you want to reach finally right so whenever you are selecting these two you need to have an option for submit right so whenever you are submitting click on the submit or ok button whatever it is it will show you the direction how many miles or how many kilometers it will be taken for you to reach this is what the road it will show next you will be having a button called start right so whenever you start click on the start button it will tell you right so goes try it go left goes go right all that stuff once you have reached the destination point it will give you a voice message that you have reached the location this is either in the left or right hand side of yours right this is what generally the device is still new now assume that nothing of this whatever i have explained you so far was not there in there was not there in the future called gpr striking is this having any value for that just a quick info guys intellipaat provides agile training mentored by industry experts the course link of which is given in the description below now let's continue with the session right so it doesn't have any telling so if you're talking about gprs tracking devices feature when this is helpful when this is being useful there are some functionalities which has to be developed in this then only that feature has a value otherwise it doesn't have any value so what are those features whatever i have explained so far so those we call this functionality so every feature must be having some functional requirements now what is non-functional non-functional means how it should behave character of the functionality how we should behave this is what non-functionality non-functionality means performance scalability right so all that comes under non-functional let's say you have reached the location and you have crossed even after once you have crossed after three four minutes you have you got a text message or you got a voice message what do you feel when you are driving a car which is located which is the location you are which is not known to you right so you are simply you are driving the car anyway you have an idea that anyway you get a voice message right but after three four minutes or so you got it so what you feel usually being a person who is driving the car you feel that this device is not so accurate because it's not giving you the instructions to you prior right it's giving late maybe it could be for whatever reason so what is that you see you you will be deciding based upon the performance of the device at that limit so what features and functionalities we are developing for any customer end of the day that has to be performed well right so you are developing a for example you are using an e-commerce portal for shopping all that stuff so you have chosen the products you have kept all these in the cart finally you have edited something you have paid finally you have decided the products you paid the bill online using different different payments mode you have paid it now once you have paid if you normally the rule is that because normally these instructions by why i am saying all this because non functionalities will be explained by the client client will tell you right for example once customer has paid within fraction of two or three seconds he has to get a reply message what reply message sucks thank you uh thank you with shopping with us so that you will be receiving your products in another two to two to three business working days to your total step right so this is what the message then only being a user being a customer you feel happy right assume that it is it is delayed right so pay payment was paid it was debited from your account everything done but you have not yet you have not received any kind of reply message so far what do you feel right so you may feel susceptible right is it because it is detected in my account but i didn't receive whatever the reason could be right so it was delayed maybe 5 minutes or 10 minutes or 15 minutes so if it is happening every time right so if it is happens run time okay fine it may be because of server issue all that but assume that understand and think that way that it is happening every time so what do you feel normally you feel that it is inaccurate right so it's not so accurate as what we understood what we think of this is what we call this non-functionality so functional requirements are required non-functional requirements will also be there so normally whenever we are preparing documentation whenever a business analyst is preparing documentation these functional and non-functional requirements will be prepared on the document usually but whereas in agile area as i mentioned you there are no documentation and all everything what is that we have to do we are writing users to these so what is user story means whatever the functional and non-functional you are writing that is what generally we are writing in a form of user story so what is user story user story nothing but it's a short description of requirement this is what user students stands for just really nothing but short description of requirement so so epic has to be identified right so epic has to be created for every application it means large scale of solution or is in feature whatever it is so for every epic what is that you require you need to have multiple user stories either functional or non-functional requirements you need to develop some user stories for that what is user story user story is nothing but short description of the requirement for example customer wants you to develop a login page right this is one thing so how you are going to show this assume that you are a product owner right you're all belongs to the product owner isn't that your own product you want to explain the same thing to the technical team how do you do that in what way you'll be presenting this this you are presenting in a form of writing down the user story use a story very simple how to write user story that i will be explaining after the next session onwards you will be knowing it how to write user story to write a user story there is a template we follow that i'll tell you later so writing down the user stories all that stuff has to be done by the product model so there will be epic followed by epic there will be user story this is what generally we read but user stories can also be minimized that's a different thing user story can be minimized into tasks again tasks can be minimized into sub tasks all that we can do because whenever we feel in real environment that user story is having a complexity in order to reduce the complexity whatever you do that user story will be diluted means divided into multiple checks those we call it as functional tasks right so again those tasks can be divided into subtasks so that's a different story let us not go into it so creating of epics writing down the user stories is what generally and product owner has to do this is the second point now next creating and maintaining product background this is also a responsibility for you what is product backlog product backlog nothing but it's a repository to store all the user stories repository so all the user stories this is what generally a product backlog stands for because for example we were writing multiple user stories this may be crossing somewhere 40 50 60 user stories we were writing where are we storing we have to store it somewhere where are we storing all that information that store is nothing but product backlog product backlog nothing but it's a repository to store all the user stories in that so you are storing all the user stories so that based on the prioritization and all whatever the sprint planning and all everything we do it comes in the next okay so being being a product owner the major responsibility we do is that first of all we have to define the goal and vision of the product that is the first thing being a product and you have to do unless until if you are failed in doing this project or the work what we are doing going to do will be under the tool runs right so going goal and define a vision of the product is important point one next you need to develop epics followed by the user stories this is second what is a pic what is user story i have told you how to write and all everything that we discuss it later because our discussion is confined totally what are the roles and how it functions right so how to write and all comes under the next level how to write user stories for that there is a three step procedure is there that we follow at the same time when you want to write a user story there is a principle invest principle is there so based on the invest principle because user stories cannot be written like as as what we feel right because it must be having a value it must be having a quality then only that user story will have an identity and recognization otherwise there is no part of it so user stories that there is there is something like i'll tell you later right so this is user story next whenever you are writing down all the user stories there must be a repository to store all that so where are we storing all that this is where we call it as product product background so you are creating a product owner product owner if you are a product owner you have to define the goal and vision of the product is your responsibility you need to write down understand the picks followed by the user stories creating and maintaining product so this is what generally being a po you're responsible so most of the people who are from a business else background we landed if you are if you are into agile this is most of the times you will be a product owner in majority of occasions so i can say right this is one thing second next role will be called as crumpty what scrum team is this is where almost this is what i have told you that cross-functional teams like both developers testing team even sometimes you may be having a business or list or architects right user interface designers you and ux design is right user interface all these people will become sentence grunty means people who are responsible to complete the amount of work which was given to them is what we call it as grumpy scrum team nothing but development team in simple words because we are we are talking about scrum that's the reason why we are talking about scrum team right so when when people are using kanban and all everything they call it as development not scrumptious otherwise it normally it is considered and called as development team what is development team development team nothing but members who are combination of all those people will be under the same team so these people should have an expertise multitasking that is what i told you in the beginning itself multitasking is what essentially needed for the team members to perform right so if you are a team member if you are a scrum team member you must be capable enough to do it right from the analysis part to deployment and delivery you have to be involved in each and every stage means you must be capable enough to handle all that stuff this is what generally the scrum team responsibility is normally these people will be somewhere around seven to eight people in percentage for one team right if you have multiple teams seven into two right so this is how it is right so every one thing you will be having somewhere around seven to eight people in simple terms like two developers two testing team maybe one database designer a user interface designer maybe one but sometimes uh they'll be hiring a business analyst also right so because one business and list is a product owner you may be require one va who will be with the team members to coordinate different different things depends on their interest depends on their business they'll be adding people but the team members who are in the scrum team members are responsible to complete whatever the given task to them means whatever the task normally these tasks will be divided as a sprint usually we call it a sprints sprint development all that stuff comes into picture that i will tell you so usually whatever the activity means in simple terms whatever the task given the task completion is the responsibility of the team decision should also be taken by them normally in traditional model if you see project manager or project management team and all everything will decide right project planning all that will be decided responsibility will be more on their shoulders but here here is self scrum team is a self organizing team so there is nothing called boss there is nothing called pressure all that of course they have a pressure because when because in the beginning also i told you why tactically because as in as i am into agile coaching because i am an agile coach now so what i can what i could see closely because i am dealing with lot of clients i am dealing with a lot of business owners all that stuff what i could see is that why they are wanting transform their organizations or the projects into agile because they want to make everyone accountable responsible first see slowly when i am putting pressure let's see i want to make you accountable and responsible for the deeds what is that i have to do i need to give you responsibility for everything so i am giving responsibility automatically you will be accountable for sure right so i need not do anything for you right simply if i do that you will be accountable and you will be it means this is the persons who are not right i am saying right so this is not in a negative sense people some people try to escape right so people say that this is not my work this is not mine all that stuff for them this agile is the right one because they are accountable for everything they are responsible for everything responsible and accountable for everything that's the reason why multitasking is required means whatever the piece of work must be given to them they have to complete within the timelines that is what journalists grumpty must be capable of so whatsoever reason for example if i am giving two weeks time at any cost in two weeks you have to complete end of the day for that what is required team spirit team management is required team effectiveness right team dynamics all these were matters so no individual performances will be identified or recognized in agile agile hundred percent team effort self-organizing team whatever the decisions they are taking everything is belongs to them what work to start what to initiate everything that responsibility everything will be on their shoulders normally in the traditional model that's not the way task will be given these people will do it but here whereas in agile and all responsibility will be given to them so it is everything in there on on their shoulders they are the responsible persons of the deed which is being initiated which they have to work on so they are responsible for everything this is what generous crime team stands for so right from analysis planning design implementation testing deployment if they are completing two weeks for example if i have given a task where i am asking you to complete in two weeks means two weeks the whole thing has to be completed you cannot say that i just excuse me i did i do you cannot say that it is analysis or planning design two weeks that particular task whatever the user stories we have given to you you guys have to be completed in two weeks all everything right so testing everything has to be completed and you have to put it straight this is where generally cross-functional teams this is where generally these themes called as cross-functional cross-functional means everybody are involving in these activities and all these these people target is to reach whatever the goal and vision which product owner has defined if they are failed in doing it so there is no point in working on it because product owner will also always have a right to cancel at any time whatever the sprints they have defined and all they can a product owner will have a right to cancel any time so that that is what generally product owner will have that authority over the team all that stuff so scrum team is responsible for that now scrum master scrum master nothing but more or less a project manager no i'm not comparing project manager to scrum master because project manager those responsibilities authorities will be different practically speaking but scrum masters doesn't have that because that's the reason why scrum master will be called as like what i can say like scrum master will be more or less like a they are listening the team that's it right so they are listening the team and whatever the requirements they want to have write something like assisting the team right so whatever the challenges they are facing all that will be taken care of by the scrum master so scrum master is some more or less i can say project manager on i can say more or less to that extent possible more or less as a project manager what is what generally scrum master do fusion is the one person but scrum master responsibility and role is more important because they have to manage the team first of all first point right so they need to understand whether these people are capable enough to complete or not because some people recruit see recruitment will happen usually but we never know whether these people are capable to do it or not some people will hesitate to do some people are reluctant to work right some people will have some pressure right there because they are technically strong but these people will be if there is more pressure automatically these people will raise their hands this different different right so we have behavioral traits especially energy especially because because we are i if you can take mine as a profile i can say i was just promised earlier then i was turned as myself as an agent coach now i am in a jail coach exclusively right this is how my transformations so if you see a scrum master role or an agile coach because gel coaching experience should also be there for a scrum master so these people should also have experience in understanding the behavioral traits of the individuals behavioral coaching all this comes under a giant because it's not something uh like managing the team and you need to understand the behavior rights of the individuals because some people are technically strong as is stated but they are not there there is more pressure one right so they can't work some people doesn't have any technical knowledge because not to the text impossible but they know how to manage things so we have to deal lot of people and at the same time you have to make people to work in the stipulated timelines which was given here all that stuff same time scrum master it is also having a responsible to track the progress what is being given to them because for example two weeks is the time i have given i have to make sure if i am a scrum master i have to make sure that you guys have to be completed this week on time or not i have to see if you are not completing the work what will happen whatever the release date we have given will be a failure so being a scrum master i am responsible for all these so i have to track the progress of the velocity right so velocity means let's say for example there is one sprint i have given what is print i'll tell you later next session i'll tell you what is print there are different things when i explain about agile planning process you will be knowing about all this here because we are confined only to the roles and responsibilities so i am explaining all these things to you so velocity means for example there is a sprint which was given two weeks time four user stories i have given you guys have completed only three one is left even on the next sprint also you did the same four they completed one for whatsoever reason if this is the case i may be having a doubt that you guys cannot complete release planning whatever the release planning we have we may be failed so what is that i have to do being a scrum master i have to do this velocity planning all that right i have to see what is that i have given what is that you have completed where is the balance what is the balance so if this is the case these people are capable enough to compete within the stipulated time or not if not what are the things to be taken care of means how many sprints additionally i have to create all that have to do being a scrum master so scrumas is a different role and different content altogether this is separate so this is what generally scrum masters do scrum master on more or less i can say something like a project manager job skraz karma's like a project manager job there is from master major responsibilities to manage the team at the same time managing the regular works right reviewing the spiritual sprints all that retrospections on that same time tracking the progress of the work velocity all that stuff will be done by scrum must so these are the three different tools but apart from all above all scrum master should make sure whatever the given timelines whatever the goal as well as the vision which product owner has recall scrum must always try to achieve that's what generally the connect must be so then on the screen master the role will be successful otherwise there is no point of success here so these are the three different roles so all put together somewhere around nine to ten people you'll get one team consists of ten people one product owner 78 people of team one scrum this is all about the roles of hi now when we talk about scrum due to the rules which was decided which was divided into three different parts which make people to understand much better because the person who is coming from the traditional environment traditional project development can adjust to the strong framework and all everything in an easiest manner comparing to the other ones the reason why most of the people tend towards scrum due to one reason the reason of imparting agile scrum under agile and all everything is due to one reason is this at the same time flexibility of development and whatever the works we are doing and all everything will be in a form of user stories right this is what general user story stands for user story is nothing but a short description of requirement this is what general user story is all about so that user story development everything can be done in agile environment especially in scrum framework which is easy for a team members to understand the process well in advance that's the reason why most of the people go for scrum due to that reason but in that scrum whatever the rules i have mentioned so far we call it a scrum as well goes but majorly towards scrum because if you see xp and kanban because this also have explained you earlier because if you can see three major ones in agile one is scrum second is xp third is kanban so agile is a prominent one these roles you can see but in reference to the rules when we are comparing along among with scrum xp doesn't have any rules specific like you don't see any kind of product on our scrum team scrum master all that there will be a development team as a whole so the development team responsibility is to complete the whole thing right from the requirements understanding and completing the works and all everything is completely towards the development team itself but apart from that of course they are using different different uh software uh development methodologies something like pair programming tdd all that stuff that's a different story at the same time we have another process called canberra technology even in kanban methodology you don't see these kind of rules what are the rules we can see and all everything won't be there in kanban so again kanban has a development uh development team will be there so the team itself will be looking after all the things here we are writing down the user story but there you don't write any user story or something of that sort directly task will be taken and it will be implemented accordingly of course every framework and process has its own pros and cons anyway that you know well so whatever the rules we have discussed is product owner is the first role who defines the goal and vision of the product writing down the epics user stories maintaining product backlog all that next we call it as grunty members it's a combination of developers testers user interface designers it's a cross-functional team i can say scrum team is all about across functionality where people must have multiple skills because if you are a developer you cannot confine your responsibility only for development you must be capable enough to handle other activities also when it is needed so cross functionalities and multitasking is more required in scrum team so whatever the development of implementation and reference so the project itself is concerned everything will be looking after by this company itself followed by this the third role as i mentioned about scrum master more or less something like managing the team right tailing whatever the task team is doing and all that managing the task followed by this whatever the review how much work they have completed so far what is the balance of work so whether are these people who are capable enough to complete it or not if there is any kind of doubt instance what are the other strategies to be implemented to make to implement in real environment to make it complete within the specific release so for that how to track the progress of the work velocity all that will be looking after by the scrum mass system so these are the three different roles will be there in agile in reference to the scrum frame now apart from this scrum framework and all let me explain you there are things like something like scrum ceremonies because whatever the implementation of work we do especially in reference to the scrum and all will be off majorly off to few different things one is about scrum's harmonies second is we call it as chrome artifacts all that stuff so there are two things we need to discuss under agile scrub one is scrum ceremony second is artifacts so scrum ceremonies means how project is implemented or how product is implementing in scrum we'll explains about this crumb ceremonies and all these are the standard procedures which normally we follow when we are following a practice of scrum so it starts with sprint planning this is the first scrum ceremony so followed by this we do daily scrum meetings print planning means where we do the detailed planning of sprint all that so of course that will be explained next slide whenever i am explaining about agile planning process you will be knowing about the detailed part of this so the first is print planning where we do the whatever the splint be in order to develop and all everything will be planned so followed by this daily scrum meeting we call it as daily scrum meeting nothing but especially in agile if you see in the traditional model the difference is that there is a regular interaction with the team members this happens this is about uh sometime between 15 minutes every day normally we discuss like this is what generally we call it as daily scrum meetings or scrum meetings different different ways people will pronounce that normally we conduct meetings so the advantage of meeting is to interact with the team members who are involving in the project so that it will be easy for us to interact with the people and we will be knowing about what are their inputs and what is the task to be done to be today itself if there is any kind of challenges they are facing and all how to overcome those challenges all these things comes under daily scrum meetings on that this is the second sermon the third we call it a sprint review meeting review meeting means whatever the review process and all happens here followed by retrospection all that so these are the major scrum ceremonies which normally we follow if we are following a practice of scrum in reference to the product development we are working on agile environment apart from the vision creation product vision all that stuff these crumbs are minus has to be followed by the team members for sure so the team members in reference to the scrum team member as well scrum masters majorly these are the two different roles will be played an important one of course product owner will also be employed empire will be also be involved but in the level of sprint planning initially not in the level of daily scrum meetings review and retrospection because as i mentioned product owner is the person i always try to see in what way we have to satisfy the customer and wrong so review yes review meetings and all everything product owner will be involved followed the retrospection all that stuff not majorly into the cross fiction but review meeting yes review meeting product owner will be allowed attended but major role will be played somewhere in the spring planning because whatever the products backlog items do we have and all everything will be planned there itself so these are the different different sermons which normally we follow in reference to the spread so apart from the scrum ceremonies there are some scrum artifacts we call it as from artifacts means whenever we are implementing scrum there are some active facts we follow because if you want to implement something in sprint planning what is that you want to implement for what reason you are implementing what items are we taking and all everything comes under the product background this is the first and foremost thing we normally follow so product backlog is one thing from product background we have sprint backlog as well as the sprint increments product backlog increments refinement process and all everything are the three things so these are the three different things will be there in scrum artifacts so when we are implementing aptly products and all everything in agile not only the value system of agile values principles all that what we have discussed so far along with that one must be knowing about the artifacts of scrum followed by the scrum ceremonies all that right so this is wall report the overall view about the scrum so why scrum are we using for what reason and what is the value system scrum is having so what focus we are focusing on all these things as comes under the scrum pattern so now today i am going to explain you about the planning process because how different agile planning will be in reference to the comparison to the traditional model because in the traditional model you know if you remember when i explained about the sdlc process in the beginning i hope you might have understood like analysis planning design implementation testing right this is how generally the process happens that's what generally the structure we follow in traditional effort but whereas when it comes to the agile approach itself is concerned it is something different it's not something based on the traditional approach what we follow it is not something of that sort because the traditional way of approach is completely different to agile because agile majorly focusing on the release part because if you take a project let's say for example you're developing an code banking application for one of your customers you are not developing all the application at your time so what is that you are doing you are breaking down into releases right release one two three four so on so based upon the release planning what we have made so far implementation will be taken place so the release planning especially if you see traditional to agile when you are comparing traditional degree the major difference you can see is about release pattern means release planning will be made so based upon the release planning and all implementation will be taken place this is what generally so there is a difference you see from traditional agent for very clear because that's the reason why adoption and adopting two words agile planning process would be difficult for members to understand because the transformation itself is a difficult and challenging task for many of the people due to multiple reasons due to might be they may not have towards exposure towards agile environment earlier might be reason they may not be ready to face the challenges within the stipulated time to complete reasons might be indifferent but of course whatever the reasons it could be so one end of the day people have to understand the process of agile environment well in networks before they want to implement just a quick info guys intellipaat provides agile training mentored by industry experts the course link of which is given in the description below now let's continue with the session so if anybody wants to move towards the agile environment so they must be knowing about the planning process of the jail first so what are the steps means whatever the sprint planning review retrospection whatever i have told so far along with this product backlog right so whatever the items we have discussed even in the last week in this week as well till now so everything will be a part of the agile planning process which will be us different different steps the steps of agile planning process will be as follows this is what generally agile planning process let me explain you an overall view so this agile planning process completely into seven different steps total seven steps will be there in agile planning process means if you are implementing a product to the product a product in the any any kind of uh you're developing any kind of product for customer requirements all that stuff the agile planning process will be divided into seven different steps so this is for me you make it to to understand much better so i have just divided into seven different steps so that you guys can understand well networks the first we call it as product mission and scope second is about building out the product roadmap followed by this release planning which is essentially important as i mentioned earlier at the same time splint planning daily stand-up meetings reveal under cross fiction so these are the seven different steps you can see in agile planning process now let us understand how it is different from the traditional voltage because in traditional one as you know there will be in phase where we call it as analysis phase analysis phase means where we are trying to understand the business problem from the customer right so we need to understand the existing process what was their existing process right so we need to study about what is their proposed system solution they are expecting all that normally being a traditional team we study but here when it comes to the agile planning process there are two different things we need to understand so one is about the team who are involved in implementation of the project product at the same time even you can see from the customer and also this is where generally these product owners all these people will be involved now the very first step especially in agile planning process when we want to implement an application or a product in an agile planning process the very first thing is that we need to have a clear understanding about the product vision and as the scope this is essentially important for any of the product to start with why because creation of product backlog in addition to the product backlog creation creating the product roadmap for any of the project is different essentially important if you want to create a roadmap followed by the product backlog and all a team means customer i am saying from the stakeholders in the point of view they must be having a clear understanding about the kind of vision and scope what they want to achieve so far because if they are missing in clarity and understanding about the vision and scope what they want to achieve in the future right so whatever the requirements and whatever the expectation they are expecting from the agile part and all everything will become failure obviously because you don't see any kind of connect between these two because product owner not only a product owner about to that stakeholders itself are in a state of confusion where they don't have a clear understanding about the vignette scope hence obviously the product will become a failure here that's the reason why the very first step we need to understand about this is to create and as well as to understand the product vision and scope of the product this is where generally the planning meeting will be conducted in this planning meeting there are few points we need to discuss first of all we need to understand the need and goal of the product to be achieved so whenever we need to understand about the need and goal of the product we have to understand about few different things the first point in reference in reference to the first point i'm explaining this here so the first point we call it as clearly about the business need all that right so first point is this yeah first point is about clear business need end goal and how to achieve it now if you are a stakeholder if you are the customer wherein you want someone to provide solutions for your business problem the very first thing you need to have a clear understanding about the business need follow that followed by the end goal so when you are trying to understand about the business need as well as the end goal this may be for two different things for example as an example i'm just taking here for example first point customer type one i can say right i can write it as type type one because this business need as well as the scope goal and all everything will be for based upon the two different types first is customer as a product and expecting someone to enhance it this is the first point means type one customer has a product at the same time customer is expecting someone to enhance it means here there is an existing application which was there for the customer for a very long time customer is using an application for very long let's say there is a core banking application which customer is using for very long so now due to the business process changes whatever happens customer wants to upgrade this application to the next level assume that roughly i'm saying so what is what we want first of all you need to know about what customer wants to enhance and for what reason customer has a product and expecting someone to enhance it to that instead enhance it to the next level means it means they are expecting some features to add right this is the first type of thing right now the goal will be different that's the reason i have i've told you because when it comes to the goals there will be two different goals one is about the business score second is a project goal right so two different things we need to understand because most of the people will have a confusion here so one is business goal second is a project goal business goal is what client having right so this is what generally a business goal means what they want to achieve in their business is what generally the business goal is so towards the business goal if they want to invest some kind of money to be invested to have some solution obviously they'll be investing on the product whatever the project or a product goes whatever it is this product goal must be understood and defined by the team who are implementing you know they should understand so there must be a proper alignment as well as the connectivity between the kind of business goal what customer wants to achieve in connection to the product what we are going to develop if you don't have any connection between these two obviously it leads to a failure of them it leads to a failure of the product because customer is having a product assume that in the first case or in the second type might be anything customer is having some goal which they wants to achieve finally right so which for that reason he is investing some amount of money to develop some product for the future needs so that must be the product goal when someone is trying to develop the application if those two have two different uh understandings obviously it leads to the product failure that's the reason why there is a two different things one is business goal from the customer perspective as well as the product goal from the implementation perspective so do different things so being an implementation team whoever is trying to understand and who is trying to provide solutions for this kind of projects products all that stuff they should understand the kind of business goal what customer wants to achieve finally unless until otherwise developing a product and all according to the reads of the customer and all would be really difficult and challenging so this is what the point here so the first type is this second type 2 customer is expecting us to develop a new application normally this proposal we may get from the customer or we may be providing i'll give you an example between two things for example there was an application called core banking being used by one of the bank for a very long time now their business model was there but still there are some changes in terms of the lines of the services has added in recent times due to that reason they wants to add some new features and functionalities into the existing ones whenever they wants to add some new features and functionalities what is that they need to understand they want someone to develop to new features and functionalities to the existing ones compatibility is the issue this is where generally feasibility study comes into picture assume that your all belongs to the development team assume that i am the customer i am expecting you to develop a core banking solution there was an application called core banking where i am expecting you to add some new features and functionalities assume that now if i came this if i came with this proposal to you you are into implementation understand this way right so your all belongs to the implementation team what is the first thing you see apart from the financials apart from the remaining things all that stuff see first of all you tc the first point is about the technical feasibility financials of course that's required but keep it aside for some time technical feasibility is what normally you consider first what is technical feasibility assume that the application was developed on.net i'm using this for from past 10 years now i'm expecting you to add some new features and functionalities to the existing one the existing technology means either hardware or software may or may not support new features and functionalities because the system infrastructure was very old may or may not support this is point number one so in reference by understanding this what is the thing you you'll be saying this is where generally technical feasibility comes into picture whether is it compatible or not if it is not compatible right so what we want to do we have to propose to the customer that we are going to develop a new product for you as separate because rather than repairing the existing one it is always easy for any team to develop a new application as fresh because requirements are very fresh from the beginning so they could understand the requirements well in advance so that they can develop and build the product easily rather than understanding the architecture of the existing product making changes out of it and all everything normally it's a difficult and challenging task but sometimes it happens that's a different story so being you are a technical team you are into the development team where you guys are into the implementation side where you always try to see in what way technically it is feasible for us to develop right this is where generally feasibility study comes into picture so if i am a customer if i am expecting some sort of solution from you guys what is that first of all i need to have whether is either i'm expecting you to enhance the new features i'm expecting you to develop a new product as fresh whatever it could be i need to have a clear understanding about the kind of business needs followed by the goal what i want to achieve finally this is what first of all i need to have a clear understanding being a stakeholder we i don't say as individual i can say like we need to have a clear understanding about whether uh do we have clarity on this perspective or not is what i need to know first at the same time i must be knowing about how to achieve it because being a sol vm gain expecting a solution from a technical people all that being a stakeholder or being a client i must be knowing about how this could be achieved because if any clarifications come across in near times in reference to the expectation of the product itself is concerned i was the first person to answer those questions i may be an individual or a group of people who are there so we need to have a clear understanding about the need of the business for what reason am i expecting someone to develop the product right so business need so when we talk about the business need there are few things we need to understand when we talk about the business need from the perspective of perspective of the client perspective of the client i am saying so first point what is the name of me to make someone to develop a solution at this time point number one to be noted so being in stakeholder being a client i must be knowing about this well right what is the need of me to make someone to develop the solution at this time second point how important for me to use this at the present condition because i am endorsing someone to develop the product so how important for me right so how am i important for me it's not only important how immediate because depends on my immediate need and all everything we will be knowing for example if i am expecting a product to be developed as early as as possible whatever the model they were choosing and all everything will be different end of the day we are using aja so that is one thing how immediate right so next who are going to get benefit out of this right means beneficiaries right we must be knowing about beneficiaries etcetera so when i'm trying to understand about the need being a customer being a client or being in a person who is whom expecting the product to be developed so i must be having a clear understanding about for what reason am i developing i'm expecting someone to develop the product and how important is it to me how immediate is it for me right and who are going to get benefit out of it this is what generally in business analysis terms we call it as business case because again i'm comparing with the traditional one because there is a connect between traditional agile will happen sometimes in between the reason i always i'm trying to compare when it is required to the traditional one also this is where generally in business analysis terms we call it as business case business case we need to define the business case here normally in regular models and all we call it as business case defining a business case right so defining the business case is what generally we do so when we want to define a business case especially in reference to your business because i am explaining about the business needs so that hope it is helpful to you so that i am explaining this point it's not a deviation but in addition to that because it's a traditional way of approach we follow whenever we follow a traditional way of approach we need to define the business case first so when you want to define a business case first you need to understand the business situation understand the business situation second list of problems right next the same point how important for us at this level someone to develop the solution right so this is one more thing we need to understand here now how immediate who are the beneficiaries who are the beneficiaries going to benefit out of this right what are the assumptions and dependencies what are the different different results and these assumptions and dependencies we have to think from two different ones one is from the client side other second from the implementation team vendor stack right what are the assumptions dependencies these are all comes under the business case here so very first thing is that when we want to understand the business need of the customer these are the points we have to focus more on so understanding about the business need had to have how to achieve it and what is the final goal we want to achieve there must be the goal whatever you are going to achieve must be a business goal obviously right so the end goal has to be knowing so that is what the first point is the second point you need to know about the scope of work followed by the vision what is scope of work scope means scope we need to define nothing but scope nothing but the possibility possibilities of developing solution is what we call it as scope scope of the min do we have that scope to develop the product or not normally when we talk about the scope this scope we need to understand from two different ways assume that i am the customer right i am the client wherein you guys your all belongs to the development team scope will be defined by me as well as by you as well because scope means when i am giving some problem to you to solve that all that stuff first of all i need to have a clear understanding about do you have the possibility someone to develop the product or not so that sort of scope we need to understand because am i providing all the information to them so do i have any kind of restrictions to provide any sort of information to them if i'm not providing if they have any kind of limitations in providing information and all that how to go over about that so that sort of understanding first of all being a customer i need to have at the same time there are possibilities sometimes where i may be changing requirements in between right so these sort of understanding is all concerning the scope of the project from my perspective so there are two perspectives remember careful listen careful so one is from the customer side scope of the project from your site is different because you are into implementation team you see the possibility right how to make it successful because for example i am assigning a task to you guys to complete so when i'm assigning a task what is the first thing you say you see what are the possibilities probability of success so probability of sectors success you will be dividing into two different things which is in your hand which is not in your hands right or not what is in your hand how you are planning right have you understood what are your technical capacities for business capacities how well you are organizing your time your team all that stuff all these things comes under the capacities in terms of the internality which is something relating to you you are whole and soul responsible for that right so i am not responsible which is in your control which is in your territory but there will be some situations which is not in your control that's what normally we call it as out of scope what was that volatility requirements as i stated just now i have told you volatility for example customer has given requirements at this level assume that customer has changed requirements all of a sudden what will happen whatever the scope we have defined and all everything will get deviated right so whatever we want to implement something will get disturbed due to this right so if this is the case what should i do how do how should we proceed this is point number one second in purpose of understanding the requirements gathering the requirements before we are implementation or at the time of implementation if any sort of additional information we want to provide is that easy for you to access or do you have any kind of restrictions because especially if you see the best example especially health care or finance related products when we deal it's not easy to access their systems because they don't allow you to access their server systems all that due to different different security reasons but sometimes there are but especially for technical teams saying this there will be some problem they come across like because they need to have a sample data they need to connect to the server and they have to test in a process of implementing the project they want to do it right some sort of live data is required but normally some customers were reluctant due to different reasons as i do normally those are genuine reasons for sure but they don't allow someone to access their system and all everything for whatsoever reason so they when we are trying to implement the project this is where most of the prob most of the times we get the problem here this is what generally the kind of problem when we are facing when it comes to the out of scope so scope of the project when we are trying to understand we have to understand two different one is in scope second is out scope in scope means which is in your control in your control like project planning your team technical expertise the kind of model you are using right so the kind of technical infrastructure what are the infrastructure desired infrastructure to develop the project do we have sufficient or not is this your technical team is well equipped to develop the product all these things comes under your control end of the day so if you are failing in doing so that is your responsibility but when it comes to the out of scope and all there will be some conditions like changes in requirements volatility requirements might be taking place sometimes changes in requirements happens second not only changes and requirements sometimes there are possibilities that there is a possibility that sometimes what you call law sometimes accessing of information additional information may not be so easy so this is what generally the scope of work from the customer perspective because whatever i have truly explained you so far from the client from the development team perspective as as for the first level i have explained about the customer perspective this is what generally the scope followed by the kind of vision the what they want to achieve is what being a customer we need to understand this is this is the second point now whenever we are going to conduct the meeting this is where generally planning meeting will be conducted of course if you are in agile team at all you are no way related point to be noted because if you are in an agile team or if you whenever you are in a team right you are part of scrum team or something of that sort you have nothing to do with this because understanding about the vision and scope is important how they are going to conduct and all it's nowhere relating to your near element but when you are trying to understand about the gel planning process and all everything how it happens and all everything should be known that's the reason why we'll be discussing about these points otherwise it is not required for you but if you are a product owner yes it is required because we never know out of people who are comes who are going as a product owner or a scrum master or team member and all right so that's a different story we don't know so if you are a product owner for example maybe in future indoor you must be having a clear understanding about the vision and as well as the scope of the product what we want to achieve hence planning of meeting and all everything will be conducted here at the client location where they have to focus on the target customers right who are going to use the application let's say let us take a core banking target customer when we talk about target customer let us understand from the business user user perspective normally when you are developing a solution or whenever someone to develop you the solution for any kind of product we need to understand the user first target customers users users will be of two different types users people who are inside the organization second we call it is business users i'll give you two different examples to you in reference to the user part if you are developing a core banking application who will be the user here user will be a bank customer bank employees right they are the users because core banking is an internal application used in the bank itself it is not for the external usage it's only for the banking transactions in regular intervals they'll be using it this is what generally uh what we called a core banking application is being used so this is only for the internal purpose second there will be some applications like something like e-commerce if you take online shopping portal something of that sort general users will be too one employees of that same portal because they are receiving the orders right so whatever the supply chain process and all everything has to be handled by them at the same time business users business users nothing but customer for example if i am a person who is developing a solution for some of the customers something like online shopping all that so what is that i have to do sometimes not only a solution for writers sometimes i have to think from the user perspective when we talk about user again i have to think in two different ways if i am the person who is receiving an order what is that i am going to do if i am the person who is placing the order what is that i want i am expecting someone should be on the screen right so when you are developing some solution when you are becoming a solution provider it is not always helpful to you from to think from the solution provider perspective we have to think from the end user perspective right so you have to think from the end user perspective if i am the person who is going to use this e-commerce application what is that i am expecting someone to develop right so we need to understand if i am a person who is developing someone i am expecting someone to develop the product so first of all i need to have a clear understanding about the target customers followed by the need at the same time what was the name of the product category what kind of product i'm expecting someone to develop right which car under which category it falls into at the same time what kind of benefits i'm expecting from the product because if i'm developing some if i'm expecting someone to develop the product for sure there will be some benefits right i'm expecting some sort of benefits and all of it so what are those benefits could be next at the same time we need to understand the primary competitive alternative is there any kind of alternatives we need to understand when we are developing some kind of solution in future at the same time what kind of who are the relevant people who are finally participating in the meeting like planning meeting and all that who are the people because if i'm a business owner i'm not only the one participating right along with that there will be some relevant stakeholders like other functional heads and all everybody will be attending at the same time key team members will be attending of the product at the same time there will be a role called pivo and the last time also i have told you about the pv role itself we were nothing but the product owner so this product owner will also be attended so understanding about creating understanding about the vision and as well as the scope of the product is what one must be knowing so before you are going to do the project before we are going to develop any kind of product and all that one must be conducting this meeting so that they'll be having a clear understanding about what they are expecting and what their application expecting the product must be finally right so that sort of clarity is required so in agile planning process the first step will be this point number two based on this based on the clear understanding based on the meeting based on the inputs what we have discussed so far based on the final conclusions what we have made in out of this meeting from here onwards the responsibility of a po starts because if you remember i have explained you about the roles of a product owner right so here i've told you right to define the goal and vision of the product all that i have discussed in the earlier session if you remember this is where generally a product owner do means if i am a product owner assume that if i'm a product owner as i have attended the meeting i got to know what is requirement right so what what is their expectation everything known to me well so being a product owner what i have to do whatever the vision and what vision means what is that they want to they want to see near times right that is what generally we want to have a vision so i want to make that vision into a visual representation this is where generally reality comes into picture means i want to make it real if i want to make it real what is that i need to have i need to make it visual this is where generally we call it as product roadmap i'll give you an example to you of course i'm not explaining jira here i'll explain jira in some time maybe once it is done and all everything i'll be showing because there is an application in between anyway i'm just explaining about the this part i'm explaining about product roadmap to you let me introduce this jira part there is an application called jira usually it's kind of project management tool compact tracking which is widely used across industries for managing the project all that stuff when you see a product for example this is an high level explanation i'm giving so because i'm explaining about the project planning i'm just showing you here right so if you can go to the projects how to create project and all i'll show you means once this is everything is done finally we go to that right how to create project and how to i'll show you that later let me show you there is an existing application called for example online shopping right this is one application so this is where generally a roadmap has to be created first we have to create a roadmap roadmap means what are all because based on this is what whatever the epics you can see here all that stuff this is what generally the roadmap this is what generally a roadmap stands for this roadmap has to be created by the product owner how the roadmap this roadmap has been created by the product owner based on the kind of meetings they had earlier means this is where generally this creation of product vision goal all that stuff happens based on that a product owner is the person who is responsible to build a product roadmap this is how generally a product roadmap looks like means there are fixed user stories all that stuff i'll explain one by one later right so this is where generally the product wrote method so whatever the vision and whatever being a product owner i have something in my mind means in my mind is that i want someone to i am expecting an online shopping portal to be developed now being a product owner what is that i have to do i have to make it into reality means i will have to create a product roadmap first product roadmap means what are all the features should be there in each and every product for example website option of mobile is required mobile website option is one kind of epic is required advanced navigation and search is one more epic i require superior photos and image options is one thing at the same time product descriptions are customer reviews right check host options so these are the different different types which based on the this interaction as well as the discussion we had with the team finally being a product owner i have decided that these are the epics majorly my customer means myself being a product owner i am expecting that i am the owner of the production nut right so if i am the product owner this is what i am expecting so asian that you are all belongs to the technical team wherein if you want to understand and to implement the products successfully being a po i have to create this epic first first of all i have to create a pick at the same time not only creation of the peaks i have to give some timelines also these timelines remember were nothing but the estimation timers because being a bo pio i must be knowing about the rough estimation now how much of the time it will be taken for the team members to develop right so what is the amount of time it will be taken for us to implement right for you guys to implement because end of the day implementation and all everything will be done by you accepted but even though you are implementing the product first of all being a product owner i need to have a clear understanding about the kind of effort estimation how much how much effort estimation it will be taken for me to implement that is what generally we must be having this is what generally call it as rough rough effort estimation months how much approximately it will be taken for a team members to develop that product the whole product right how much time it will be taken for them to develop the project is what generally the rough estimation time all that so the rough estimation time is what generally we must be knowing this is what generally happens in the second level means being a product owner what is that first i have done i have understood the goal and as well as the vision of the product followed by this i need to understand rough estimation time right how much amount of time it will be taken for me to complete the product at the same time how much effort it will be taken for someone to develop the product is what first of all i need to have i need to know first now based on this i should also keep something in mind about the kind of goals and objectives means again these goals objectives will be two different types as i told you just a quick info guys intellipaat provides agile training mentored by industry experts the course link of which is given in the description below now let's continue with the session whatever we discussed in the planning meeting is all under under the business goal now whatever the goals we are discussing here and all everything comes under the project goal means basis upon the business goals and all that so what is the project goal and all everything that we have to see so the goals must be knowing at the same time we must be knowing about the objectives any project has been connecting with few things first objectives and goals second need followed by the scope these are the three major aspects will be there for any of the project if you want to develop any kind of product if you want to develop any product to be successful in long run so we have to focus on three different things one is objectives and goals second is need third followed by scope if there is any kind of clarity which is missing in these three things the product will be even the product is developed end of the day it is not surviving the actual purpose what customer is expecting that's the reason why you need to have a clear understanding about the kind of business goals in connection to that what kind of product you are developing that product goal must be connecting to this at the same time what kind of objectives we want to achieve finally is what we must be knowing about in this second step comes under the product roadmap which is being done by the product owner for sure at the same time this product owner should have a responsibility to create a product backlog this is where generally product backlog and all everything comes into picture normally before we are going for a product backlog and all a product owner should have to and should should prepare or else should have an idea about the mvp part this is where mvp what is mvp mvp nothing but minimum minimum viable product uh in other sense i can say like because in agile normally we call it as mvp all that normally we call it as minimum viable product minimum viable product nothing but it's something like a prototype for example someone wants to develop an e-commerce portal right something website or something normally for a general general understanding i am giving this explanation to you for example someone is expecting you to develop a website now before you are going into a website or before you are going to develop the actual website what is that normally happens sometimes because if you are anybody come from that segment will be knowing that well you are developing a website to one of your customer so when there is a negotiation taken place whenever there is an interaction happened before you are going for a full-time website implementation what is that first thing they'll ask you first thing they'll ask you to develop some prototype isn't it right so demo kind of thing prototype they'll ask you to develop first so that prototype may not be the real one assume that right and there is no guarantee that will be going on the next level because this prototype will give you a clear understanding about how it looks like right so how it works from an external point of view is what generally prototype so based on that prototype and all what is that customer say customer has given you the signal yes next level will be implemented the same prototype will be turned as a product right so turned as a website and we complete the whole thing this is how generally happen the same thing happens even in agile environment but we call it as identifying the mvp like minimum viable product what is the minimum viable product which customer is expecting at this level means being a product owner i have to understand creating an mvp first i need to identify the mvp this identification of mvp and all everything may not be the real one right so because there is no guarantee in agile that mvp implemented 100 as as as a as this because there may be some sort of changes and all happens in between right because but to have a clear understanding about this first of all we need to identify the mvp this is what we call it as minimum viable product so if you are a product owner based upon understanding what we have first of all you need to translate whatever the inputs you have taken and whatever the final conclusions you have identified so far those you have to translate into product roadmap so once you are creating product roadmap if you want to create a roadmap of the product you need to have few different things one you need to understand the epic followed by the pick and all that so you have to write down the user stories user stories if you want to write down the user stories and epics and all everything first of all you need to understand the actual solution which you are expecting someone to develop so based on that epic epic nothing but i can simply i can call you epic nothing but a feature epic nothing but a feature so again in future there are different different functional and non-functional requirements will be there those functional and non-functional requirements will be called as user stories right so all these things and all comes under the product roadmap so once the product roadmap has been created we need to have estimation of timelines is required at the same time what is the goal of objectives and as well as the goals what we want to achieve finally at the same time a product owner is the person who is trying to identify the mean minimum viable product which is to be developed first so based on the minimum viable product next level product implementation will be taking place because this is the base level to move on to the product to the next level because this is the minimum thing which customer is required at this level at this stage it doesn't mean that it will stop to that extent it will go to the next level but this is the minimum available product which gives a clear understanding about the high level view and high level understanding about the product all that this is what generally the second we call it as product roadmap is it clear to everyone any doubts in these two points any questions now for example let us understand release planning process here for example to develop a product itself taking 12 months okay i am making it simple so that you will be understood by 12 months now four months release one in four months there is release too in another four months there is release list three right there is release one release to list three now if you are completing the whole product it is itself is taking 12 months but whereas when we are doing agile implementation whenever we are working in agile implementation the planning process and all everything happens through release part release one release to release now in the first release assume that right in the first release product owner wants few epics to complete product owner wants few epics to complete you can take any of the product let's say for example let us take our point of sale system as an example i'll show you understood better right for example here right so for example this is a cloud based point of sale system assume that these are the different different features we have right different different features we have now customer is expecting a crm is one thing may not be required all the user stories can to develop on the first level right may not be now for example customer is expecting pure epics here for example crm loyalty hardware in cash registers may be inventory management system so these are the three epics required by the product owner at this level so if you are taking three epics into consideration how many user stories we have we have four user stories here remember again i am repeating if you are taking about product backlog into consideration because next time next thing got to what i'm explaining about product backlog because product pack not nothing but it's a repository to store all the user stories to store all the user stories normally product backlog starts well if you're talking about product backlog user store is nothing but only functional requirements even technical dates even technical requirements bugs everything will be there in that that i will list that i'll be explained it later to you okay now what is that we want here for example customer is expecting crm loyalty is what wants to develop in the first level second they want inventory management system third hardware in cash register these are the three different apex which customer is expecting us to complete now how many user stories we have assume that functionality nothing but the user story four four plus four eight eight plus four twelve right so twelve user stories so how many user stories there are three epics three epics to complete okay each epic as per the case today i have shown you i am writing here as an example each and epic totally total three effects consists of 12 user stories nothing but 12 functionalities okay forget about technical requirements all that assigned i'm talking about only requirement functional requirement three picks to complete total three epics totally consists of tall user stories because one epic may be having four one more having four one more having four four into three twelve users to this to complete this is the first release now when you talk about four months when you talk about four months how many weeks it is four weeks into four months means 16 weeks right 16 weeks is what the time we have 16 weeks is what the time we have but when it comes to working days because this is where generally sprint planning and all everything comes here when we talk about this in your converting into working days how many usually five days per week into how many weeks 16 weeks 5 days in a week into 16 so 5 days in a week into 16 so which is coming around 80 working days because especially in agile whenever we are going for spring planning at all normally whenever we are doing the release pattern or we have to take working days into consideration now you could ask me one thing raj where you have taken five days a week because monday to friday is the working time so saturday sunday is the holiday hence we have taken five days in a week right five days per week into 16 16 weeks means for four months i am talking about one release i am talking about one release release planning list planning happens in every release they say the same process we follow but whatever the user stories we have taken whatever they picks we have taken might be different from one to another it will not remain constant and same all the time so roughly speaking five days in a week into 16 80 working days this 80 working days excluding any excluding holidays any government holidays or festivals all that comes we have to exclude it then only we have to consider otherwise because we cannot include all that right excluding holidays because if there is any government holidays or some other days and all that so that has to be deducted finally working days comes into picture now in this four months time four months nothing but four weeks into four 16 weeks five days in a week into sixteen eighty working days excluding always assume that there was no working there is no holidays except saturday sunday asian that there is no holiday right eighty working days in eighty working days product owner wants three epics to complete total consists of twelve user story this is where generally the release planning process will be initiated now if you want to discuss about the release planning process and all that who has to involve here product dollar has to involve point number one second scrum master has to involve because kramas is the person who is to manage the scrum team and all they have to involve here at the same time team members should also be involved scrum team members all that why because especially in agile whatever the decision in reference to the implementation itself is concerned everything will be taken care of by the development team not by the product owner nor by the scrum master scrum team members has to take in a decision on how much time it will be taken complexity all that stuff will be taken care of by the people itself this is where general the release planning process and all everything will happen means if you are talking about four months is the first release roughly speaking to complete a product where in four months product owner will give you the guideline to you product owner will tell you in the first release this is what i want these are the three different types which i am expecting you to complete this whatever the three whatever the four months release and all that if you're talking about three epics these user stories may be different right so the sprints and all everything will be different because there are a few things we need to understand here first point what is product backlog few answers fewer questions you need to understand what is user story if you know about this you will be knowing what is user story what is epic first what is what is product backlog next what is right these are the four things epic epic nothing but large scale of solution is what we call the right what is user story short description of requirement is called as user study what is product background there are different different user stories we are writing for example we have 12 user stories in three epics where to store all these there must be some repository to store on that this is where generally product backlog comes into picture now what is print sprint nothing but collection of user stories which are we developing based on the priority this is what we call the sprint sprint in simple terms you can consider it as module i don't compare that sprint with module normally it won't but assume that right for example this prince may be anyone right for example if you have 4 weeks for example 4 into 4 16 weeks in 16 weeks normal sprints will be calculated in a form of weeks normally sprints will be calculated implementation of spins will be calculated into weeks into weeks for example this project we have taken for example some project let us take some project here let's say for example hospital management system i have taken okay for example right now there were different different types we have written followed by epics and all we have written the user stories also so whenever we write user stories what is that we have to do right so here this is where generally backlog is backlog means what are the user stories and all everything will be there in this right so this is the this is all whatever the user stories we have in our leftover user stories will be there on the sprint in the backlog from here what we have to do we have to create a sprint whatever the sprint we want to develop so these we have to push here we have to push here push here means this is again based upon the priority based upon the priority and all everything so sprint nothing but whatever the implementation based upon the time frame or time boxing thing we are following for that the thing is which is called a sprint means if you are taking this into consideration for example if you want to complete four user stories 12 user stories and three epics will be formed in different different sprints sprint will be form of one two three four weeks ago for example sprint one out of twelve right three user stories right next sprint two sprint two for example the customer is expecting you to develop four use the stories right and maybe sprint three four plus three twelve four plus three twelve yes uh fourth plus three seven right purpose three seven for example two user stories we have taken print so sprints there is no guarantee like these mini sprints it will be taken so if you're taking sprint and all it depends on how many user stories we have taken and how much effort it will be taken all that into consideration so whenever we are doing the release planning release planning process and all everything is depending on how many sprints we are developing these prints normally will be converted in the form of weeks one week two weeks three weeks four weeks and so on right so normally for example if you are taking 12 user stories it can be like this sprint one may be having three user stories sprint two may be having four user stories sprint tv3 will be having two user stories four plus three seven seven plus two nine for example nine print four may be having three uses right so three uses students so to complete if you can see roughly if you want to complete this 12 user stories out of three epics in the first release how many sprints we have planned we have planned four user stories four sprints it may not be four sprint sometimes it may be six it may be two it may be 3 it may be 4 even why because it purely depends on how many user stories we have taken at the same time what is the complexity which is involved to implement that because particular user story nothing but the functionality if you want to implement the functionality what is that you required there is an amount of complexity which is involved right it depends on so for example three user stories may be taking two weeks for example four user stories may be taking three weeks four weeks time for you to come two user stories sometimes it may be taken one week for you to come maybe the three user stories may be taken four weeks time for you to come right so which is not something guaranteed right it's really because this planning whatever the sprint planning and all everything this will be decided by the team members but when we are planning about the first release means what are the release we are planning and all being a product owner that's the reason why product owner is being involved here why because product on is the person is expecting you this is what i want you to complete now when it comes to the implementation part who has to take in the decision on this this decision has to be taken by the team members so team members should also be knowing about the release planning process in advance whether how many user stories they are developing how many sprints they are developing in first sprint second third fourth and all everything it depends upon the decision what they have made at the time of spring plan so before that whenever they are completing the release planning process product owner will give you the clear understanding about what is that is they are expecting in how many days this has to be completed assume that if it is taking four months print for example in 80 working days i want these three epics to be completed which is a combination of turn user stories now you could ask me one thing raj is it only confined to 12 user stories don't you give any guarantee that sometimes more than 12 user stories will also be there sometimes yes there is a possibility that's the reason why whenever we are implementing in agile implementation there are two different things some user stories and all everything will be in the sprint some user stories in real environment normally what we see there are out of split means there are no no in the sprint in the initial sprint whenever the splint planning and all everything we do these user stories won't be there after that these user stories will come and add in between that kind of problem will also be arised means there is possibility i don't say it's a problem there is a possibility it may be arrives to you so that's the reason why whenever we are doing the release planning process in the release planning process how many epics should be completed in respect of the user stories of course i have taken 12 user stories here it may be 20 30 40 50 and so on right so forget about that how many epics to be completed in the first release that decision will be given by the periodic donor where this understanding and all should be there to the team members who are attending in the release planning process means either by scrum masters or scrum team and all these people should understand how many epics to be completed irrespective of user stories because how many sprints we want to develop each and every sprint how many user stories and all again that is depends on the complexity of the particular user story because that complexity is different right for example even though there will be some simple requirements something like login page creation itself looks very simple but when starts implementation and all complexity might be increased day by day because we have started for example right because login page we don't feel much difficulty but what will happen in practical difficult practical possibilities that he would ask me raj what what complexity you can see in login page creation because it looks very simple so why why it will be complex in future because what will happen whenever we have started maybe the complexity might be less but afterwards keep on some sort of requirements and some sort of changes happened in between might happen might be taken place so what will happen obviously as there is a lot of changes are involved in the existing functionality what we are developing automatically complexity it also increased when there is a complex increase the effort how much time people were spending to complete and all will also be increased obviously when duration is increasing obviously the timelines will also becoming very short understood clear everywhere is it clear to everyone or not normally in traditional model what we do once the product is completed finally after the duration after 12 months or so normally finally we we finally we deliver the product to the client normally speaking in regular models all that stuff but whereas when it comes to the agile and all everything we are doing releases spice point number one point number two not only on the releases if there is any kind of things to be added in between there is a flexibility of doing the changes here there is a flexibility of doing changes why there is a flexibility of doing changes because whatever the user stories whatever the requirements we are writing all these requirements are writing in a form of user story user story is individual user story is individual so you there is no contact with user story with other user story right if i am writing a user story this user store is no way connecting to other one there is no connect that user story is individual on its nature so when there is an individuality what will happen automatically there are possibilities that that can be changed at any point in time of course effort is taking more but there is a possibility that we can change n number of times subject to terms and conditions if it is being accepted by the team yeah this is what generally the release planning process is so release planning has to be done so release planning whatever the release planning process i have explained you so far the same process happens in each and every release even it may be first release second release third fourth and so on the release planning remain constant every time whenever there is a relay there is a release the planning process is something inevitable okay because there is no one release plan how many releases we have those many release planning processes has to be made in this release plan release plan for the particular release either it may be one two three so whatever the part of creating a release plan and all this is the repetition one first release the happens the same maybe for the second release maybe for the third release and so on whenever how many releases we have release planning will be continued the same the same way i have just given you the rough idea here right for example if you are taking one release so based on that because how many epics and all everything there is a dependency right so how many releases and all everything so this is what general release planning process is all about once the release planning process is completed yeah once the release planning is completed the next part is that for this sprint planning for this sprint planning right so the release planning part and all everything spring planning so whenever we are going this print planning first of all what we have to do whenever the first part like for giving creating this product roadmap right so creating release plan all that normally there is a concept called product back this is where we have discussed here but of course not in detail product pack law so what is product backlog for example there is a product called payroll management now task what is task simplifying user story is nothing but task again simplifying the task into sub task because this is all to reduce the complexity you are doing this right simplifying the task this is what we call the sub transfer right this is what generally the roadmap is once the roadmap is created what is that you are doing you are writing down the user strategy where you have to put is we have to put in product pack what is product backlog it's a repository to store all the user stories not only user storage we can store anything right so this is what generally the product backlog is so product backlog creation is what we have to discuss before you're going for sprint planning product backlog is there so this is what the product is for example you are taking hospital management system there are different epidemics epics have user stories what is that we are doing whatever the user stories everything will be there all these these things you can see in the product network this is what product backlog means it's a repository to store all the user stories whatever the user stories and all everything will be done under product background right so from product backlog what is that we are doing from here onwards whatever the scrum sermon is i have told you right sprint planning daily scrum sprint review and retrospection will be taken place understood everywhere right understood or not following right goal and vision followed by this product roadmap you have created in this product world map you have apix user stories all that like has i shown you on jira just know some time back next from there what you are doing you are creating a product backlog in the same user story in the jira itself we are storing all the user stories in the product from there what you are doing again from the product backlog we are taking few user stories and we have to do screen planning and all of course print planning i have not started it because what is product backlog why do we do product backlog for what reason product backlog is to be done i have to discuss now so for that there is a presentation for product backlog which i am showing you let me explain that first confirming whether you can see this yeah can you see this product backlog right so this is yeah so this is what general product backlog consists of what is product backlog just to have told you product backlog nothing but whatever the user stories are we writing to store all the user stories we require a product backlog it's a repository to store all the user stories but product owner is product backlog is not only for user stories because user stories are nothing but functional requirements isn't it that's what i have told you in the beginning but there may be some technical requirements also right some technical requirements will be there so technical requirements will also be there in the product for example core spikes code spikes means for example some demo kind of work has been done by the team so where are we that putting that information for that information also we put it on the product bank for example there is some technical doubts technical dates all these that also will be there in the product pack now so product backlog means this is what generally product backlog is so product backlogged means where in this product backlog whatever the user stories we are writing whatever the technical requirements whatever the code spikes we have whatever the technical gets that's whatever the bugs bugs may be may not be immediate maybe once the implementation has been taken place whatever the box we have identified all this can be stored in this product bank log so product backlog refinement process creation of product backlog maintaining it backlog refinement process all that will be looking after by the product owner normally but if you want to put something in the product backlog what are all product backloggers and all this is how generally the structure is product idea we have discussed earlier product vision from their epics discussed epics we have discussed after pics we are going for user stories so user stories technical requirements code spikes technical dates bugs everything will be there in the product backlog so product backlog creation and maintaining product backlog is what will be done by the product owner product backlog used as a repository between means once the product roadmap is being created once the product roadmap is being created at the time of the thing product backlog has to be created we have to create a product backlog product roadmap based on that release planning processes after that sprint plan sprint planning in its development what to develop how to develop how much time do we have how much manpower do we have how much manpower how much time do they have to complete will there be any possibility for them to complete within the timelines or not how much time it will be taken for the particular user story to complete and for that how many story points to be given and all everything comes under the spring planning so we have not even started sprint planning yet remember right we have not started sprint planning actual sprint planning will be started after not now what is that we have done so far is that only about till release planning is what we have completed so creation and vision on scope of the product is what we have created first next we have to create a roadmap based on the roadmap product backlog creations and everything will be done here based on that release planning will be made here once the release planning everything is done okay fine we understood clearly that in another four months this is what we want to do now next next is about sprint planning in sprint planning how many sprints we have to take right because this is where i have explained here if you remember i think here i have explained you right here i've explained yeah first way for example how many for example 12 user stories we have three epics we have 12 user stories for 12 user stories how many sprints should be there right how many sprints each and sprint how much time so that is all those all these aspects and all everything will be discussed under the sprint planning so whenever we are done in the sprint planning this is where generally all these things will comes into picture just a quick info guys intellipaat provides agile training mentored by industry experts the course link of which is given in the description below you

Channel: Intellipaat

Views: 113,622

Keywords: agile project management full course, agile course, agile training, agile tutorial, agile complete course, what is agile project management, agile tutorial for beginners, agile complete tutorial, importance of agile, agile scrum master, agile project management, project management, agile, agile methodology, agile project management tutorial, what is agile methodology, project management tools, project management fundamentals, agile project management training, intellipaat

Id: tlB-WAR0j-U

Length: 211min 20sec (12680 seconds)

Published: Sun May 29 2022