🔥 Agile Scrum Crash Course 2023 | Learn Agile In 3 Hours | Agile Training | Simplilearn

welcome to this new and amazing video on agile crash cause by simply learn before we move ahead consider subscribing to our Channel and hit the Bell icon to never miss any updates from us agile scrum is a widely used project management framework that promotes collaboration flexibility and iterative development it breaks work into small manageable task called Sprints and employs a self-organizing team approach key features include daily standup meetings product backlogs delivering incremental value to customers scrum helps teams adapt to changing requirements and deliver high quality products more efficiently so are you interested in becoming an agile scrum professional here we have certified scrum Master CSM certification training course some key features of this course include two days online virtual classes two-year membership with scrum Alliance 20 pdus and 16 scus includes CSM exam fees as well by the end of this course you will be skilled with scrum and agile methodologies importance of agile scrum life cycle scrum terminologies daily scrum and review roles involved in scrum and distributed scrum one year of experience is preferred to enroll in this program so hurry up and enroll Now find the course Link in the description box so without any further delay let's begin by understanding what is aile methodology over to our tutors look at a time in the late '90s what was happening with software development forms so they used to follow waterfall methodologies so there used to be expression like sir you have a problem so what happened so our client want a new feature to the software we are already Midway creating the software we can't add the feature so what does it mean so there is a scenario where the change is asked so why change change may be because of adding certain features removing certain features modifying certain things already given what is wrong in that why can't we do the change so now Point here is not about doing the change itself it's about the effort additionally takes cost money in terms of which is going out the effort then uh the scope which is going to change at the same time you also need to put more efforts which will delay the project so now is it okay so '90s it was okay today is it okay a big question mark so why is that not okay so we to understand that very clearly right I knew we should not have used the waterfall methodology for development so is that an issue with the waterfall methodology so answer is no if it is today scenario answer would be yes if it is '90s answer would be no so what changed in this 20 years or 15 years the Dynamics of the market changed the behavior of consumers changed so if you look at anyone who is using any product it may be a software product or a hardware uh like if you mobile phone or a television or any application mobile application or application used on your systems the upgradation of the new features and functionality of that is improved more and more and consumer wants it more and you have a very less time to respond that is one thing second thing there is lot of competition if you do not respond quickly competition will take over so for you to sustain and grow it is very essential that you understand this Dynamics and you need to respond quickly which was bit difficult when it comes to approach what is called waterfall model now how do we address this so what is that waterfall model is all about why is it difficult for us so the methodology where waterfall model is used involves teams following a series of steps and only going forward after the previous steps are completed so there is a wait time involved so until the previous steps are completed only then I can move to the next so it is a slower thing it would take certain longer duration so it is best used in the scenarios where the teams are small and the project is expected to move in a predictable manner so predictability is very important when we follow waterfall methodology predictability the variation should be as lesser as possible so what is that predictability I'm speaking about as I create this product as a results comes up if it takes 6 months 1 year 2 years 3 years it's okay so this is how the product would look like the predictability how the product would look like how that particular output would come so when is that going to come is it okay if I bring that result after 2 years is that okay so if everything is okay that with without very less without any variations as such very less variations then it's fine so because of folling waterfall model U what is that methodology what is that flow we need to understand that so requirements Gathering and documentation is the first thing what used to happen which is true in AEL methodologies also but the main difference here is the requirements Gathering and documentation happens in detail a comprehensive one now once that is signed off only then it is moved to the design now based on that requirement which is gathered which is full comprehensive then the design will happen based on that the consideration of process the products the people the environment then the design happens which is again a detailed design now once the implementation starts if you find any deviations the correction needs to be done since the design is in detail the deviation possibilities as less as possible but the challenge comes up when the the Dynamics in the market when the Dynamics of customer changes customer asks for change then you may require to do the change now when you want to do that change you may require to do that change only after understanding what would be the impact of this change in the entire output which you're going to create which is very comprehensive one so because of this it consumes time it consumes extra effort so it may be a scenario where the scope of work is reduced as well even after that this exercise has to be done which will delay the project so this was okay so when this model when things were done things were taken up for changes it was okay because the consumer Behavior as I mentioned there's a lot of wait time for the consumers also so there was less competition but today it is not I need to go quicker so because of this what are the disadvantages which has came up to the consumers or to the organization who actually follow waterfall methodologies in today's scenario so what could be those so making changes would be difficult as I mentioned earlier so then it doesn't focus on inducer client customer perspective value so today I think more and more we're speaking about creating a value in the consumer perspective customer perspective and the time it takes for Consumer to realize the value how long it takes the more it delays in realizing the values by the consumer there is a delay in terms of making your product impression better in the consumer's mind so competition will take over so your existence will be in bigger threat so testing phase is delayed until most of the project is completed because it has to follow step by step wait the things to complete and then testing happen then measuring the progress within the stages is difficult so why is it difficult measuring the progress within the stages because the deliverables or the metrics what are defined are defined to measure at a milestone and at a end of the phase to understand whether everything is delivered as part of it now let us look at how agile is going to help help us to address these disadvantages mentioned in what fall model so what is agile the basic meaning of agile is to move faster be flexible respond to change Etc but to accomplish this there are a lot of methodologies now there is something called agile Manifesto on 12 principles of agile which we need to understand so following this accomplishing this can only help us in becoming agile so in 2001 agile was introduced so that's where the term agile came into picture where people start realizing what is agile and why should we adopt that agile methodologies so while it was introduced so agile Manifesto was also released it's a set of principles used in project management and software development so basically there are four points which we need to understand very correctly very clearly so that we can able to understand what is agile is all about right it enables team to deliver value to their customers with ease so agile team deliver work in small but usable increments then evaluation of the requirements plans and results takes place continuously this allows teams to respond to changes quickly now change was one of the scenario what we were speaking about now responding to change quickly is one of the disadvantages what we spoke about and here it is addressed it is considered to address that is very important now when we respond to change quickly it is not that I just quickly responded but I did not address that problem or that scenario it is very essential to address that scenario as well effectively and efficiently so now agile is a concept right so it has a detailed Manifesto based on which all the agile methodologies are created so what is this agile Manifesto is all about so it is created it was created during February 2001 so which details out the values and principles of agile processes which says there are some values which is mentioned in the left which has more weightage compared to the one which is in the right now when we say this for for example let us take let us go one by one individuals and interactions over process and tools so are we saying we don't value the processing tools that is not the case now let us look at what were the typical issues or challenges anyone would have expressed regarding the processes so delay maybe bureaucracy and they cannot have a flexibility to move faster so basically delays because of the approval which is not happening because of the processes now how do we address this so can I eliminate the process itself answer is no because in the absence of tools and processes none of the things which we can do easily can exist so it should be there process and tool should be there the way it should be defined it should also ensure there is individuals and interactions encourage to have that individuals and interactions while having the processing tools so next is working products or comprehensive documentation so when we say comprehensive documentation as as I mentioned in the waterfall methodology during the requirement Gathering during designing there is a detailed documentation which is made so which take lot of efforts in creating those now while delivering the challenge what anyone was faced was the change which is coming up and making changes to these documentations which is an additional effort now if we have a working products if I have a bigger product in that a module of that I keep creating every small small modules of it and start integrating to the base model now I will only focus on the documentation for that particular model working piece which I'm going to create in the next iterations then my documentation changes are less and also the way I'm making the documentation is initially I would have a full skeleton of the entire product which I'm going to create the road map and upon that I'm going to making the detail documentation for that only for that working piece rather than the full product itself then these working piece documentation which I'm going to create as I create the working pieces I'm also getting the feedback because I'm doing the interactions with the users the consumers the end users so I get the feedback I keep making the changes quickly and then documentation will become accordingly the small pieces of documentation which happens with those small small small working modules which are created and those are Consolidated over a period of time by the time the product ends you have a comprehensive documentation the project ends you have a comprehensive documentation so it uh saves lot of time so documentation is important but the way we accomplish the documentation is one by one not in one go next is customer collaboration or contract negotiation so any engagement or any relationship or any business can it happen in the absence of contract answer is no there should be a contract now how this contract should be when we want to follow in agile it should allow the customer collaboration why are we collaborating to understand what customer is required to understand what customer needs is fulfilled right so now this requires a lot of flexibility in the contract itself so that commercial is one area which gets impacted and there should be guidelines for that also in the contract so that during the collaboration during the change during the effort being put customer is also informed what is the change which is going to happen in terms of commercials as well as time and everything so that it is documented in the contract so there is no confusion responding to change or following a plan now I cannot have a rigid plan as we were speaking about waterfall methodology so I we need to go like this only So based on the scenarios changes so we be requir to change your directions and move faster so responding to change requires a specific flexibility which is required in the plan so that I don't have a plan which is very rigid and that provides some flexibility that's how I can able to create my plan so that I can able to move or respond to that specific scenarios which are changing so this is called agile Manifesto and this agile Manifesto has 12 principles associated with with this now keeping this agile Manifesto on 12 principles all the agile methodologies have created their own approaches and framework now let us look at what are those 12 principles the agile principles so agile principles so here are some of principles that need to be followed to make a processes agile so first principle is about customer satisfaction so one need to satisfy the customer through early and quick delivery of the product now someone who is hungry if you give them a water or a food immediately a piece of bread at least there is some satisfaction there is some realization yes I got it what I need so energy is back so it is very much required to ensure seeing things in a customer perspective and customer is satisfied so customer satisfaction is not a result of the survey what I do it's about how I deal with the consumer what is that impact the perceptions I'm building with the consumer and what do I know about my customer do I really understand the pulse of my customer how Associated am I how close am I how am I collaborating with the customer that will help you to understand how satisfied your customer is it is very essential to consider customer satisfaction and the second principle would be welcome change so changing needs need to be addressed even late in the development process so change can happen anytime now these changes should not become a challenge so there should be a flexibility in your design itself which will bring in so that is the I think when you move faster so it doesn't mean that you eliminate or you just keep introducing the defects and move faster no that is not allowed so whenever there is a change in the feature Whenever there is a change to some specific product functionality accommodating that should become easier whatever the methodology I follow that should help me in terms of accommodating so I should be welcoming changes it's okay for me to have the change so that is not a challenge anymore for me so principle three deliver frequently so Ure software is delivered frequently focusing on shorter time scales as I was mentioning while discussing the manifesto point like I keep creating a smaller piece of product modules so that I keep putting into the base model and integrating those and ultimately once all the features functionalities are integrated we have a product with all the features and functionality so this needs to happen more frequently so the release of those working P should happen more frequently more repeatedly so that that customer is seeing those working piece and experiencing and giving their feedbacks so quick changes to those working piece making that will become easier then work together so when I say work together it is very essential that developers and business individuals need to work together through the course of project which means involvement of customers involvement of suppliers involvement of your own team everyone should work together each one should understand each other's perspective view if there is no proper understanding ing about each other's perspective view it is quite obvious what was expected what was delivered would not match so there should be correct understanding to have that correct understanding one should work together collaborate so they should speak Express it is very important so feedback has to be given by consumers regularly similarly organization who is doing the project should also keep giving the feedbacks to the suppliers to make necessary changes and once it works together in a Unison I think that would help in terms of bringing out the results the way it is required that would help customer to get the value motivated team so projects need to built around motivated individuals and they must be trusted to get the job done means when will the team get motivated when the work what they are doing is acknowledged when the work what they are doing the results are seen experienced and then feedback is given there is an opportunity for Learning and contribution their contribution is acknowledged only then team is motivated when there is a motivated team when team feels there is someone with whom they can look up to is quite obvious team will also come up with certain set of innovation in their mind giving their feedback as well involving themsel in terms of getting the results what is required so it is always essential to ensure the team which is involved in creating the products is always motivated so I think when we say team the conflict also come across there may be a clash between various different thoughts and differences so one cannot just shy away being a manager one cannot shy away from it he or she should involve sit with the team resolve those put things in the right direction so right interpersonal skills are very important here next face tof face interactions so which helps in terms of most efficient means of communication which helps in terms of giving a proper Clarity in terms of what is required so that I sent an email I expect the person to do it that is not the case what we're discussing about so more and more interactions which should happen face to face so that each other understand what requires to be done and there is a quick feedback which can happen when that particular interactions conversation which keeps happening so one can understand other perspective view as well then working software so it is a primarily the deliverable which you're speaking about which has to come regularly so more and more working piece as it comes customer can give feedback based on their experience on this working piece instead of just imagining something and then giving the feedback so it should not look like an hypothesis or or something which is in the Dreamland so I told something the person who heard visualize something else it should not end up that way instead of that give the working piece expect the consumer the user to give the feedback so that it helps in terms of creating that particular product ultimately which is usable and which is going to create value to the consumers so next is constant pace so agile process promotes sustainable development so it should not I did it and I sleep I did it and then I'm waiting for something else no there should be frequent deliverables which is happening so there should be constant moment from left to right from beginning to end so that the deliverables which are expected keeps happening so that consumers or users are realizing the value of it so it should be constant Pace the velocity the speed which needs to be adopted then good design agility can be improved by focusing on technical excellence and good design so when we say technical excellence and good design it is very essential to understand inside towards what is the product being delivered inside towards what is the technology being used inside towards the processes the capability skills so all this comes together when people sit together and focus on creating that product or services so they are putting the effort towards designing it appropriately so that that will fit for purpose so since things are moved step by step in terms of creating a working piece the detailed designing of that small working piece would happen which can can happen quicker as well and since these are going and fitting into the architecture which is basically open architecture kind of scenarios what we speaking about so all those modules what you create you keep plugging into it so that you are designing that small piece was quicker so instead of Designing the entire system as a whole in detail you're just creating that small small pieces and fitting into that architecture which is open so pluggable so that gives flexibility as well and changes to the design will become easier if it's not working and the agility helps in accomplishing that Simplicity the amount of work that's not being done needs to be minimized meaning when we say Simplicity doesn't mean less right so the appropriate number of tasks the minimum number of tasks which needs to be done and mostly I think all nonv value adding activities and processes would be removed it has to be removed so the more optimized more simpler in terms of handling things is always good so that only those what is required to be done are done so it is very clearly visible and there will be CL ity self-organization so when we say self-organized teams who is not capable of everything but when you look at a team as a whole each one has different different skills many skills not one or two skills many skills which they are complimenting to each other so they come together they discuss together they focus on the architectures requirements and design and address it together so team is also owning the ownership is one thing when it comes to picture when we say team so here since team is actually taking up that ownership and organizing themsel to accomplish the results the products what is required so then obviously the results will happen the way it is needed and they will become accountable as a team so they cannot have a blaming scenario where because of one or two members it is happening they should collaborate better they should be self organizing what should happen so next is reflect and adjust so when are we going to reflect reflect upon what is that happening learn understand keep learning it having a reflection to that what is happening means responding to that so that that Improvement can happen quicker Effectiveness can be improved by the team regularly reflecting on it so team is also understanding team is also having that accountability to ensure that necessary adjustments necessary actions are taken to make those changes and Corrections quickly so these are about 12 principles so which supports which helps that accomplishment of Manifesto points the four Manifesto points what is mentioned so keeping these four Manifesto points four values which is mentioned in Manifesto and then 12 principles so keeping these in mind any agile methodologies have their own approaches and they accomplish all of this so further let us look at some of the uh advantages what would be there when following agile so we looked at a disadvantages what we have when we follow waterfall so did we overcome those the disadvantages what we had in waterfall did we overcome that using agile so what are the advantages of agile so agile is helpful in terms of of handling large amounts of interactions between client and project team because it is throwing lights on it the importance of interactions the import of collaboration the what is that self-organized teams it is spoken more and more then improve transparency to claims in every phase of the project how this transparency because customer is seeing those products the products with features and functionalities are seen they're experiencing it and based on that they're given the feedback there is nothing something hidden like when I go with what waterfall till the end of the project customer don't know what is going to come out as a whole but here since the working piece is given regularly customer is seeing it the users are using it and giving their feedback so interactions increased so visibility towards what we are creating results is more right then the delivery of the output is predictable and can sometime be earlier than expected because we know what is being delivered more and more clarity users are obtaining at the same time the team which is creating is obtaining because of it the pulse of the customer the directions are clear accommodating changes which was the challenges in it was a big challenge in waterfall methodology has become easier here so then the cost of the project are predictable and follow a rigid schedule so it is very easy to handle the schedules because more and more you interact and more iterations are in creation of small small working piece of a product working module of the product so now as you progress in that you understood the environment better you understood the clients better the customers better the expectation better and moving faster so that will become easier for you now you have become predictable You can predict easily what is that going to happen ultimately so more and more visibility you start getting so handling things will become easier so then it allows for changes to refine and reprioritize the product backlog so when I say product backlog we need to understand the various different user stories what is return to deliver so that is a list of deliverables product backlog what are there since we already know what are the things needs to be created so this helps in terms of prioritizing those changing the priorities based on the change scenario and then taking the pace taking the speed accordingly the client can provide the priority of features allowing the team to ensure maximum project value so since it is visible what are the user stories what are the epex return what is that order priorities order of priority what we kept now the change scenario obviously tells us do we really need to change this priority of which feature has to be done first so that will become easier because you have the list only changing that order in the list and then going forward accordingly integration is not an issue because we have the base model which can integrate all of this together with no issues now then by focusing on needs of the users the team can deliver value to the customers so users are involved more often so user pulse is understood what user requires is clearly understood so delivering that value to the customer will become more easier and simpler so then project is broken into smaller units with high quality development testing and collaboration because you have the flexibility so since you have better visibility you can able to do this and you move one by one iteration by iterations you progress further so those were the advantages of adopting aile now keeping that agile Manifesto and 12 principles of Manifesto so what are the types of typical aile methodologies would come across so there are few which we're going to look at as part of it which we need to know so these agile methodologies definitely considers the agile Manifesto points and then they demonstrate it in their own way now agile methodology perspective let us go one by one so some of them to look at the first one is XP that is Extreme programming so this is the framework that enables teams to create high quality software and improves their quality of life so it enables software development with appropriate engineering practices so and then when is it applicable so it is applicable to the scenario where changing software requirements to handle risks caused due to new technology while working with a small extended development team to use technology to allow automated unit and functional tests so that is about extreme programming so next let us look at kban so kban is a methodology which is used to design manage and improve the flow of system it is actually called as pull system so visual system so everything which is actually put on a board and it is visible to everyone what work need to be done what is in progress who has to do it is very clearly visible so organizations can visualize their flow of work and the limiting their work in progress so what is limiting what is stopping is clearly visible so generally if I look at whenever I'll just take a scenario of a meeting and minutes of meeting which always discuss about it now when there is a minutes of meeting shared with many people who are participated in the meeting there are certain action items given to them for example now these action items will have a Target day to complete and accordingly those needs to be closed now when the next meeting happens when you look at that action item status majority of them are not addressed what could be the reason is that people are not sensitive about answering or addressing those so more than that the prioritization changes so one important thing we need to understand how kban works here is it is a visual system compared to that minutes of meeting which is not visible to us always the kban board is visible to us always so one which is visible to us always makes us put a conscious effort to close it because our name is indicated on the board the work need to be completed is mentioned against our name then we need to take it up and then close it so it push pushes it it we will put a conscious effort because it is visible and I cannot build any stories telling that why I did not do why did I not consider this as a priority rather than consider something else as a priority so this Conan straight of addresses it and then it's also called as pool system because people pull the work from it and then complete right so where is this applicable it can be used in situations where work arrives in an unpredictable fashion so that means it gives lot of flexibility in terms of adopting to the changes which are happening the Dynamics environment so it is also used to deploy work immediately without waiting for other work items so since it is visible I think things can go smoother easier so that people are owning it rather than just disowning it so now let us look at lean so when we say lean it is very important for us to understand that value is always in customer perspective and elimination of waste these are the two things mainly spoken about so lean is a set of tools and principles that aims to identify and remove waste to increase the speed of process development it focuses on maximizing the value to the client ensuring waste is minimized so when you look at visualize of processes process interfaces and the flow so the interface certain way so unless the output of one process or procedures getting into another process so that flow should be smoother like many pipes connected together and water is Flowing so let us assume series of pipes which is of around 1 ft in terms of diameter of each of the pipes water is flowing in between if you have a pipe which is of half a feet now what happens to the downstream after that half fet pipe the entire capacity in the downstream even though it has 1 ft diameter pipe it leads to the waste underutilized capacity because this has become bottleneck now such bottlenecks such the one which contributes to the waste has to be eliminated that is very important so value should be seen in the consumer perspective and that value would happen only through the series value streams then in this value stream the identification of the constraints and bottlenecks and elimination of waste now what are the contributors of waste so waiting time more often changing things moving from one place to another place allowing defects to flow which leads towards rever work so all this likewise many things which actually end up in giving the wayte so one has to visualize understand realize what are those non-v valuing activities and eliminating those is very important right so now when is it applicable lean principles apply to any sector where there is waste of any form so it can be applied easily so one needs to know that so that it should effort which needs to be put with the objective to accomplish so your ability to move faster your ability to create that product which is more efficient so only you can achieve it the effective results can happen only when there is a lesser delays or lesser waste non valuating activities that needs to be understood and eliminate those so next one of the popular methodology would be scrum so scrum is a framework that is used by teams to establish a hypothesis trying it out reflect on the experience and adjust it is used to able teams to incorporate practices from other Frameworks depending on the team's requirement it's a simple framework which speaks about a product owner a scrum Master a self-organizing team so some of the terminologies what it uses is Sprint daily scrum product backlog Sprint backlog so it's very essential to understand this framework simpler and able to adopt it is also very easy when is it applicable it is used when cross functional teams are working on product development when work is split into more than one 2 to 4 week iterations so these iterations are called as Sprints Small Time boxed iterations so this will also help in terms of accomplishing the results provides that flexibility and able to move faster then Crystal so Crystal is an approach to the software uh development that focuses on people and their interactions rather than tools and processes it is aimed to streamline processes and improve optimization it works on principle that projects are unique and dynamic each requiring its specific methods so where is it applicable it focuses on strengthening teams communication it also focuses on continuous integration active user involvement and configurable processes so these are the few agile methodologies which are there which are more popular more heard however we can come across many other me methodologies like safe Agile which is a scaled scenario for more complex projects so likewise we have many methodologies which organizations adopt and these are few for us to understand there are two main approaches to project management the traditional waterfall approach and the agile approach originally agile developed as a way to better manage software development projects agile emerged in the late 1990s specifically in response to the Challen Alles encountered when managing software development projects using the traditional waterfall approach specifically addressing the burdens of heavy documentation and frequent changes in requirements agile techniques and best practices began to emerge and gain prominence in software development projects this led to a meeting in February 2001 in Park City Utah where 17 leading software developers wrote what has become known as the agile Manifesto let's review the agile Manifesto for software development together we are uncovering better ways of developing software by doing it and helping others do it through this work we have come to Value individuals and interactions over processes and tools working software over comprehensive documentation customer collaboration over contract negotiation responding to change over following a plan that is while there is value in the items on the right we value the items on the left more before you take your agile scrum Foundation certification exam I recommend you memorize these four lines we call them the statement of value and you can see that on the right hand side those are items that are more relevant for the traditional or waterfall approach and on the left you have those things that are more agile in nature let's review each of these four lines individuals and interactions over processes and tools clearly any project requires processes and tools however individuals and their interactions deliver better results when the emphasis is not on the processes and the tools working software over comprehensive documentation documentation here refers to things like status reports progress reports detailed specifications which do not really demonstrate any real progress or value therefore the emphasis is on working software that can be delivered and demonstrated customer collaboration over contract negotiation organizations need to be flexible and accommodating rather than following detailed definitions listed in contracts responding in to change over following the plan in agile small pieces of working software are delivered to the customer incrementally and the customer is involved in the project from the beginning to the end so in agile we are responsive to the customer and willing to make even midcourse Corrections in order to deliver to the customer the value that the customer wants remember you will be tested on these four lines so again I urge you to memorize them in fact knowing these four lines and having a feel for what they mean will actually help you get to the correct answer on many questions in the exam here we can see what it might look like to manage a project using the waterfall approach you can see that the system and software requirements would need to be identified and documented upfront that would be followed by the necessary analysis and program design work then comes the actual ual coding and testing that's Then followed by the handoff to the customer or to operations as you can see there is a heavy upfront cost of documentation as well as the status reporting that would be to be done during the course of the project you can also see that it would be difficult to respond to change in this kind of an approach in fact the Standish group issued a study that showed that software development projects using the agile approach succeed three times more often than when using the waterfall approach the Standish group defined project success as being on time on budget and delivering all of the plan features the study summarized as follows the agile process is the universal remedy for software development project failure software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns now let's talk about strum versus agile firstly let's have a look at methodologies now agile is a set of principles that are iterative and incremental agile has a number of different methodologies you can choose from there's XP Crystal can ban even scrum for that matter let's talk about scrum now scrum is an implementation of the concepts of agile so basically most of the important components of agile can be applied to scrum as well it provides the customer with incremental builds that are delivered to the customer in the span of 2 to 4 weeks an organization can be agile but not practice Crum however an organization cannot practice crumb without being agile next up let's have a look at projects agile is more suited towards projects that have a spa development team that consists of experts whereas on the side of scrum it's usually better suited for projects that are subject to a large amount of change and that do rapidly next we have leadership now for aile a project head takes care of all the tasks and has a very important role to play in the process of a j a project head represents the entire team and is responsible for getting issues resolved by assigning them to the appropriate members of the team in scrum there's no leader there's a scrum master who can overall guide the scrum process but the team addresses issues by themselves it usually involves cross functional and self-organizing teams next up we have flexibility agile is relatively more rigid than scrum and cannot handle changes with these it also requires a lot of upfront development process and changes within the organization with scrum you can enable teams delivery agile requires frequent deliveries so that they can get feedback from the end user this in turn will help make the product better the product is delivered as well as updated on a regular basis with scrum after a print feedback from the client for a build is provided to the team scrum involves daily scrum meetings to review and get feedback to determine the next steps of the project the next print is only planned by the team after the current Sprint is complete next we have collaboration with agile collaboration involves face to-face interactions with team members of other cross functional teams first scrum daily standup meetings take place with specific roles like scrum Master product owner and the scrum team and finally we have design with ag Gile the design as well as its execution it's relatively simple with scrum the design and its execution can be Innovative and experimental so you might be wondering which one should you choose now among both these options there one thing that will remain common agile now what you can decide upon is which agile methodology you'll be choosing is it lean is it Canan or is it scrum now if you do want to know more about how scrum and Canan are different from one another you can check out our video scrum versus Canan can ban comes from the Japanese word can bam which literally means signboard like scrum can ban is a popular agile framework that is a visual system by which the work can be manage with ease as it progresses Canan uses something known as the can ban board to make these things possible with this you can easily identify bottlenecks and then fix them cost effectively at optimal speeds the main focus with can ban is transparency since everything related to the the tasks are on the board everyone can keep themselves updated it also ensures the team's focus on their current tasks until they're done this limits the amount of work that's in progress so on the can ban board work is divided into smaller more manageable pieces the work that's needed to be done is written on a note or card and placed on a board columns on the board help represent where each item is with respect to the workflow now let's have a look at what these are in detail let's find out how Canan works now the board consists of three major components there's the to-do list which represents items that need to be completed the ongoing column which represents items that are being currently work worked on and the completed or the done column now these represent tasks or items that have already been completed now although this is a physical representation of the board several organizations use software versions of the board that replaces the sticky notes with cards that can be moved from one column to another as work progresses now an example of such a software is Trello so if you want to learn more about Trello you can check out the link link I'll be adding to the live chat in a moment at this point you guys must have realized how similar these two Frameworks sound so let's run through some more of their similarities let's find out how they are similar firstly they both have principles of lean and agile which means reduction of waste and both of them are time boxed and itative approaches that enable product delivery in an incremental manner both these Frameworks aim to reduce the amount of work in progress this forces the teams to ensure that they focus on a smaller set of tasks this also makes blockers and bottlenecks a little more visible in both cases the work is divided into smaller more manageable units both of these Frameworks use pull scheduling now this means the products are only Built based on demand rather than forecasts transparency plays a major role in both these Frameworks by helping them Drive process Improvement and in both cases the release plan is continuously optimized and finally both these methods aimed to deliver releasable software often and earlier than expected so so now that we've reached Midway let me ask you guys a question do you guys use scrum or can band in your workplace or do you use these software for personal reasons what exactly do you use these for let me know in the live chat now let's have a look at how these two Frameworks are different from one another firstly let's have a look at Cadence Cadence refers to the amount of time in a Sprint or before a release so when it comes to scrum the entire project is divided into time constrained iterations that is into smaller manageable units but when it comes to Canan it's even driven the next criteria we're going to have a look at is release methodology in scrum releases take place after each Sprint which usually takes 2 to 4 weeks to complete for Canan releases take place in the form of continuous delivery they happen in such a way that changes like new features configuration changes bug fixes and experiments get to the users in a safe quick and sustainable manner next up let's have a look at how changes are addressed in both these Frameworks in scrum no change can be made while the Sprint is in progress once it its complete changes can be considered in the Sprint plan and then added to the Sprint backlog with Canan changes can be made at any time and incorporated into the workflow now let's consider the metric that's being measured in scrum for planning and process Improvement velocity which is the measure of the work that can be completed by a team in a Sprint is the key metric in Canan Le time is the key metric this represents the period of time between a new task's appearance in your workflow and its final departure from the system next let's have a look at how teams work in these Frameworks in scrum you need a cross functional team to achieve your goals in a Sprint in Canan cross functional teams are optional but specialized teams that focus on particular aspects of the workflow are are required now let's talk about new additions in scrum just like handling changes you can't add any items between a Sprint or an iteration in can band new items can be added to the board as long as there's capacity available for it now let's have a look at the job roles Within These Frameworks scrum has three major job roles product owner scrum master and scrum team with can ban you don't have any specific job roles now let's talk about representation or moreover let's talk about how data can be represented with scrum the Board needs to be reset once a particular Sprint is complete with Canan the board stays persistent throughout the entirety of the project and finally let's let's have a look at project link with scrum it's better suited for longer projects and with Canan projects that can be completed in a shorter period of time are better so which one should you choose now selecting from these two methods is mainly based on the requirements of the team do you expect your project to be shorter do you want to make changes at any time you don't want to set up job specific roles then can ban is the framework for you or do you want a long running project with different job roles and involving cross functional teams scrum is the answer for you based on the differences we discussed in the last topic you can make an informed decision now let's have a look at some of the popular companies around the world that employ both these Frameworks some of the companies that have successfully implemented scrum our Facebook General electronics and Adobe companies that have implemented Canan our seens BBC and sap so are you interested in becoming an agile scrum professional here we have certified scrum Master CSM certification training course so hurry up and enroll Now find the course Link in the description box what I want to do team is I want to before we get into the user stories I want to go to the white board and I want to just give you a little bit more information that might help us in organizing our discussion that we're about to embark on here so a word that is not in our slides is themes themes are epics and user stories grouped together you know similar epics and user stories grouped together for planning purposes so an epic is Big um you would never do an epic in or pardon me a theme in a Sprint it's too big um so it's used for planning purposes below that I would put epics ethics are low priority large user stories meaning that an ethic will eventually have to be disaggregated into multiple user Stories the reason it would be low priority is because if it if an epic was higher up on the product backlog um it would have to be more detailed that's when you would break it down so epics are usually going to live at the lower uh priority levels of a product backlog and as user stories are completed in the Epic rises in priority it will eventually be broken down into um more manage ible user stories so great big low priority user stories then we have user stories themselves user stories are functions or features that the product owner wants to have developed a user story turns into working software that provides value to the customer and um and the product owner is the customer voice the product owner is the one who would accept or reject completed user stories and then there are tasks and a reminder when we were talking about the Sprint planning meeting we said the Sprint planning meeting is uh got two parts to it the first part is selecting all of the user stories that are going to be included in the Sprint and then disaggregating each of those users stor into tasks that's done in the Sprint planning meeting and then those tasks are the things that are actually then done when the uh work of the Sprint begins user stories can be estimated in story points or ideal days most teams favor story points they might start with ideal days but they will then usually end up going to story points um Tas s are uh estimated in I ideal time which is usually hours okay so now back to our slides so at the top left a use case could be an example of a user story so it's something that um the user wants to do and how the system should support it um like um a use case could be um select and pay for items in a catalog now that could actually be an epic or maybe a theme because maybe it would get disaggregated into log on screen uh catalog uh shopping cart and checkout but so the use case could either be a standalone user story or it could actually be uh a number of user stories um that would result from it below that requirement it could be a functional requirement a technical task or even a bug fix so I'm going to go back to the Whiteboard and a product backlog is going to have a lot of user stories that come from the customer right whatever the customer wants then but the team may know that it has to do some development work in order for the user stories to even be able to work you know there's some system level non-functional requirements that need to be done and so there could be Tech user stories and then can you see this low I can't see your chats but then there could also be defect user stories there could even be risk user stories now what could happen is that um the product owner ranks these in priority so this one first then that one then that one and the team says well the only thing is is that um we have to do some development work before we can actually do user story to and so what we really need to do is insert that before the uh the second priority user story and so the priority of the user stories in the product backlog while it might start with just being you know simple functional user stories coming from the uh product owner it will evolve until it includes some other things that are also considerations when it comes to uh priorities because of you know successor predecessor relationships dependencies and things like that are um considerations a user story be uh back to the the uh screen um bottom left now the user story um can use a fictitious user or a Persona to help uh the team or the the team and the product owner to get an idea of okay who's going to be doing this function uh what are they going to need in order to be able to complete the function Etc so you try and um come up with an actual well a fictitious but a person who's actually doing it to kind of get out of the realm of you know listing requirements and you know specs and things like that and say okay what's the user experience need to look like top right template a portion of a user story is um let me back up so a user story card um is usually going to contain um a brief description of the user story using some kind of a metal language format like we're suggesting right here as a user or Persona I want want this feature so that I can so not unlike our um estimating session here as a frequent traveler I want to eat grapes so I can be healthier in the one that we uh didn't do uh the inventory system as a customer okay there's a a user I want to get cash back so I don't have to wait in line at the bank okay here's another user story as a consumer I want the shopping cart functionality to easily purchase items online and maybe that could be customer as well um as an executive right as a suit I want to generate a sales report so I know which departments need to improve their productivity as a buyer so you can see I I tried to come up with these different roles right here executive buyer sells rep Etc um and that's the format as a type of user I want some kind of goal um or feature and uh so that's some kind of a reason um the below that connect connect the dots by writing all of the user stories necessary to uncover the entire use case so like we were talking about right here if you want to be able to purchase items online from a catalog that might be uh multiple user stories in order to support that use case and so of course um we would want to be able to connect the dots and see where all the user stories fit in into the overall goal of the project or release and the stories um excuse me um are grouped to form an epic or higher level story so epic or theme um stories can then be split into child stories or task and so that's what we were covering before right so you have um themes up at the top that's the biggest grouping if you will used primarily for um you know high level planning purposes so you have your themes then you have your epics which are large user stories um low priority and they're going to have to be broken down into smaller user stories like in the question that we had at the end of the the last section where um the product owner needed something done and the team said well based on the size of this user story it's going to take three Sprints to do well a user story has to be small enough to be completed within a single Sprint so a Sprint can contain more than one user story but a user story cannot span Sprints so that feature or function that was in the question was probably more like an epic it was something that would need to be uh disaggregated into smaller user stories or perhaps it was more of a use case that would need more than one user story in order to actually deliver the overall use case let's see as a product supervisor I want to see an unfinished part list at the end of the day so that I can reallocate work the next day great user story description well done verage um did you hear that team as a product supervisor I want to see an unfinished part list at the end of the day so I can reallocate work the next day that is a well-crafted description of a user story now here are some things that I want you to memorize you were hoping I was done with the memorization part so I want you to um remember that we have to invest in our user stories and I was going over to the Whiteboard and I didn't change cameras so let me do that I recommend um you know figuring out how you memorize best so that you can if um well not if you wanted to what I recommend is being able to write out all of this stuff on plain white scrap paper in about 14 minutes because that's the amount of free time you have in the tutorial when you're at the uh or when you're taking the test um exen does a little bit different you maybe won't have a tutorial the only time you'd have a tutorial is if you were at a center taking a test um exen has other options like you can do a paper based test um uh where you get a third party you know a buddy or somebody who will agree to sort of proor the test for you or you can do it on your laptop all by yourself and they have software that watches you while you're taking the test and they require you to take the laptop and do like a 360 so that um they can verify that you don't have any cheat sheets up on the wall or anything like that but the point is is um you got to have this memorized um whether you're going to dump it out on the paper or not um when I took the test um I actually did the paper based option um and that was because of some kind time constraints and it was the quickest way to get me into the test and so I didn't write out any of the stuff I'd memorized but I had it memorized and I had it memorized well enough that I could kind of recall it in my mind's eye okay so we're talking about user stories and you have to invest in your user stories you know I like memorizing things by creating these charts that have the first letter of the word or phrase that you're memorizing in a separate column and then I make up a story you know that uh um reminds me that I've got to have I in V EST this one is pretty easy probably just invest Works um but so let's go over that I stands for independent independent meaning that each user story stands on its own um you don't have when we're doing scrum you don't do a user story that won't result in working software we just talked about the description of user stories right so it's a user that needs some kind of functionality for some kind of a reason and they're all independent will they work together of course they'll work together if that's a necessity but um if you developed a a log on screen you could demonstrate working software for the login screen there might be another user story that is um you know has to do with displaying uh the catalog and being able to flag or select items that you want to purchase but there'd be working software for that would they work together yes but each user story would complete um or result in some kind of working software and they have to be independent negotiable negotiable in the way the user story is going to be implemented the product owner doesn't dictate to the team the team doesn't say it it's only this way and we don't want to hear anything from you so there are discussions about the size and implementation for each user user story so the product owner can't make it so detailed that there's no room for discussion and the possibility of you know the team coming up with Solutions other than what the product owner was attempting to dictate um v stands for valuable meaning each user story has to create value for the customer or the end user e it has to be estimable as an estimat except estimat is not really a word it's estimable um and asses for small has to be small enough enough to be done in a single Sprint if we're doing two we Sprints has to be able to be done in two weeks or less if we're doing four-week sprints it could be a larger user story but it would still uh have to be done in four weeks or less and then the last one the t is testable every user story needs to be testable and it needs to be testable at two levels remember our triangle needs to be testable at the intrinsic quality level unit tests Etc and also testable at the extrinsic level which is the customer point of view which is acceptance so every user story uh has to be testable okay so that's invest and so let's add that to our list of things to memorize invest and then the next one we have here is um the three C's of a user story so the first C team is cardred so user stories should be able to be written on a 4x6 in index card or some uh media similar to that card the the second C is conversation the user story card is the item that is used for the team and the product owner to talk and discuss in order to make sure that the product owner and the team are on the same page when it comes to what is actually supposed to be developed and um uh what you know so what it's supposed to look like at the end which leads us to the third one which is confirmation each user story essentially has to have acceptance tests um in it itself so card 4x6 conversation that's the starting point that's where uh the team and the product owner discuss and then eventually there will be acceptance tests included on the user story card um in order to be used during the Sprint review to um assure that it's acceptable that there's kind confirmation okay so oh let's add that to the memorization list so three C's all right now I've got an example here of a user story card so we're looking right here and if you were to go out on the internet and search um user story cards um they would be similar there would be some differences of course um but typically what you're going to have is you're going to have a title or a name for the user story and then there's going to be some kind of unique identifier like user story 321 then there will be the description like we just talked about as a librarian I want to have the facility of searching a book by different criteria so that I will save time while serving a customer then there might be some other descriptive words or links to other information that might be necessary and then there would be acceptance criteria or tests sometimes these get included on the back of the card but the point is is that they are on the cord on the card rather then there will be an estimate of size it could be ideal days or story points as I mentioned most teams do story points that's more likely what you'll be tested on as opposed to um ideal days but you know we'll cover both so you understand uh the differences um there is probably it's not listed here but there's probably going to be a um value point assignment this is where the product owner um kind of determines in a relative way the uh value of the stories just like we were doing in planning poker the product owner might say well this story is twice as valuable as uh this other one comparing them together and this is what um these value points are what's used to uh prioritize the user stories that's supposed to be a v as in value points and then typically there's also going to be a indication sometimes it's just by colors um it could be words uh that has to do with um you know where the story came from did it come from the customer that would be considered a functional requirement um if it came from the team that would be from the technical domain I'm trying to write where from uh you know it's not me team it's the mouse clearly it's hard to uh do that that's from where from um here it's got uh customer tech you could also have defect you could maybe have risk um and then there's also going to be an X Factor um which would be some kind of word probably like um stable um erratic um incomplete something like that to uh so that the team is designating the user story in uh respect to the amount of uncertainty or risk that's associated with that user story and because all of that's a part of the story right the story is going to be turned into working software there may need to be uh some efforts to actually figure out how to actually do that user story so that's the X Factor um over to the right here on the same chart we have some comments about um if you are using a uh software package excuse me like Trello or jira or something like that excuse me the user story cards will generally be able to contain more information using you know dynamic links and things like that um could even include things like responsible team member or depending on how you're doing it you would break the user Story down into tasks and you might have team members assigned to various tasks for the user story um okay so that's typically what a user story card is like sometimes their cards sometimes are like on sticky notes and they're put up on a can band board if you're using can band to track the project if you have a story that is too large to be completed in a Sprint it's going to have to be subdivided or we call it disaggregation into um smaller user stories and there's uh three ways that we're proposing here that you could go about doing that you could split it based on operational boundaries for example as an operator one needs to manage reservations which could be split for example there could be one portion that is uh that has to do with making a reservation another one that has to do with modifying it and yet another one that has to do with cancelling it so um that could be split into in this construct here three separate user stories you could also separate based on exceptions or crosscutting concerns for example in the beginning develop only one main path like accept repayment for a loan then address exceptions like what if a person um overpays then um come up with a user story that recognizes that and processes a refund and or gives the option of allocating the overpayment to a future payment or something like that and then also um um adds on other concerns like the tech access restrictions or record name of operator so maybe um you know when you're working on uh accepting pay payments or processing refunds it's going to check on um who the operator is or track that so that if at a later time you know who was it that gave this uh refund here well you could look and see you know okay the the operator's name was recorded or maybe you put some restrictions so that maybe not everybody um is allowed to do a refund and so you would have levels of users that have different privileges okay and then down at the bottom split Based on data boundaries for an example you know as an accountant one needs to enter balance sheet information um which could then be split into summary information and separately um uh receivable details or you know maybe you could have AP you know so you could have different portions of the overall um balance sheet um activity that need to be done so enter AR enter AP Etc make sense so just to kind of uh prompt you give you some ideas about what to do um in a scrum project if you have the scenario arise where a user story is being estimated by the team and it won't fit into a Sprint it's too big now when it comes to determining value for user story this is primarily owned by the uh product owner right and it always comes back the money but money you know the value can be looked at from different points of view so new Revenue obviously you know getting new customers and having them buy stuff um well below that there's another consideration incremental Revenue uh so somebody's in the process of placing an order um maybe they're are some premium features that could be add-ons at that point in time um or maybe added later on so you have an existing customer who actually buys um more of or enhanced parts of the existing thing they already purchased or are in the process of purchasing retained value so this is um you know retaining customers so that they don't go to a competitor and then the bottom one is operational efficiency you know how could things be done to speed up the process of whatever it is um so that the cost of delivering uh the product is reduced so this then leads us to a discussion about priorities recognizing that there are some priority concerns that come from from both the customer domain as well as the technical domain and there are some prioritization models um if we look right here there is value based prioritization and the hierarchy of that would be high value followed by high risk followed by high value and then low risk followed by low value and then low risk so you know we might have written this a little bit differently but that's value based prioritization and this is primarily the product owner with maybe some input from the team just simply deciding um what he or she wants the most listening to the team say well you know there's some you know greater risks with this user story than that and so you'd probably want to uh persuade the product owner to take care of high-risk stuff first um because that would have an a uh oh excuse me sorry an impact on the future things that need to be done there's the K the Cano model uh which looks at each of the user stories and classifies them as being mandatory linear or exciters and the mandatory items are those user stories that are musts and they'll never move Beyond move the customer the end user Beyond neutral it's if they're not there it creates dissatisfaction if the the you the product owner and the team has done a good job in identifying what are the mandatory or threshold items um you would see that um um it just gets it to neutral that's what's expected for the product linear items um user stories are those us user stories that as they are implemented progressively throughout the project and added to the feature set it will linear increase customer satisfaction and it can be you know in their absence dissatisfaction all the way up to high implementation creating a great deal of satisfaction for the customer and then the third category is exciters and delighters um and those are features or functions those are user stories that are not mandatory and the absence of them will never result in satisfaction going below neutral but by adding them um you could create excitement and Delight for the customer these would typically be things that are features that would be included in a premium version of the product or maybe add-ons that are promoted you know at the point of sale you know if you thought about this because it'll really help you or whatever so that's the canal model and then there's weager relative waiting method and um this is all using numbers so each feature is given a value for its benefit and it's penalty given a value for penalty meaning what's the pain if that feature or function is not included and then there is um um the cost side and the risk side and then those are all calculated together and that results in excuse me a ranking or a hierarchy which gives you the uh priority for the uh user stories um we also talked about Moscow didn't we did we talk about Moscow uh Moscow is another prioritization model must could I said that differently must should could won't Moscow mscw must should could won't and we talked about that one thank you for that confirmation does it seem like a long time ago or is it just me I know it was just last weekend but it's like last year okay so now let's talk about velocity um uh prianka that is exactly right um so velocity is the capacity of the team to complete work in a single iteration so the team has estimated the user stories uh for size or ideal days and um the Sprints are going to be three week weeks in duration obviously not all user stories can be be completed in a single Sprint and be done with the project well I guess maybe I shouldn't say Obviously when I'm saying that I'm thinking well maybe you had a very small short duration project so you could but the point is is that uh it's the team's capacity to um complete work in a given Sprint and it is an observation it's not a prediction so if we're working on Sprint five and we're working on determining what our velocity is then um it would be the average of the previous four Sprints if there were any uh outliers You' you would uh disregard those um and so it's an observation if we look over to question or uh box number two here velocity is used to deal with um determining how many user stories we are going to include in a given Sprint and also how many Sprints are we going to need to create a release or a set of user stories and here's an example in box number three a team completed five user stories that were sized 5 38 1 and two two user stories each sized five were left half complete what is the velocity of the team and the answer is either going to be 31 or 36 31 is the sum of the completed user stories um if you were 36 you were claiming half of the two that were five five uh so that would be a total of 10 so you claim half of it which would be five would take you to 36 but it's not going to be 36 because the only thing that counts towards progress is working software so even if the team had finished nine out of 10 story points for a user story meaning it's almost done and then the Sprint ends that doesn't get counted towards velocity and you don't mess around with velocity um you can mess around with your estimating and you can mess around with um you know what user stories are going to be completed in a Sprint but you don't the the velocity is not variable it is what it is based on past performance when it comes to levels of planning we have What's called the planning onion and let me walk you through through this here up at the the broadest area is the vision level so the vision level that's the suits right they're the ones that have the strategy and objectives for the company and where it's going and so they have that overall big vision for the uh company which is likely going to include products and each product should have a road map my example of that website that I'm uh working on has has uh three versions um which make up the product road map version one is the free site version two is the membership site and version three is the um uh the pay referral commissions uh uh version of the site and the product road map is then supported by releases so for my project I have three releases so all of the user stories needed for the free version are in release one all of the additional user stories that are needed for the um uh paid version the subscriber version uh and then also for version three those are all releases three releases and then for each Sprint we will be pulling user stories from the release that we're working on a release is likely going to take multiple Sprints and um and then the Sprints are populated by the individual user stories which are then disaggregated into tasks and we do the excuse me the daily scrum which is the daily level of planning and coordination so we call that the planning onion we already kind of talked about the release and road map um concept here so let's just review this quickly um priories high level epics and determine goals and releases so we'll use epics and themes in order to group things together you know what should be included in what release so what are the goals for the releases then the first bullet point establish goals of release based on market demand regulatory needs or customer expectations for each release you want to estimate the target stories repeat until the target stories are assigned and iteration length I should that's it's blending some things here um be able to estimate velocity and then uh assign stories to the Sprints so we keep estimating the user stories and we keep organizing uh that until we can do that we can come up with an iteration length or Sprint length and then figure out what our velocity for each Sprint is and then uh assign stories to the uh the Sprints uh the the next bullet down iterate until the user stories and release date meets conditions of satisfaction so that's uh definition of done or acceptance for the release and try not to pack too much into a release backlog so um just like you would not want to pack too many user stories into a Sprint you want to have the timelines appropriate and uh what are included in the uh events uh make sense okay so here's a bit more about release planning on this slide here um you've got the product backlog here on the left and then we might come up with a release plan which could be flipped and could be looked at uh horizontally and you probably plan um about three releases in advance uh um or at least you're doing more of the detailed planning on that uh because things are going to emerge when we do you know Sprint one that's going to help in Sprint two and things that happen in Sprints one and two that are going to help um release three and then you've got um you know your subsequent releases where we're just doing very high level planning it's called rolling wave planning where we do detailed planning for things in the future in tandem with doing high level planning for things in uh the future did I say that right detail planning for things in the near term in tandem with high LEL planning for things in the future um and we talked about deciding as late as possible I believe meaning that it's better to actually plan the later uh releases uh for purposes of uh making sure we have more information uh the most information available okay so s estimation let's start at the top left the principles behind estimation understand the cone of uncertainty which is an estimate or best guess to begin with and then progressively becomes more accurate in fact let's just take a break and look at the cone of uncertainty so at the very beginning of a project there's going to be a high level of uncertainty um if I were to draw this chart I would make it a little bit more like this so clearly you're going to drisk the project as early as you can and then eventually all risk disappears when the project is done risk is uncertainty okay below that the only estimate that matters is the one given by the teen supported by this uh comment here nothing is impossible for the one who doesn't have to do it so the product owner is like team come on you can do this the team's like no we know what our velocity is no the product owner says I'm telling you there's no way that that can't be done I know you can do it I trust you I believe in you but the product owner doesn't have to do have to do the work okay top right overestimate and underestimation is always going to be an issue that we deal with it's more likely that we will underestimate than overestimate and by looking at our velocity from iteration or Sprint to Sprint um there could be some information that is um showing us that we're underestimating for example meaning um we're we're thinking we you know the user stories are smaller than they are and that we can get you know a certain number done in the Sprint and then there's a fail well that would mean then that would be discussed during the retrospective and then we would do something different going forward which might include doing some reestimating scrum estimating is not necessarily more difficult however scrum exposes bad estimates sooner which is a good thing when we were doing our um uh planning poker you can see that um the first time as a team you know we didn't know each other we didn't know everybody's thoughts and concerns and those kinds of things you know get shared and absorbed as a project goes on and so there's a higher awareness of that so um what we would say is that um using estimation techniques scrum estimation techniques might be uh more inaccurate at the beginning of a project but they will quickly become very accurate as the um project advances forward let's see is there a question here can velocity be increased over a period of time for the project yes it can now it's not that it can't it will increase if the team is learning how to work together better and better you would expect that if I could just use my mouse here if we were tracking velocity so this would be um points completed over here uh let me just do pts for points and down here is time and we go from Sprint to Sprint right you would expect that maybe you know the first couple of Sprints the team would be learning how to work together and there would be a steep curve and then it would kind of flatten out and maybe have you know a slow rise going forward as the team emerges as a high performing team they get better at their cross uh functional Behavior you know somebody's the team just keeps chugging along um other things you know just um oh sorry there I bumped the thing on my screen there um um so the team you know learns how to work better together and you know their estimates become more accurate Etc and you would expect a high per a high performing team to have a uh a result like this for velocity where there's quick Improvement and then it kind of stabilizes and then begins to tick upwards okay we talked about the cone of uncertainty let's talk about ideal time um when we do estimating for user stories um we do it in ideal days when we do estimating for tasks we do it in ideal time which means hours I think that's on the Whiteboard or it was on the Whiteboard oh it was on it um so ideal time is the amount of time it takes to complete a piece of work but that's based on the notion that the team member or members are available to do just the work with no distractions or anything at all so assuming that um prian could sit down at a keyboard and code for 8 hours without taking a break for lunch no phone calls no discussions no meetings of any kind just work eight hours how much could be done in that eight hours by Priyanka that's what ideal time is but the thing of it is is that there is no such thing as somebody being able to spend every minute of every day only doing work there will be um distractions so it has to be be converted into a lapse time now we don't convert it to aapse time at the user story level but we do convert it to aapse time when we are dealing at the task level and what that looks like is you know for each team member you're going to have to do it separately because some team members have more distractions than others some might have other duties that pull them away um whatever the case may be um you Det determine how much time in a given day a team member is available to do work so say it's 5 hours out of eight for one maybe it's six hours out of eight for another maybe it's four out of eight but you figure out what it is and then you take the average and that average availability is used then to convert Ideal Time into elapse time um I should have circled this box because we talked about this as well um and then I already mentioned this here only considers actual work time not the distractions so that's the concept of Ideal time when it comes to story points it's different than that they are a measure of size relative to each other so we were doing planning poker this morning where um we were looking at grapes versus apples and then we were looking at oranges and and what else do we have watermelons and coconuts and we weren't trying to figure out how much time it would take to eat grapes as opposed to how much time it would uh take to eat a coconut it's clear that it's going to take longer to eat a coconut because there's more effort involved so we have a sense that it's going to take more time but comparing the coconut to our Baseline of two right we came up with a baseline of two for the smallest user Story We compare eating C to that Baseline and we say okay you know what it's going to take more effort to uh eat the coconut than it is to eat grapes or apples um so you can do it like we did you can also triangulate um for example when we did our planning project this morning or this morning for me rather at the beginning um oh that's not it that is the daily standup here it is is if I had said Team I want you to pick a small user story a medium user story and a large user story um and then we would then compare other stories to those three and so we would kind of triangulate on it um let's say that we did uh you know two was small uh I'm sorry I'm saying that wrong grapes was small apples were medium and coconuts were large well if we then looked at Orange and we said well you know orange is um smaller than Apples but bigger than grapes so we would know this would fit in between grapes and apples um and so let's say you know we had apples at five and grapes at two then we would say an orange is probably going to be three and the value use you know now I used um in our example the modified Fibonacci series uh what we do in scrum and Adel if we're using story points we're going to use um a nonlinear scale for the values so down at the bottom here there's the modified Fibonacci Sequence the way the Fibonacci sequence works by the way um um it's the the value is the sum of the two on the right so let me break this right here because this is a modified Fibonacci so 13 is 5 + 8 8 is 3 + 5 5 is 2+ 3 and 3 is 1 + 2 if we were doing the real Fibonacci series this wouldn't be 20 it would be 13 + 8 which would be 21 um and I don't know why some use modified Fibonacci and others not but that's just kind of a common thing to do if you're doing planning poker you give everybody seven cards one two 3 58 13 and 20 um another nonlinear scale is doubling 12486 um you typically don't go too far to the left with the values because um that either means that you're being too granular or you've got stories that are probably too big and they need to be disaggregated now somebody just chatted here um should some suffer time be included in the actual estimates um let me answer that question first by going back to Ideal time and then I'm going to come back to story points and answer the question when we're estimating in ideal time we don't add a special amount of time that we would call a buffer we just allow for the distractions and the interruptions which could look like a buffer right you're saying you know um you know prianka if um based on your duties in the organization and our uh workday of eight hours you're typically available to be doing your project work five out of those eight hours so when we are converting ideal time to elapse time um you know we will be building in extra time based on distractions and interruptions we would not call it a buffer but that's essentially what we're doing now when it comes the user stories that we're using story points it is different um the points are for the entire amount of the work and why might we need to have some extra time for a user story well it's likely going to be driven by uncertainty there might be other uh things that impact it but that's the main thing sorry team so when the team is estimating the size of the user story they will be including in their discussion and estimates any extra time or buffer time that would be needed for uh that user story to be completed so do we accommodate um uncertainty when we're using story points yes we're looking at the The X Factor and if we've got an unstable user story then we're probably going to um say you know this is going to be a bigger user story than one that's similar but has a a much lesser level of uncertainty um so that's the story points let's compare the two um Ideal Time uses things like hours and days which is easier to explain outside the team right the suits like things in days and hours everybody's estimate may be different not a bad thing it's easier to do at the beginning because we're oriented to think about time um and it does kind of shine a light on wasted time story points um are harder to explain outside the team um you know the suit says well um how long is it going to take to do user story 301 and our answer is um well that's a 10 user story Point user story and the suit's saying what does that mean tell me how long it's going to take um so the suits have to be converted to uh uh story points now here's the thing it's a lot easier to get consensus when we're estimating in story points and once we get good at it it's going to be much faster we have to remember it's not comparable across teams so you know a team working together will have its own kind of system for for sizing the stories and another team that might even be working on the same project will have a CO a whole different uh scheme and so if the velocity of one team is 25 and the velocity of another is 50 it doesn't mean that the team with the velocity of 50 is able to do more work than the teams whose velocity is 25 and we did um when we got our day going um we started with um uh a planning poker exercise and so you know we used all of the team members so we selected the team the product owner was there to answer any questions um the team discussed each of the story cards and then um decided what their vote was going to be and then everybody voted at once if there were outliers they were discussed and um the reasons for that uh those variances those outliers um were then part of the discussion and then we did another round of voting and we would keep doing that until we had our estimates converge or we reached consensus on that okay so advantages of planning poker it's fun it's quick it gets the whole team involved the the team understands um a little bit about all of the stories everybody contributes his or her expertise and the discussion during the estimation provides Clarity in the direction approach and even a bit of design if we were in the same room team and we were doing a planning poker activity like we did uh at the beginning of our day uh together um we would be able to you know model it a little bit better or if we tried to unmute everybody but you could hear the background noise I've tried doing it it doesn't really work but you get the idea that if the team's discussing and things like that you would actually get to the point where um your estimates would converge and the team would say okay this user story size is you know whatever it is okay so we need to wrap things up for the day so we are ending right here and that means tomorrow when we get together we're going to be doing slide 20 we starting with that which is Affinity estimating and let's see Affinity estimating we go through that we're going to talk about tracking progress using um information radiators and then we're going to talk about what we do when we find variances between the plan and the actual results and then we'll have our quiz so we're almost finished um I think we're good on time so are you interested in becoming an agile scrum professional here we have certified scrum Master CSM certification training course so hurry up and enroll Now find the cost Link in the description box now let us look at a typical scenario of an organization where the need of user stories would come in so looking at this scenario so an organization would have a scenario where the existing products are sold very well in the market and uh they may think about introducing new product or they may think about introducing a new feature or functionality to the existing product so the scenario what we are considering is it says our previous product sold really well in the market now let's think about new products so we'll need to make sure we can understand the require requirments and fulfill their requirements now how do you do this so how are you going to understand the consumer requirements user requirements and how is that going to help the user to accomplish their requirement and fulfill the need whatever it's required to be fulfilled so user story helps one who understand the user stories would look at the perspective of the users and these user stories provides those inside towards what user would exist so as we go through we will understand in the perspective of the users the requirements and how user stories helps in terms of fulfilling those requirements this requires certain amount of visualization let us see what it is so what are user stories user stories are an agile software development project management tool that provides users with simple natural language explanations of one or more features written from the end users perspectives so for for a given product we may have many end users so we may develop an application within an organization and use that application for an organization that is one scenario second scenario is we create a product we sell it and employees of our customer organization will become users of those products these are the two scenarios so having these scenarios what kind of product it is what is the objective of this product which is going to fulfill so let me assume an HR application which is used for submission of claims from the employees so what is that requirement so these application should accept the claims submission from the employees of the organization and then that needs to be processed and the claims needs to be uh clear now what will happen now the user Community if you visualize there is an user as an employee of an organization who submit claims so there is an user in the finance perspective who is going to deposit the money similar L there is an user who is going to approve so many such user interfaces we will see the existence of the roles of users we will see who would be using these particular applications so in their perspective there should be an interface provided there should be some privileges provided through which they would do their transactions and activities when we raise the user stories we don't write them in detail so a user story doesn't go in detail it just mentions how a certain type of work will bring value to end user so what is this role specific end user would be doing at that particular role in this particular product what is the transactions involved so the end user in this case could mean external end user or even internal customer or colleagues within the organization so looking at these points if I look at the same application HR claim processing application who are this internal users the employees of organization so who are these external maybe the people who sold this particular application to our organization so they have installed it they manage it there is an Administration role for this particular product that is a role similarly another set of internal users maybe someone who is like from Finance from HR so in each of these roles perspective this particular product should provide the interface and then there should be a transaction in their perspective which is very important so user story should explain this in very brief so that it helps in terms of visualizing what kind of interface has to be provided and why would this particular role use it that is very important so user stories also form the building block of agile Frameworks like epics and initiatives so what is this epics what is this initiatives let us look at it now epics refers to the group of user stories where the large amount of work broken down into user stories so many user stories together forms epics which will provide certain Insight towards how these user stories are connected with each other so similarly initiative refers to combination of multiple epics forming that initiatives so which is very essential to group so managing perspective it will become easy and also looking at the objective what is that particular group of user stories group of epics are going to accomplish so user stories can also help ensuring that team work to goals of the organization through epics and initiatives it should be looking at the objective exactly what is the directions we are getting into and how these combination of user stories so as an employee I'm submitting my claims so what is that required in that users perspective there should be story so I as a finance person I'm going to clear these claims I'm going to pay the money deposit the money so that is that particular role needs certain interfaces and that visualization requires how this interactions happens so user story should help in terms of understanding those so the requirements for making user story a reality are added later after discussing with the team so we made an user story we created an user story it doesn't end there so there needs to be a discussion which happens further to decide yes it is a valid user story so this will also helps in terms of prioritization which needs to be taken up first so user stories are recorded on post it notes or an index card or a project management software and this would help in terms of prioritization or for tracking as well so what is the advantages of user stories so advantages of user story involves it helps in delivering high quality content because what is required to be accomplished in the user perspective that will be very clear EES collaboration with team members because finalization on the user stories and understanding of the user requirements would happen after discussing with the team members each one would give their own uh viewpoints and uh prioritization of particular user story or keeping a specific user story or not considering that user story would be based on the feedback which team provides this cannot happen in terms of having team members together and speaking about it helps understanding users better so user roles are discussed users requirement is discussed and what is that they're going to accomplish through this user interface that is also discussed so user role is understood user requirement is clearly understood by writing an user story this will also help in improving transparency because since the collaboration is happening since the user story is not just taken just like that the discussion happens and that will have an interaction and collaboration so definitely improves transparency so now it reduces risks so when I say risk it's obviously uncertainty so it reduces risk because the clarity one would have about the requirement of users so accordingly the features functionality of the product are defined so that they can fulfill those user requirements then supports iterative developments as I mentioned earlier the collaboration the transparency everyone working together and in the agile perspective users stories epics and initiatives gets into the specific iterations only after this discussion with the team members and after prioritizing it so the user story will be there in the product backlogs which will be prioritized based on that particular scenario of requirement in agile scenario so as when we say agile it's quite obvious we need to be flexible to the changing scenarios so since we're working together and when we go for an iterative mode of approach is quite obvious we're going for it to get adopting to the changing scenario so that we can select that particular features functionality by pulling that particular epic or user story as a priority in the given list so that prioritization making will also become easier focuses on oal Communications means lot of interactions happens while discussing on user stories so since people are doing it o so there is some Personal Touch also established good collaboration can get established so us story also provides that visibility because of that people working together in a collaborative manner invest in user stories so what is invest so investing in user stories so what does that mean so it is a concept that helps creating meaningful user stories so it stands for independent negotiable valuable esteemable sized appropriately testable so when I say independent so whenever we write the user story that should be selfcontained if at all possible to avoid dependencies on other user stories so it should be independent of one another so that each of them can be developed and delivered separately so negotiable so when we say negotiable user stories can always be changed or r- return so at any given point in time so we should be able to do the modifications required so that should support the flexibility associated with the agile methodologies so since requirements often evolve changes and this changes comes for various different reasons so how do we change this user stories or modify this so that it can fit into the requirement so that adaption can happen to the changing requirements so story should be discussible and should be open for negotiation for any change scenarios so next valuable when I say valuable it's quite obvious we're speaking about value what is being created for the users or consumers so a user story would rep the goal or an objective an end user who is going to look for means value is always in the consumer's perspective so now I created certain features functionality is fine but did that really create the value to the consumers so the value realization plays an important role So Stories must ensure there's a value being added to the consumers and customers or users always otherwise user story doesn't make any sense so estimable so when we say estimable one should always be able to to estimate the size of the user story so sometimes developers may not have the experience required to size the particular situations or needed for an user story reasons may be anything it may be not having specific Insight towards it or don't know how to estimate there may be someone specific who needs to understand the scenarios and then come and discuss reasons may be anything so stories if they cannot estimate then it will become difficult in terms of handling it better so it should give some visualization so it should be estimable and can be divided into tasks so now small means sized appropriately so user story should not be very big or should not be too small and then uh how do we decide on this size so now when we say any user story that can be completed by a developer in single iterations then can we call it as two big quite obviously that is an indicative so user story should be subdivided into two or more small stories into multiple pieces multiple stories small small stories so that it can be handled better so story should not be too big and should be completed within 40 hours or 3 to 4 days this numbers are indicative so not necessarily you should be fixing with these numbers so just an indicative to show you that what would be the focus when I say us the story in what is that effort it would take to accomplish that now testable so when we say user story is testable one has to ensure that development is complete and has been done correctly so means one once you create a user story so that needs to be articulated in such a way so that it becomes measurable when it's a testable obviously there should be metrics a Target metric which can be created which will help me to State yes this particular requirement is accomplished so they should have an acceptance criteria that can be tested to check if they fulfill the customers need so then how to write user story this is very important an point to look at so how to write the user story so writing user stories comes up with a specific template with a simple language so what is it so now as a role I want to so that so you keep filling it so typically role means what the specific user role who would be using that particular product and their requirements which are being fulfilled so that is the role the name of the role we are going to put it here so the role refers to an individual that would be interfacing or interacting with the system now uh want to when we say want to the want or action which represents the behavior of the systems so what is that it's supposed to do this action would be unique to each user stories now so that this refers to the benefits or results that nonfunctional and external to the system as a result what would happen what is that we are trying to accomplish out of it so let us look at an example how does it look like as a CEO I want to track my subordinates progress to ensure organizations goals are met similarly if we take the reference to those examples what we discussed earlier like we took the example of HR portal so claim processing requirement now this can be same user story as an employee of an organization what can I write so as an employee of this organization I want to submit my claims online so that claim processing will become smoother easier faster without any errors so that can also be an user story so it gives certain visualization what kind of users are there and what is that they need so the moment you write the user stories you should visualize that rule it is very important so there is three CES of user stories which we uh call it as card then uh conversation and then confirmation so when we say card card provides a written description of the user story so what do I mean by written description of the user story so same thing the user story what we just saw as an example so that can be written on a card so this will help in planning and estimating so what that will also gives that visualization of users and their requirement so that that can be articulated further and also estimated so that it can uh looked in the perspective of invest what is invest What would discussed so it is independent it is negotiable it is valuable it is estimable it is sized appropriately means it's not should not be too big too small the examples what we saw was appropriate and testable so now when we see this particular user story is it fulfilling all those points what we discussed in invest that is very important now this card whatever the description is provided should elaborate on that very clearly so then further what happens conversation after the user story is written in a card and given and it is shared with every individuals who is participating in that conversation so then there will be discussion so conversation represents discussion between users team product owners so this helps in terms of whatever the user story is written is it making sense is it in line with the user's expectation and at the same time what whatever the understanding we have maybe as a product owner or the team member a developer is my understanding correct then user perspective so whatever the user story is written is that user story is speaking about the requirement which needs to be fulfilled as they require so this helps to build a shared understanding between all those individuals so that there is no confusion further so once people Converse together once the stakeholders Converse together then you will confirm confirmation so this represents the condition that need to be satisfied to ensure that the Story meets all requirements so you are confirming so all the stakeholders are agreeing to that so firstly to summarize this 3 C's refers to card conversation confirmation card provides the user stories which actually represents as we took an examples which will capture that so that it also fulfills the thought of invest then then uh conversation is required to understand what is this user story is speaking about is that a real requirement so confirmation further in terms of confirmation from users as well as all the stakeholders before you go and develop or execute that so what is life cycle of user story so when we say life cycle so we may require to understand a life cycle starts when you conceptualize when you visualize when you say this is what we may require to accomplish they should be conceiving someone should conceive that idea here so it may be related to a problem it may be related to a specific product for an opportunity what is seen so whatsoever the reason it is there is a scenario where something is conceived trigger may be a problem trigger may be some issues what is being faced trigger may be an opportunity what is seen so then the initiative the trigger which actually pushed towards creation of the requirements and user stories so the life cycle of user stories starts from there so how does it go so it involves right from the point pending to to-do then discussion then developing confirming and then finished so when I say pending I'm basically saying user stories in their most basic forms where they are created after communicating with the user and the project team these acts as the reminder for further discussion so first level of understanding on user stories in the basic form so which will help in terms of further discussion and taking a call on that so will there be a possibility that this user stories will be modified as we progress answer is yes and no both so it may be modified but discussion is further which goes on uh from this basic understanding of that particular user story so further discussion is to elaborate on that make sense out of it and confirm so then after discussion with the stakeholders users stories that need to be addressed are decided and put into Sprints so in between the point where we said pending to too so in between this there is a lot of discussion so where decision is happening here so decided and put into Sprints means there is a prioritization also which is happening so now discussion at this stage user confirms users confirms the requirement and acceptance criterias so acceptance criterias helps in terms of once you test that particular user story after executing you will check based on these acceptance criteria so that you can conclude the requirement is fulfilled the end users are shown a preview of upcoming features so that they understand yes this is what we were expecting they can provide their feedbacks necessary feedbacks or insights whatever is required to be provided so then once the discussion is complete the team would be able to design and Implement features to fulfill user requirements so once user concludes yes this is what we were expecting and there is a sign off during the discussion then features are developed and implemented so that it can goes to that product which can be used so then after developing confirming so the end user confirms the user story features are confirmed to testing environments Alpha versions and acceptance criterias are looked at before saying yes it is confirmed user is accepting so that will happen as part of confirming means that features or functionality what was written in user story so that specific users are using it and concluding or acknowledging yes this is fulfilling our requirement and this is according to the acceptance criteria what we discussed and agreed so that is very important so we write a user story fine but users are not agreeing to it that is not a good scenario to be with user should accept and confirm then finished so the user story is completed at this stage for new require ments or new features a new user story must be created any new features or new functionality I'm required to add to this particular product then I would write another user story and the same life cycle starts continues and this is not an ending thing so as I keep modifying the features as I add new features and I as I look at improving the performances so I keep writing the user stories now one question keeps coming to me so we write a user story while fulfilling the requirements fine as a specific user I want this easy to narrate that so how are you going to look at a scenario where there is an improvement of something so whenever we are going to discuss about Improvement of something it is quite obvious we need to look at it what is that Improvement user is looking at now when I'm am uh submitting a particular request or accessing something it is taking some time means there is some delay now user experience can be enhanced by reducing that particular time that is Improvement as a user the user story basic user story doesn't change but in the performance perspective you may require to visualize that so problem statement has to come in accordingly user story has to be articulated then once the user story is written it is required to put the user story mapping so user story mapping represents and arranges user stories that help with understanding the systems functionalities the systems backlog planning releases and providing value to the customers so typically this involves arranging or organizing user stories based on the priority along the horizontal axis so I will horizontally when you move so you will say which one is the priority which user stories are priority first thing which I need to focus on so vertical Arrangements represents how in the given specific user Story how the activities perspective task perspective subtask perspective further down how it gets elaborated to improving the levels how it goes forward so now let us look at an user story mapping with an example of let me say net banking services provided by a bank for account holders when I say net banking service it is quite obvious it is also has to be provided through having a product uh which banking application would use so but here we need to visualize the users Journey while accessing the net banking portal viewing the Account Details paying bills like utility bills doing lot of transactions within that particular portal net banking access the moment they do like generating statements or transferring money to one of the benef beneficiaries Etc so the all this transactions what is being done so in this user story map let us see how does it look like so few activities are considered here like uh logging into the account means net banking portal will come in then one would input their credentials and then the login now that journey of the users in a specific activity what they do is visualized Now log to account in the sense obviously one has to go to that portal so go to login page then enter credentials login ID and password so once that login ID and password is entered obviously there is a process engine which runs behind to provide the necessary access now if that credentials are not uh working or if I don't remember it reset password is an option immediately now as I go through further from this subtask in all the particular columns which I have given you as you go through this as I deep dive into it further it goes on so until the person gets an access to the account and then start doing the transactions it goes up to that level so I can keep writing the subtask further so manage account so you would go to account page once you access it then you'll select the specific account because you may have many different account types which is there with the bank you may be having one or many so in the scenario you have more than one obviously you will select that account and Account Details will be displayed to you so this user will not do but user will get that so we are visualizing that and further after Account Details are displayed what user would do then further you would keep visualizing that so some of the transaction like generate rating statement transferring money so even for that the steps are written so going to statement page then selecting the account for which you need a statement then selecting the period from when to when the statement one is requiring and then uh further clicking on it and downloading that particular statement or choosing an options mentioning that I need this in an email or I need an OD copy of this so similarly transferring money so you will go to that specific page where you need to transfer the money so you may have the beneficiary there in the list already added if you have added earlier or newly you're adding a beneficiary so there are various types of transfers like so International transfer you will have local domestic transfer you will have within a bank uh accounts being within the same bank bank a two consumers so from me if I'm a consumer transferring money to another consumer of the same bank and vice versa that is one of the options second is a bank consumer having an transferring a money to some other bank account of someone else that is another scenario or transferring money for my own account in another bank so various different scenarios you come across so then limitation or depending on what kind of beneficiaries are these what is the limitations and how are you going to authenticate them so the moment I visualize a specific transaction and activities of user stories what are the things an user can do then I can keep writing mapping this to each of those flow and see how the flow happens so this flow helps me to bring in all those features and functionality and also prioritizing them so can I say the beneficiary option would be the basic thing which consumer would give I think initially if I go back when actually net banking features were provided by the bank the basic thing was just viewing the account that was the given statement download was given otherwise there was no opportunity to transfer money there was no opportunity to do something beyond that so now now as we see today the lot of flexibility has brought in with lot of new features functionalities in the net banking or mobile banking options so they evolve so as they evolve it is quite obvious we may require to keep adding those features functionality by rating the user stories this is how the enhancement happens so overall if you look at user story mapping helps in terms of understanding not just the user story of one transaction Associated transaction in the user story what happens through the journey that will help so this will also support to understand and visualize what needs to be created to ultimately give that access to the user so the end to end flow should be visualized and also needs to be prioritization and has to be looked at as well now what are the advantages of user story mapping so the advantages wise helps with prioritizing work as I explained in the example similarly the focus is on user value the moment I click click on web page www.abc bank.com now the bank page will come I will have an interface of login I'll go and click on login now from the point I open a browser and input that URL and then click on login and login page comes in how long it takes so there are many things which is involved the browser things are involved the system from which the person is accessing is involved so removing that part so thinking that both of them working well and what should be the response from the server with where this particular website is hosted that experience needs to be looked at so that's how you look at a user value in the transaction now once I put a credentials now how quickly the authentication happens what are the checks the bank portal does to ensure that the person who is logging in as is a genuine user is it just a password is there any capture codes is there any OTP sent or is there any secret code the person has to put in so likewise many things are involved while giving that experience to the user so and today's user if you just put in various different checks points they understand because they are well educated so why all those things like capture or OTP scenario scheming so these are came in because more and more informed the people has become then their ability to hack also improved so more and more levels added to ensure that only that genuine user will enter the user account similarly when you visualize any product and user journey in the user's interest what are the things which is going to create value that needs to be understood so only that experience will help for the user to realize the benefit then road blocks are highlighted so as we visualize this journey so this will tell me so what would stop me to move forward is there any concerns is there any constraints like for example if you want to activate a beneficiary but for some limited period you can only send the limited amount of money why is that done by chance if the beneficiary is added by that individual who is not a genuine user so we are actually holding it right so by the time that freezing time whatever is given so by the time the message goes to the actual consumer telling that there is a user activated like this and if at all if it is not a genuine user obviously the person can call to the bank saying that this is not the uh beneficiary which I have added there's something which is not correct so they are giving that space so how did they visualize this has to be done so as we looked at the Journey of adding a beneficiary it's quite obvious when beneficiary is added if by chance someone who is not authorized adds it so who is going to disbenefit obviously user will be dis benefited so that blocks that constraints are visualized similarly in making or creating that features functionality what should be the basic features or in the product should be ready only then I can add this feature even that will be visible right so roadblock will be highlighted and that those will be made visible so that easy for you to move forward prioritizing and ensuring that it goes in the flow required to accomplish that value so then ensuring team unity because everyone will have an visualization user stories and mapping reads a lot of discussion brings the people to have a common understanding so obviously that Unity the collaboration would come in focus on constant Improvement so Improvement is the key whatever you do you have just adopted a waterfall methodology you have just adopted an agile you write user stories you write a pics you write bring in that various different methods to do something whatever you do whether it's product or a service or a process or specific uh transactions task reports whatever we make so all that should help in terms of identifying the opportunities for improvement and making that improvements that is very important agile project management as a name suggests is a flexible approach to building a project in agile project management the project is broken down into several stages or Sprints agile does not work on the principle of delivering the final product at the end of the project it works on delivering sections of a project or mini projects the process of project management in the case of agile is agile based so there won't be any central control of project manager as it was there in the traditional way of working before we move forth let's have a look at the Agile development cycle agile methodologies consist of several small Cycles or Sprints at the end of each stage we get a mini project there's a product backlog that explains new features changes in the existing features and several other improvements in the project then we have a Sprint backlog which has a list of tasks that are to be completed during each Sprint the Sprint consists of planning designing execution testing and deployment stages and at the end of each Sprint a mini project is delivered with every Sprint new features are added to the product which plays a significant role in the overall project growth after all the Sprints and early validation in the development a final deliverable has a fewer chances of failure let's now have a look at some reasons why Industries have started moving towards agile project management the first reason is high product quality when we talk about high product quality we refer to the build of the product as per stakeholders demands testing is performed at Short intervals of time wherever needed to ensure high quality of the product then another reason is customer satisfaction whatever is done in the project is known by the customer the deliveries don't take longer durations as they used to take in the case of traditional ways the changes may be provided by the customer in the execution phase of the project third reason is reduced risk since the project is divided into Sprints so if the risk affects one Sprint it doesn't mean whole of the project will be at risk the process of risk analysis continues to take place with all the other processes another significant reason for agile project management is better and faster return on investment the project is now developed in several Sprints and each Sprint has its own version therefore the project becomes Market ready after a few Sprints only since the projects can now be released with ease and in shorter duration this helps the organization to stay ahead in competition with respect to other organizations which have still not moved to Agile methodology now we shall check the principles of agile project management there are 10 principles for successful agile project management the first principle is the satisfaction of the customer by delivering the project fast and with least number of Errors the next principle refers to decreasing the amount of time between the phase of planning and delivery the third principle states that the team of managers and developers work together and increase the productivity of their work the next principle states that the changes requested by the stakeholders can be taken into consideration and worked upon during the development phase as well the fifth principal pays attention to the factor of coordination among the team members then the sixth principle refers to the process of monitoring and tracking the progress of the project at the end of each Sprint and making amendments wherever needed moving on the next principle states that there must be a feeling of trust and support towards the team to complete the Project's objectives the next principle emphasizes on face-to-face conversations with the development team the face-to-face conversation helps in both soling problems and easy knowledge sharing then the ninth principle emphasizes on finding Solutions and maximizing the amount of work done with Simplicity this ensures timely completion of tasks by all the team members the last principle states that scrum tools like monday.com or Zoho Sprints must be used to simplify the complicated codes which further helps in Saving Time We Shall now see the steps in agile project management the goal of agile methodology is to produce shorter development life cyle cycles and more frequent product releases than traditional waterfall project management so we will now check six steps in agile project methodology the first step in the process is Project planning project planning includes feasibility study development of scope breaking the project into executable tasks or Sprints and then estimating the amount of time needed to complete those Sprints the second step is the step of roadmap creation a road map is a plan of action that shows how a project shall evolve over time a list of all the features that the final product should have is created and the steps to achieve those features are taken the next important step is release planning since we are doing the project keeping in mind the agile project methodology the project will complete in Sprints that means there will be the release of features at the end of each cycle and unlike the traditional waterfall model the development Cycles will be smaller the fourth step in agile project management is Sprint planning the Sprints are made keeping in mind what all is to be accomplished in that particular Step At the beginning of each Sprint the goal of that Sprint is decided and steps to achieve that goal are taken the next step in the process emphasizes on daily meetings there are short meetings every day to discuss if the team was able to finish the task for each Sprint and check if there are any amendments that are required each team member talks about what they achieved in the last Sprint and what are they going to work on in the next Sprint the last step is the step of Sprint review and retrospective Ive there are two meetings after each Sprint first meeting is for the Sprint review this meeting is with the stakeholders to show them the finished product this helps both sides to build a relationship and discuss if there are any issues in the end product the second meeting is for having a Sprint retrospective this meeting involves the stakeholders to discuss what went well and what went wrong during the Sprint Sprint retrospective takes place after the Sprint review and before the next Sprint planning now when we know the steps needed for agile project methodology we must understand some agile project management Frameworks there are several Frameworks available today here we will be discussing some of the most popular Frameworks the first framework we will discuss is the canbin framework canbin framework is a wellknown framework for implementing agile software development in the case of canbin framework work items are represented on the canbin board which helps all the team members to see the state of every piece of work at any time canman board not only helps in visualizing the work but also optimizing the workflow among the team the next framework we will discuss today is the scrum framework scrum framework is a popular framework for managing complex knowledge work like in the field of research and Advanced Technologies scrum is a simple framework that helps team work together and learn through their experiences gained while working on a problem the third framework we will see today is the hybrid framework the hybrid framework is a combination of agile methodology and non-agile methodology in the case of a hybrid framework planning is done using the traditional way of project management while the execution and delivery is done using the agile methodology since the hybrid is a combination of the two it handles the requirement changes and delivers the product in different stages the fourth and the last framework we will see is the lean framework the lean framework works on the principle of providing maximum customer value and creating zero wte it focuses on optimizing the flow of products all through the value stream this helps in eliminating waste all through the process and create processes that requires less human efforts this also simplifies the process of information management and makes it more accurate finally let's have a look at some companies that have opted for agile project management today around 22% of the organizations worldwide have all their teams working on the principle of agile project methodology did you know know that IDC has confirmed 30 to 35% of IT projects still fail the major reason behind the failure of software development projects is due to poor communication poor management by senior authorities employee resistance and insufficient funding to avoid these problems businesses prefer customer Centric Innovation techniques such as design thinking and agile methodology these Concepts have similar techniques such as Gathering user feedback back following an iterative approach of the model that results in a better idea with such benefits designers avoid errors and result in faster and reliable output however these two concepts are not interchangeable hi welcome to Simply learns YouTube channel today we'll be discussing the design thinking and Agile development let us see how these two techniques can be implemented together now without further Ado let's get started with the tutorial design thinking and agile today we will be looking at what is design thinking what is agile design thinking explained design thinking and agile so the first topic what is design thinking design thinking is extremely helpful in solving problems that are IL defined or unknown it is an iterative method that helps resolve user issues or redefines problems with the best Solutions next let us understand what is agile agile is a set of methods and practices that focuses on iterative development also requirements and solutions are obtained due to self-organizing cross functional teams collaborating if getting your learning started is half the battle what if you could do that for free visit scaleup by simply learn click on the link in the description to know more moving further let us understand what is design thinking in detail design thinking requires designers to step into their customer shoes and try to find a solution to their problem with empathy the process also helps resolve user issues by redefining problems and providing the best Solutions design thinking covers five stages they are empathy Define ideate prototype and testing let's talk about empathy first the initial step to follow in the design thinking process is to pay attention to the client's requirements a designer or its team should consider the user requirements in short they should step into their shoes and try to find the solution to their problem in the best way possible without the empathy stage the design process lacks all important user Centric quality which helps a designer reach the success stage rather than failing next comes the defined stage the defined stage will encourage the team to gather useful techniques in order to solve challenges with the least difficulty an individual will start to progress to the third stage that is the id8 stage by asking relevant questions to encourage the person to develop ideas and solutions next is the id8 stage this phase gives priority to creativity and ideation in this stage the designers will be performing ideation sessions and searching for new ideas in simple words the phase focuses on creative and curious activity such as brainstorming activity next is the Prototype stage in this phase we can experiment and modify the errors found in the product this phas is a mini version of the product it validates Solutions and tries to resolve obstacles this stage has two prototypes one is low Fidelity and the other one is medium fidelity finally comes testing this stage gives importance to user feedback based on the prototypes we have created basically in this stage the user's feedback on the Prototype stage is considered and improvements are made that was all about the five stages in design thinking process moving forward let us see how design thinking and agile can be implemented together while design thinking and agile are applied separately the two strategies can be implemented together as well a majority of it companies have begun to utilize agile in conjunction with design thinking whereas agile methodology is a practice of solving problems and design thinking is an approach to find user problems for teams looking to leverage agile and design thinking for the first time here are a few recommendations to focus on let us see the first topic begin at a small level it means focus on high value low risk opportunities in order to earn better Solutions using design thinking and agile together then with better results take on more challenging initiatives next is invest in your research it means ensure the entire design team understand the end user Suppose there are any existing data start by testing some ideas start the design thinking process by building a map of the user's Journey as a result it encourages team members to focus on empathize phase and discover new Solutions next focus on a clearly defined problem statement with Sprint start design thinking in Sprint zero encourage the entire team to understand the problem statement and build a useful design framework then build a production team culture form a core design and development team teams such as decision maker ux researcher designer visual designer scrum Master developers and quality analysts do not exceed the team to more than 10 members and make sure every professional has an equal say create an environment that supports collaboration across departments like a successful design solution next is optimal use of design thinking use design thinking during the first stage of project development and then apply it whenever an important feature has to be developed next comes design patterns and maintain a good user experience this stage helps in minimizing design and development time design patterns work as building blocks encouraging team members to remove lower level design decisions the patterns created should be accepted by the entire team and should be easily implemented finally comes periodic Tes testing based on the characteristics of the project set up a testing schedule the time can be scheduled once in 4 days or once during the Sprint test simple prototypes to eliminate errors and understand the viability of ideas during the early stages test the working software and evaluate the result for a better output so are you interested in becoming an agile scrum professional here we have certified scrum Master CSM certification training course so hurry up and enroll Now find the course Link in the description box so this would help the people who actually needs to know something some important details about agile and Associated details so that can help them to understand the agile and agile methodologies the tools related to Agile better so explain agile in brief if this is the question what would be the typical answer so the term agile refers to ability to move quickly and easily by becoming more flexible and adaptable so most of the times I've have seen people say whenever I ask the question what is aile they say agile is a methodology the term agile itself is not a methodology it actually refers to this flexibility adaptability so all those methodologies which are there defined for agile for example scrum so they have an approach towards to become agile and do the projects in agile way so this requires adoption and adoption of continual changing scenarios in modern dynamic business environment which means the flexibility and adaptability is required because of the changing business environment the Dynamics to quickly adopt to the change to become flexible agile approaches are required it is very essential for organization to become agile for their sustenance and growth there are various agile methods and practices that focuses on iterative development typically any agile methodologies follows iterative approaches requirements and solutions are obtained through self-organizing cross functional teams collaborating so collaboration is very important any of the agel methodologies we come across we speak about cross functional self-organizing teams so this is the basic details one should know when they hear the term aile so question number two explain the difference between a traditional waterfall model and agile testing so when we say agile and waterfall it has two different Dynamics all together so agile model is a continuous iteration life cycle model for developing and testing software whereas waterfall is linear sequential life cycle model for developing and testing the software so similarly the rigidity so agile methodologies is flexible way of building a software which provides lot of flexibility Whenever there is a change adopting to the change will become very easy adapting and adopting for the change scenario whereas in waterfall methodology it is bit difficult it is rigid because it's very much structured any changes which comes in adopting that and changing things to according to the change Dynamics requires changing many things which makes it very tedious and rigid so thirdly collaboration so agile model is highly collaborative that's what it approach considers mainly toward software development where involvement all the members involvement of all the members like customers uh uh maybe the team m MERS the project managers so their active involvement is very much required so that things can be handled better so whereas waterfall model generally don't insist on that so it is least flexible and follow sequence of steps which are predefined and that doesn't allow the team to collaborate even the collaboration happens it will have a limitation because everything is defined and one has to follow it and comply to it there is no opportunity or options to change anything so easily when it comes to Waterfall model then processes the entire process of development is divided into iterations which are of short period so that in each of these iterations the working model working piece of that product will come out so in waterfall approach the software development process is broken down into several phases sequential phases linear phases so things which has to be delivered in each of the faes are very well defined and accordingly it happens so changes changes may be made even after the initial planning is completed in agile approaches or in agile whenever whoever follow agile it is easy to adopt to that change scenario whereas in waterfall approaches development requirements cannot be changed once the project development begins it will become difficult because everything is defined in a comprehensive way detailed so that small changes may impact other parts of the the products or descriptions which is defined so software develop ment is a collection of many different projects which can happen in agile whereas waterfall software development is completed as a single project or deliverable so testing testing is performed in same iterations as programming or building so within that iteration since we build the working product all the testing will be done within that so that one would be fully informed about that product which is being developed in the iterations so that users can give the feedback quickly whereas testing phase is separate in uh waterfall approaches but however testing can be built in parallel in waterfall also if it is planned that way but still it does not give that flexibility as it is there in the agile because the product will not be available to the users to give their feedback so that necessary Corrections cannot be made so whatever testing reveals in waterfall methodologies the corrections will be done by the team limiting to their understanding whereas in agile since users are very closely involved working model is ready so the feedback is straight from the users in their perspective so that Corrections can be made and ultimate product will be very much useful to the people who are going to use that product ultimately so question number three what are some important parts of agile process so here are some of the important principles that need to be followed to make a process of agile so one is customer satisfaction so very much important one has to ensure customer is satisfied customer sees the product gives the feedback the uses it gives the feedback necessary Corrections are made in time so that quick delivery of the product can be made according to the requirement of the customers which would result in high customer satisfaction then changing needs so agile welcome changes so any changing needs will be addressed even late in the development processes in the entire life cycle of the project wherever the change comes in taking that changes making that necessary changes will be easy easier when it comes to Agile delivery frequently so ensuring software is delivered frequently focusing on shorter time scales which is very well uh understood the full clarity of the product and the working piece of the product will come out of the iterations so as I mentioned earlier as well quick feedback from the users will also obtain so that products which are delivered will be as per the customer requirement so agile approaches helps that way work together so agile Manifesto emphasizes on working together collaborations so that each one of them contributes so developers and business individuals has to work together through the course of the project so that necessary outcome can be created so motivated team so projects need to be built around motivated individuals and they must be trusted to get the job done so as I mentioned in the previous Point collaboration is very important so we cannot ignore team as well who is actually actively involved in creation of those products so they should be motivated and their active involvement is very much required face-to-face conversation is most efficient means of communication so since theel methodologies whatever is defined actually emphasizes on having the face Toof face conversation collaborating better uh contributing proactively and involvement proactivity is very essential so conversation communication plays a very important role so working software working software is a primary measure of progress which will be delivered in each of the iterations so that users can give the necessary feedbacks so constant Pace agile process promotes sustainable development because all the products which are being developed used feedback obtained are in real time so people actually know what is being produced and what is that they can expect as it progresses so Clarity is also one of the things and that pace has to be maintained and agile approaches helps to accomplish it so good design agility can be improved by focusing on technical excellence and good design as you progress as the changes comes in as you adapt and adopt so since it has the flexibility technically as well as process wise as well as any of the configuration wise it is easy to do the necessary changes and have the design which is required to accomplish the ultimate results Simplicity the amount of work that's not being done needs to be minimized so we say Simplicity is the ultimate sophistication means what is that required to be done consider only that not anything else above or below that so whatever we may require to do focusing on that the minimum thing what need to be done will be done and has to be done when one follows AEL approach self-organized the team is self-organized so self organized teams provides best architectures requirements and design because they having various different capabilities come together contribute together with their capability with a different capability multi skilled as well will be present in the self-organized team reflect and adjust Effectiveness can be improved by the team regularly reflecting on it because as I mentioned earlier in every iterations there are feedback obtained testing is being done in each of the iterations as it progresses so this will help us in uh terms of providing the Insight towards how is it progressing so that that will help in quickly doing the necessary Corrections which are required to be done so next uh question number four explain iterative and incremental development in a j so incremental development when we say the process is divided into many small workable increments so which can be done one after the other each successive increment Builds on the top of the work done in the previous increments over time functionalities are added based on what was already created so iterative development involves the development of system by following repeated Cycles or iterations based on the results from the most recent iterations of the process changes are made this helps the project evolve over time so the term evolve is the one which one should keep in mind it is not that I'm just going that is my destination yes definitely that is a destination while progressing there are lot of variations which happens those variations has to be considered and accordingly the necessary deviations or Corrections adjustments has to made and things to be progressed further which is very important because of this iterative approach it helps to become adaptable and flexible to adjust to these varying conditions so that's where project should evolve it cannot go in a straight line it has to evolve based on the variations while progressing towards the destination or the results what we are supposed to accomplish so agile definitely iterative plus incremental so agile involves consideration and creation of working product in an iterations which is part of the overall final products the consolidation of all the products which are produced in each of the iterations will become part of the ultimate results ultimate product each iteration is an enhanced working increment of the final product this process continues until all the products functionalities are satisfied so organizations and user can use and experience the product and provide feedback that can be incorporated into next iterations so each iterations when the working product is produced those things are used by the users experience uh they will look at the features and functionality and based on the requirement what they're supposed to fulfill they may also give the feedback for necessary Corrections or they add new requirement to it because the minimum requirements what is being fulfilled by this product maybe some requirements which are not expressed earlier there is an opportunity to express at this point in time to State we can involve some of the features of these kind in the next iteration so that we can able to make this product better so such kind such a conversation the incremental iterative approach helps or allows or provides that opportunity to express so causing product road maps to be built produced tested and confirmed before the next iterations so that's where before move to next iterations there will be better Clarity in terms of what is produced what we are supposed to produce further and what is that modification we supposed to do so that product can ultimately fulfill the requirements so question number five what are the different types of agile methodologies so there are various kinds of agile methodologies some of them are briefed here so let us go through them one by one extreme programming so it is a framework that any enables team to create high quality software and improves their quality of life it enables software development with appropriate engineering practices so next is Canan this method is used to design manage and improve the flow of systems organizations can visualize their flow of work limiting their work in progress so basically kban comes from the Toyota system so here when we use the term workflow the work in progress so this will help in terms of monitoring what is happening what work is in progress what work is completed and it uses a visualiz system so one can see it what is happening so it also enables the individuals who are doing it to know what is that pending against them and they can pick it up pull it up and then complete it lean lean is a set of tools and principles that aims to identify and remove waste to increase the speed of process development it focuses on maximizing value of to the client ensuring waste is minimized so lean uh principles Le approaches says the flow in a flow if there is any bottleneck that needs to be removed so this bottleneck would limit the flow and that would add towards the waste so identification of the waste the the reason for the creation of the waste or who is the contributor of the waste and eliminate in those causes and moving forward this will help in smoothening the flow at the same time improving the system for better outcome so that's where Len is become popular and well acknowledged so scrum is a framework that is used by teams to establish a hypothesis try out reflect on experience and adjustments it is used to enable teams to incorporate practices from other Frameworks depending on the team's requirement so that's about scrum scrum is bit popular and it is mostly used for smaller projects the bigger the project more complex I think scrum would not help but scrum is very popular uh in software development organizations so where uh it has a simple uh U five events three roles and uh three artifacts so it helps uh to adopt and uh adapt to the changing conditions and it has become a proven practice okay crystal crystal is an approach to software development that focuses on people and their interactions rather than tools and processes it is aimed to streamline processes and improve optimization it works on principle that projects are unique and dynamic so next question what are the principles of agile testing so testing continuously to ensure the product improves continuously so as we know when we progress when we adopt when we follow agile approaches there is a reason because we need to Able we should be able to respond to that changes quickly we should be able to understand what is going right what is not quickly and do the necessary correction then and there itself so testing continuously become very important because as we develop as we test we can reveal any of the issues any of the defects in the product what we develop so that it reveals so obtain feedback continuously to ensure the product meets business requirements so looking at the performance does this features functionality of the product is helpful to accomplish that business requirement so this feedback comes from the customers and users when we produce at working piece of the uh product so all team roles testing development Etc need to be involved in testing process so one cannot work in isolation there should be very uh good collaboration people from various different teams working together complimenting to each other very essential to become a jack so the active involvement of business teams and representatives can provide quick feedback for each iterations so clean and simplified code ensures it is defect free during iterations the documentation created must be limited into a particular iterations so when we speak about waterfall approach the documentation will be very comprehensive for the entire project but the moment we speak about agile the documentation will get limited to what is being produced in the iterations which is very important so what is being produced in iterations and that is based on the actually what is produced something I planned in for the iterations some changes happen we developed it created it there is a feedback which is coming up documentation is limited to that so Corrections which can be made to the documentation will be easier and quicker so along with development and implementation testing is done to ensure the product is defect free continuous involvement of users ensures the final product matches their requirement which is Ultimate need so question number seven what are some agile metrics that need to be focused on so some of the popular metrics which are used are measuring burndown of deliverables which is usually represented using burndown charts similarly we have burnup chart also where uh as we complete the task the highight of the bar keeps increasing in burnup charts but most popular is burn down so that what is to be delivered will be easily visible so the velocity lead time cycle time code quality code covered in unit test deployment success rate net promote score so these are the basic metrics which are really needed when we are speaking about the velocity and speed at the same time how quickly we are able to produce what is supposed to to be done and planned are we going accordingly or not so this will help in terms of uh making our job as for the need so metrics has to be selected very carefully so metric is not just a number it should have an interpretation and that interpretation should actually complement to the business needs and requirements so metric should have an clear description of what is this measurement is all about and what is that we're going to understand from that measuring that Matrix so next is what is Canan so Canan system is visual system which helps better management of work as work moves through processes so it is it visualizes and provides visibility into the process workflows and works passing through the processes So when you say is a v it is a visual system so there will be board or a display system where each of the tasks which needs to be accomplished are displayed there and the person who is who was supposed to complete it and what is the status of it so people would look at it pull the work and complete it so since people pull that work it is also called as pull system so because the new works are pulled in taken up from the list for execution and move them from in progress status to done so kban since it is a visual system it also makes people more conscious about what is spending against them what work is pulled that is also visible so there there is no reason for anyone to say that I did not do this because of XYZ reasons since it is visible it is my job since I pull that task it is my job my ownership to completed it becomes like that so that discipline comes into place so tracking the work will also become easier as the workflow is clearly visible and put on the display board modern organization can also use the digital display systems we're seeing this more adoption in uh many many organizations today because it the value of using it the contribution of of it is seen by organization and can on playing it roles in the organization and it's very essential to have this practice so the goal is identification of constraints that is potential bottleneck in the process and ensure they are addressed this ensures that the workflow becomes smoother and more efficient I think I mentioned the reasons question number nine what are some popular agile tools so some of the tools which we keep hearing uh today when whenever uh people say we do Agile is uh some of these are listed here like JB jira software Trello Zoho yic verizone one and many more I think uh before we choose a tool it is very important for anyone to understand what is that they require first and what tool can help them in terms of accomplishing it so it requires a lot of uh uh analysis uh assessment on the tools and the comparison with what is being done in the the organization and how this tool would suit that organization's requirement is very essential so tool is not first the requirements the need analysis and then what tools best suit the environment that is the step only then selecting the tool makes sense however studying the tools and comparing the tools and the features functionality will also help defining uh what needs to be there in place in the organization when they become agile or adopt and of certain practices what are the obstacles to the agile process so some of the obstacles that one could phase are not having the appropriate or sufficient tools and Technologies so it is quite obvious organization struggle not having the right tools and Technologies as I mentioned earlier it is very important to understand what is our need first and what tools suits best at the same time I also mentioned study the tools and Technologies and what do do they offer and what do we have do we really need that additional things the Gap whatever we find do we really need those in our environment is that Dynamics is there in our environment that needs to be understood the lack of active involvement from the customer so when we say agile involvement of all the stakeholders are very very important because the changing needs comes from users and customers whenever the iteration is complete working piece is delivered if customer doesn't respond or explain or provide the feedback then moving towards the next iterations will become difficult it is very essential the active involvement of the stakeholders and very important stakeholders is users and customers the team members lacking in skills and capability so one has to ensure the team members are groomed with the right capability and that should be evaluated on a continual basis so that organization can handle things in an agile way and contribute towards the projects what is being done and become agile some of the obstacles further if you can look at is the inability to design system based on unseen requirements so this unseen requirement is very Dynamic so when they will crop up we will not know but however the systems what we designed should able to provide that uh opportunity whenever such variations happens you can able to easily adopt or invol or take that particular new requirement and plug in so otherwise one cannot become so rigid there should be flexibility adapting the agile culture to the organization so culture plays an very important role so a lot of resistance would come across to adopt the new way of doing things people may not appreciate uh the agile way of doing things so it requires a lot of uh effort motivation and uh making people to understand why the organization has taken up uh the task to make it agile and building a culture where people would think in agile way and contribute to the organization question number 11 differentiate between agile and scrum so the term agile as I mentioned earlier refers to ability to move quickly and easily by becoming more flexible and adoptable whereas scrum is an agile methodology which enables organization so organization can become agile so agile Manifesto and 12 principles acts as guidelines to become agile whereas uh scrum is used in the projects where requirements are constantly changing aligning to Agile Manifesto and 12 principles they should follow what is told in Manifesto and principles so agile Manifesto mentions about the required collaboration interactions to become aile whereas scrum defines the roles the scrum Master the product owner and cross functional self-organizing teams who are involved in making the project delivering the project project in agile way so agile manifest also mentions about the required focus on working software and focus on change whereas scrum approach enables teams to react to changes quickly so means how to become flexible what is that we need to consider to become flexible is defined in Manifesto means stressed on it whereas scrum follows with that approach one can become easily flexible so delivery the Manifesto provides necessary guidelines on frequent delivery of software so where scrum with the Sprints it build builds are delivered to users regularly and upheld agile principles so collaboration agile Manifesto stresses upon individuals interactions and customer collaboration so scrum does it through various events like daily standup meeting and other scrum events like Sprint meeting Sprint retrospective whereas people sitting and discussing about writing and user story The epics or selecting the product uh from the product backlog to the Sprint backlog so various events which happens in scrum demonstrating that uh uh point which is stressed in agile Manifesto about individuals interactions and customer collaboration are demonstrated with various different events in scrum methodology so next question what are some popular agile certifications so some of the popular agel certifications are PMI ACP certification which is offered by by PMI us scrum Master certification then certified scrum Master Prince to Agile certification then scrum product owner certification so next we will move to scenario based questions so before we uh go and answer the scenario based questions let us look at the scenario what the scenario says the manager X was having the discussion with the team about the upcoming event the event was scheduled to conduct an online marketing campaign to increase the sales due to increased competition and rapidly changing customer behaviors the campaign is very crucial and organization has decided to do it more often this is done through the online platform the organization has the requirement of integration with organization's website with all the features and functionalities the various roles involved in the marketing campaign are marketing manager Market team campaign coordinators creators of content and browers for campaign and the participants of the campaign all of these roles should have access to platform through registration so that they can have the required access and make the marketing campaign successful besides marketing manager has sto the reports needs to be generated which depicts the number of campaigns conducted responses registrations conversations Etc so this scenario speaking about uh the marketing uh challenges or problems what organization has and through that problem statement they wanted to ensure to the marketing campaign and also they want to have an online platform uh to to make this marketing campaign successful and also speaks about the various different roles involved in this so let us look at what are the typical questions which would come across in such scenarios so first question says can you write a user story from the perspective of marketing manager and participant so firstly we need to understand what is this user story is All About so in the perspective of marketing manager is something anyway we will look at it what it is but user story is the one which depicts the requirements assuming the role as a specific role I need to do this I want to have this it it gives that an explanation so that one can easily understand about that requirement what need of consumer consumers or what need of business this particular features functionality is going to fulfill so let us see what is that user story uh relating to marketing manager and uh participants so yes why not here are few examples marketing manager us a story says as a marketing manager I need to assign the activities task to the team members so now whenever we develop that platform there should be access to marketing manager and marketing manager can able to assign the activities to the team members so what feature that particular platform should have has to be defined and designed accordingly and this is the requirement participant perspective as a participant I need to register for the campaign so now there should be registration page obviously and then whatever the process needs to be follow to create that registration for the participant that needs to be made and this simple user story helps into visualize what features functionality has to be there when we go on and create that product and services so this will help understanding the requirement thoroughly and creating the designing the features accordingly and visualizing the flow as well so next question is agile the best approach to make a marketing campaign and why so now question arises should when we do marketing campaign why should I follow aile why not I do just like that why do we need agile what is that essential need because already I mentioned the need of agility requires I mean whenever there is an adaptability whenever there's dynamics of changes whenever I want to become uh someone who can able to become competitive because competition is also responding to the Dynamics of the market quickly I should be there in the business so obviously uh does uh this question make sense can this marketing campaign can be done in the agile way so obviously yes because the agile approach is the best way to go with for marketing campaign reason being the rapidly changing behaviors of the consumers which has to be understood and detail should be put in their perspective and accordingly the features has to be provided so always in the consumer perspective customer perspective secondly with increased competition the organization has to consider the unique differentiator to sustain and grow there should be uniqueness that needs to be understood and that requires exercising continuously and uh creating the products accordingly so this marketing campaign would help to understand that so next question what are the typical product backlog items so for this what could be the typical backlog items means the list of user stories list of epics which can help in terms of defining the features and functionality the typical backlog items may include the features like registration page login page campaign contains platform to conduct campaign assess requirements so so likewise we can keep writing so user stories helps us to list what is that we may require to develop in this product so this requires a lot of collaboration and discussion only then I think uh that will become more visible next question is what are the some considerations made while selecting the items for product backlog while selecting the backlog item to each iterations from the product backlog the backlog item has to be prioritized definition of done for those items to be selected value delivered Improvement considerations Etc has to be made so prioritization is very very important what features functionality I should develop first and how it makes sense to my business how users will be helped how customer will get benefited so these will help in terms of having those features functionality developed in such an order where for that moment that features and functionality are available we're not just jumping into everything and doing it one by one in a order in a prioritize list so it is very essential to prioritize defining uh the definition of done and selecting the items accordingly and then what value it delivers understanding that and improving next question is the involvement of marketing manager required during the project and why it's quite obvious marketing manager involvement is very essential because it is a marketing campaign yes the involvement of marketing manager is very important and crucial and it is a role who will have the full visibility into the requirements to be fulfilled and on ground realities besides one cannot become agile without the active involvement and collaboration of customer users with agile teams before we end this video Listen to What a happy learner say about our courses finishing the course led to personal recognition and opened the door for even more artificial intelligent projects and it came with a significant pay my hi I'm Philip I'm 61 years old and last year I up skill with simp postgraduate program in cyber security I'm happy to tell you that I was able to clear and pass my cissp and ccsp certification exams on the first attempt after taking the course we decided to take a course in devops from Simply learn the course proved to be very beneficial for both our careers yeah I got a promotion after the course and I got to hire with a new company at first I tried to learn from YouTube and then apply for new job but I wouldn't C then one of my friends suggested I go for a certification post with s My overall experience with simply Lear was very good within a few days I got three calls two are project management positions and one was in data science f i successfully change my career from software development to digital marketing and simply learn presented the perfect route I chose simply learn because of its tremendously High weighting to be readed as one of the best Education portal online worldwide is trly promising I switched to a new role as a digital marketing manager with this my skill upgraded my salary increased and my self-confident Boost of alongside numerous other positive outcomes here we came to the end of this course I hope you got a good knowledge of agile methodologies if you like this video subscribe to Simply learn and hit the Bell icon to never miss any updates from us thanks for watching staying ahead in your career requires continuous learning and upskilling whether you're a student aiming to learn today's top skills or a working professional looking to advance your career we've got you covered explore our impressive catalog of certification programs in cuttingedge domains including data science cloud computing cyber security AI machine learning or digital marketing designed in collaboration with leading universities and top corporations and delivered by industry experts choose any of our programs and set yourself on the path to Career Success click the link in the description to know more hi there if you like this video subscribe to the simply learn YouTube channel and click here to watch similar videos to nerd up and get certified click here

Channel: Simplilearn

Views: 40,304

Keywords: agile crash course 2023, learn agile in 3 hours, agile training 2023, agile for beginners, agile training for beginners, agile scrum, agile scrum training, agile scrum master, project management, agile scrum crash course, agile scrum concepts, scrum master training, scrum master roles and responsibilities, complete agile scrum, scrum master for beginners, scrum master certification, complete agile scrum master certification training, simplilearn

Id: _-00CNH3q2U

Length: 196min 58sec (11818 seconds)

Published: Wed Sep 20 2023