🔥 Agile Bootcamp 2023 | Complete Agile Scrum Bootcamp in 3 Hours | Simplilearn

in today's Dynamic and competitive business environment learning agile is essential as it is empowers individual and organizations with the skills and mindset needed to Excel and try the importance of agile lies in its ability to deliver high quality product improve project outcomes and drive customer satisfaction in today's Dynamic and fast-paced business environment embracing agile methodologies will remain critical for organizations to thrive in an ever-changing business landscape as agile continues gaining popularity organization across Industries seek professionals with agile skills and experience to drive successful project delivery and organization transformation some roles that are in demand in agile include agile quotes scrum Master agile project manager agile developer agile tester agile product manager and many more top companies hiring agile coach CS Accenture Wipro IBM Infosys and many more according to Glassdoor and agile quotes average salary in the United States is around 134 000 per year however it is 25 lakhs per year in India so are you also looking to become a certified scrum master and unlock rewarding career opportunities then take your career to new heights weather in Old certified scrum Master certification gain the necessary Knowledge and Skills for the scrum Master role through simply learns comprehensive training course led by expert instructors the course covers all essential aspects of the scrum framework equipping you for agile project management success the CSM certification is ideal for scrum team members team managers transitions teams and those aspiring to be certified scrum master so hurry up and find your course Link in the description box for more details our Learners have experienced huge success in their career listen to their experience find the simply lens Course Review Link in the description box on that note welcome to the agile boot camp by simply love in this boot camp we will start by understanding what agile is followed by agile methodologies and skilled agile framework next we'll move on to topics like agile versus waterfall model agile versus scrum and agile versus kanban then we will look at the agile scrum master and agile user Stories We Will conclude this agile bootcamp by discussing agile's essential interview question and answers to help every individual crack an interview Alex has just completed his graduation from Stanford University one fine day he receives a mail from Star Trek Technologies for an interview for the designation of a software engineer as referred by the University Alex was really happy and excited about this and starts preparing for his interview next week while he was preparing Alex came across the term downtime Alex has no idea what is a downtime he decided to seek help from his uncle John a software engineer John explained that downtime is a specific time frame allocated to deploy or update changes for a software product in a real-time environment and this happens because most of the softwares we use today are developed using the waterfall model for example Cisco one of the popular leaders in it and networking globally is using agile methodology for their subscription billing platform SBP as it was originally developed using the waterfall model after adopting the agile methodology Cisco's product improved its overall efficiency where defects were reduced by 40 percent compared to the previous releases and effect removal efficiency increased by 14. upon explaining what downtime is John further added that downtime is a small part of the waterfall model it is the traditional way of developing softwares using a software development lifecycle where the whole product is treated as one single unit and the development of one phase starts only after the completion of the previous phase adding new features or updating the existing feature in a waterfall model based product needs a specific time frame known as downtime to avoid disturbance in the workflow of an organization where applying changes in a waterfall-based product might produce irrelevant results or product failure the waterfall model is the earliest or the traditional model used for software development where the output of one phase acts as the input for the preceding phase consisting of a series of steps where each phase has specific deliverables that act as the input for the next phase as it avoids overlapping a basis as these phases are dependent on each other this method is simple and easy to understand where prerequisites are pre-known documented earlier and Technology remains static where there is no need for ambiguous requirements due to the delay in software delivery in contrast the final version is available only after completing the entire software lifecycle process with any deviations if available changes in the waterfall model contain high risk as changes include a new revised version of the entire software running the entire series of steps again and again for example a tap and pay machine where the machine first validates whether the customer's account is funded with sufficient funds or not and then initiates the transaction for money transfer unless the validation is processed the transaction cannot be initiated Alex was curious and asked Uncle John is there any way to overcome the drawbacks of the waterfall model John replies yes agile methodology was introduced to overcome the problems faced in the waterfall model where agile based products are developed by breaking the entire product process into microservices or phases which is faster to execute and deploy changes on the go there is no need to worry about other or previous tasks while working on one particular phase avoiding product failure agilebi's products don't require any particular time frame downtime to deploy changes unlike the waterfall model where the whole product is treated as one single unit and each process is dependent on the preceding processes where deploying changes leads to downtime how agile products are developed agile based products are developed using the agile life cycle at first the developed product is implemented in an actual working environment for reviews from clients and stakeholders to check its deliverables and functionality after client reviews the official product is launched in a real-time working environment where agile methodology focuses on satisfying the consumer needs by efficiently utilizing the resources and avoiding additional risks or deviations in the product for example providing a trial beta version of the software for the end user to experience the software towards its deliverables and results will be helpful in refining and reviewing the product like Adobe Photoshop Adobe Illustrator Etc after understanding all about agile methodology Alex asks Uncle John companies implementing agile in their workspace nowadays John replies yes companies are moving towards agile methodology due to its flexibility and advantages over traditional systems by adopting agile for their Sony interactive environment Sony noticed a major difference where there was a reduced planning Time by 28 with their framework and downtime was reduced to the maximum which made the company save 30 million dollars a year agile methodology aims to meet the consumer's requirements to the maximum in deploying changes in a rapidly developing environment where agile man besto principles brings an Innovative set of rules and protocols to help developers overcome the challenges faced in the traditional practices waterfall model making agile flexible and efficient let us look at the 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 it takes cost money in terms of which is going out the effort then 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 need 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's scenario answer would be S if it is 90's 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 like if your 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 computation 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 a 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 the predictability I'm speaking about as I create this product as a result comes up if it takes six months one year two years three 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 two years is it okay so if everything is okay that way without very less without any variations as such very less variations then it's fine so because of following waterfall model uh 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 agile 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 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 the change you may required to do the 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 is 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 is 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 end user client customer perspective value so today I think more and more we're speaking about creating a value in the consumer prospective 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 computation 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 weight 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 us to address these disadvantages mentioned in waterfall 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 and 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 address 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 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 process and 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 may be 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 their process and tools should be there the way it should be defined it should also ensure there is individuals and interactions encouraged to have their individuals and interactions while having the process and tools so next is working products or comprehensive documentation so when we say comprehensive documentation 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 am 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 roadmap and upon that I am going to making the detailed documentation for that only for that working piece rather than the full product itself then these working piece documentation which I am going to create as I create the working pieces I am also getting the feedback because I'm doing the interactions with the users the consumers the inducer so 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 working models 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 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 fall 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 commercial 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 that we need to go like this only So based on the scenarios changes so we may require to change directions and move faster so responding to change requires a specific flexibility which is required in the plan so that you 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 this now keeping this agile manifest 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 is 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 couples of my customer how Associated am I how close am I well how am I collaborating with a customer that will help you to understand how satisfied your customers 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 reason 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 3 deliver frequently so ensure 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 pay should happen more frequently more repeatedly so 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 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 which is very important so feedback has to be given by consumers regularly similarly the 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 build 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 it is quite obvious team will also come up with certain set of innovation in their mind giving their feedback as well involving themselves 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 preferences so one cannot just shy away being a manager one cannot shy away from it he she should involve it with the team resolve those put things in the right direction so write lead interpersonal skills are very important here next face-to-face interactions so it 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 prospective view as well and 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 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 Insight towards what is that product being delivered inside towards what is the technology being used inside towards the processes the capabilities 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 happen quicker as well and since these are going and fitting into the architecture which is basically open architecture kind of scenarios what you're speaking about so all those modules what to create you keep plugging into it so that you are designing the small piece which is quicker so instead of Designing the entire system as a whole in detail you're just creating the small mouth 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 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 non-value adding activities and processes would be removed it has to be remote 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 clarity self-organization so when we say self-organized teams who is not capable of everything but when you look at a team has a whole each one has different different skills many skills not one or two skills many skills which they are complementing to each other so they come together The discus 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 you say team so here since team is actually taking up that ownership and organizing themselves 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 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 then they accomplish all of this so further let us look at some of the advantages what would be there when following agile so we looked at the disadvantages what we have when we follow waterfall so did we overcome those the disadvantage is 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 handling large amounts of interactions between client and project team because it is throwing lights on it's the importance of interactions the importance 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 are given the feedback there is nothing something hidden like when I go with 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 a 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 a creation of small small working piece of a product working model 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 re-prioritize the product backlog so when I say product backlog we need to understand the various different user stories what is written to deliver so that is a list of deliverables product backlog what are there since we already know what other 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 effects written what is that order priorities order of priority what we are 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 that 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 a child now keeping that agile manifest on 12 principles of Manifesto so what are the types of typical agile methodologies would come across so there are few which we are 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 methodologies 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 kanban so kanban 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 have participated in the meeting there are certain action items given to them for example now these action items I will have a Target day to complete and accordingly those needs to be closed now when the next meeting happens when you look at the 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 kanban works here is it is a visual system compared to that minutes of meeting which is not visible to us always the kanban 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 pushes it it 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 kanban's title addresses it and then it's also called as pull 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 the 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 our processes process interfaces and the flow so the interface certain way so unless the output of One processor procedures getting into an 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 one feet 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 feet pipe the entire capacity in the downstream even though it has one feet diameter pipe it leads to the waist underutilized capacity because this has become bottleneck no 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 a rework so all this likewise many things which actually end up in giving the waste so one has to visualize understand realized what are those non-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 is to know that so the iterative 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 enable 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 terminology is 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 below 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 two to four 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 the flexibility and able to move faster then Crystal so Crystal is an approach to the 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 Dynamics 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 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 is the unlimited resource to equip you with the knowledge and tools you need for Success you can find the course Link in the description box below to learn more about this course we often think of high levels of collaboration and flexibility as well as iterative environment in which requirements evolve alongside the changing needs so as a result we also tend to conceptualize agile as an approach that helps development teams across various Industries delivered new features faster but how do we get there what does history of agile and tile and how can knowing the history of agile help us better understand the methodology and its positive impact on today's development World let us look at it so now historically if you see the waterfall approach was fine it was delivering the required value but it required teams to stick to the requirements and scope of work set out at the very beginning of the project and not make any changes or additions along the way as the project progresses and following that fixed plan could prove trouble sometimes comparing to the scenarios which we had earlier which is today the trouble is more challenges more so reason being waterfall methodology prioritized bringing a complete product to Market meaning it could take years before teams finish the project in hat the scenarios of change delay in responding to problem resolution meeting changing Market requirements were challenging which led to introduction of agile methodologies so the various development methods like scrum rapid application development extreme programming dsdm feature driven development and pragmatic program were introduced so it all started early I think in 2001 it was introduced however it all started in the spring of 2000 when a group of 17 software developers in Oregon to discuss how they could speed up development in order to bring new software to Market faster so they recognized two key opportunities that achieving this goal would make possible so reducing the time to the benefits for those users in order to resolve the product Market free time development problems secondly getting feedback from users quickly to confirm the usefulness of new software and continue to improve on it accordingly so further this group of 17 developers met again at Esky Resort in Snowbird Utah us so they created popularly known as agile Manifesto so which laid out four key values so it says individuals and interactions or processes and tools working software or comprehensive documentation customer collaboration or contract negotiation responding to change over following the plan are valued more now further between the time when it was introduced till today agile has become popular and Adoption of that has increased reason being the flexibility the agile brought into the system so several organizations across the world started using it but what happened further so agile gave the result but there was a challenge so there were some issues that agile face to handle widespread usage that is mainly Whenever there is a scalability requirements so what is that scalability challenges it is quite obvious how can an implementation of agile for large and more complex project and how hard the process to scale agile so this was not clear the very reason the challenge which come across which the practitioners actually faced was one is lack of experience with agile methodologies little understanding of Frameworks methods and how to implement them next large scale coordination so when I say specific project a small project it was easy implementation of agile and then going forward all this Frameworks what I mentioned earlier it was easy but the moment you want to do scaling to the bigger organization the complex environment the coordination collaboration dependency management between usually uh distributed teams geographically distributed teams was challenging and thirdly having a clear understanding of what needs to be completed in the Sprints and what the bigger picture is so fourth aligning the entire organization and managing committees so definitely organization required alignment the products or Services which are being produced by the project needs an alignment so the need of alignment was basically to ensure the organization gets the value out of whatever they have invested so fifth unrealistic expectation with respect to speed of delivery so unable to respond to this particular scenario so that organization can able to respond quickly so it was not happening so time to benefits I I was mentioning about so generally earlier we used to speak about time to Market but today it has been replaced by time to benefits how quickly the value of that particular product or Services introduced to the market is realized by the users that is very important so the framework of scaling agile there are various different Frameworks so some of the most effective ways to scale agile would be large scale scrum which is called SLS scale the agile framework discipline agile scrum at scale Nexus Chrome the Spotify model so when I say less the large scale scrum it is a way of scaling agile and scaling scrum to large and big product development groups it has been used since 2005 in different software and Hardware products in Industries such as banking gun Telecom so when it comes to scale digital framework so it is a set of organizations and workflow patterns intended to guide Enterprise in scaling lean and agile practices so it is made freely available by scaled agile link which retains the copyrights and registered trademarks so the disciplined agile delivery which is also called as dad is a software development portion of the discipline agile toolkit so Dad enables teams to make simplified process decisions around incremental and iterative solution delivery so that builds on many practices by Advocates of agile software development including scrum a child modeling lean software development and others so scrum at scale so scrum originally if you look at outline in the scrum guide is a framework for developing delivering and sustaining complex products by a single theme so since its inceptions its usage was extended to the creation of products processes services and systems that require the efforts of multiple teams whereas scrum at scale was created to efficiently coordinate this new ecosystem of teams it achieves this goal through setting up a minimum viable bureaucracy via scale free architecture now coming to next one the Nexus scrum so this consists of multiple cross functional scrum team working together to deliver a potentially releasable integrated increment at least by the end of each print based on dependencies the teams May self-organize and select the most appropriate members to do specific work so lastly the Spotify model which is basically people driven autonomous framework for scaling agile while emphasizing the importance of culture and network this methodology uses quads tribes chapters guilds the foundation of which is called which acts like scrumting so further let us look at the our Focus area of this particular video it is basically what is scaled agile framework so scale the gel framework as I mentioned earlier consists of collection of principles best practices and processes that would enable large organization to adopt agile methodologies so it would help them deliver products and services of the highest quality faster so safe is best suited for complex projects that involves several large teams in the projects program and portfolio levels the current version of safe is version 5 which has seven core competencies based on which it can help organizations the large organization in specific so safe as certain core values which are basically alignment built-in quality transparency and program execution so when I say alignment so I was mentioning about aligning with business requirement business strategies so it is needed to keep Pace with fast changing disruptive competitive forces and geographically distributed teams while empowered agile teams are good even great but the responsibility for strategy and alignment cannot rest with the combined opinions of the teams no matter how good they are instead alignment must rely on Enterprises business objective so it also need to require to keep up with the change the competitions and then the Dynamics across in the environment where organization is doing their business so next is built-in quality so built-in quality is basically to ensure that every element and every increment of the solutions reflect quality standards throughout the development life cycle so quality is not added later building quality is prerequisite of lean and flow without it the organization will likely operate with large batches of unverified unvalidated work which leads to the product or Services which is not okay and also that would lead towards excessive rework which is not good and slower velocities which is not allow the organization to respond quickly to the Dynamics of the market so third one is transparency so transparency which basically need to enable teams to rely on each other there should be trust which needs to be built So based on which high performance can happen so wherever the trust exists so when the business and development can confidently rely on each other to act with Integrity particularly in times of responding quickly or to work out a resolution for resolving something which is actually not allowing things to move forward so without trust no one can build high performance teams and programs so the confidence needed to make reasonable commitments is very very essential so fourth is program execution so safe focuses on working systems and business outcomes which mainly for example for teams to execute and continuously deliver value safe places and intense focus on working systems and business outcomes so this is because while many Enterprises start the transformation with individual agile teams they often become frustrated as even those teams struggle to deliver more substantial amount of solution value reliability and efficiently so delivering Solutions with better value reliability and efficiency Effectiveness is very very essential and here we are speaking about ensuring the scalability to the bigger organization so program management plays a very important role so that requires lot of communication collaboration so without a better execution of that without handling it better things cannot go the way it is required so various competencies safe recommends so safe competencies involves team and Technical agility agile product delivery Enterprises solution delivery lean portfolio management organizational agility continuous learning culture and then lean agile leadership so when I say T1 technical agility so agile teams are high performing and cross-functional Business Solutions are built by business and Technical teams delighting customer with high quality output so this requires an able team which understand agile Frameworks which follows it which complies with it and also technically sound so agile product delivery which actually refers to the scenario where the customer is at the center of organization's product strategy so development is based on Cadence and releases on demand exploring Integrity deploying and innovating continuously then Enterprise solution delivery so building big system with the help of lean coordinating and aligning the entire supply chain evolving the live system continuously requires to ensure the visibility of entire Enterprises and providing solution accordingly lean portfolio management which basically focuses on aligning the strategy funding and execution optimizing operations across the portfolio decentralized decision making powered by lightweight governance then organizational agility a lean agile mindset is created across the Enterprise it is very essential for example I am working in a project I have an attrition if HR does not understand my Project Dynamics and if they are not agile me as a project organization becoming agile will not help similarly the one the procurement similarly the processes so very essential for all the organization units to become agile so that business operations are able to complement contribute that speed or the change what is required so opportunities and threats are addressed quickly so risks are identified and addressed quickly so they are worked on it so risk management can become easier with the involvement of right stakeholders continuous learning culture so in this scenario everyone learns and grows together exploration creativity are a very important part of organization where there should be an innovation creation execution maybe I think I come across certain terms like intelligent risk taking so learning through failures failure should lead towards inquiry not towards blaming so this these are all the things which are more and more discussed when we want to make an organization a learning organization The Continuous Improvement of solutions services and processes is everyone's responsibility then lean agile leadership so by modeling desired behaviors inspiring others aligning words actions and mindset to lean agile principles and values lead change and guide others so this requires lot of accountability and ensuring the correct information well informed individuals to take forward things now how does safe work so safe considering those competencies what we looked at the seven competencies so let us see what happens in each of the competences how to save work using this competencies so firstly let us look at team and Technical agility which basically involves an agile team of five to eleven members which helps defining build test and deploy products so this is done by dividing the task into small easier to manage time boxed iterations right then Chrome team led by the scrum master and supported by product owner plan and then deliver the product and increments so further after delivery they have a retrospective to determine how the iterations went and how it can be improved this is incorporated into next iterations planning phase so the method used here would be scrum or kanban so both are popular the combination of this can be used so scrum basically helps in ensuring that things moves in iterations and everything is visible and delivered whereas kanban supports in terms of making it more visible and able to manage it better so agile product delivery so a large organization usually consists of several agile teams it led by their respect to scrum Masters so these teams together represent Agile Release trains also called as art so they usually involve 50 to 125 people so art are cross-functional and involved everyone who understand customer needs and can help with building and delivering the solution required so art uses an agile delivery practices like the one used by the teams to deliver value to the customers so it uses time boxed iterations called program increments or pis which usually involves four to five iterations all the teams they get together to plan their work during Pi planning events so they should work together they should have full visibility while doing it so three major components which are required when we do a gel product delivery is released train engineer then project management and then system architect so release train engineer represents the coach of the art facilitated the pi planning process the project management provides the vision for the project and backlog of the tasks system architect provides architectural guidance for the process and then the teams then make plans regarding what they would be able to deliver so the program board is also drawn up to determine dependencies between the teams which also goes through program iterations the pis as I mentioned earlier then after every iterations the art shows the integrated output to all teams through a system demo so after the pi is complete all team get together to retrospect event called the inspect and adapt events so further a continuous delivery pipeline is set up based on the art divorce practices are also used to ensure values available on demand I think the term devops is becoming more and more popular today which actually providing that visibility need for collaboration need for cultural transmission so which helps in terms of bringing that agility across the organization as well as learning organization so one of the principles of devops itself says continuous learning there should be continuous experimentation and learning risk taking intelligence risk taking and also we come across picking the concepts like say Main Army concept like introducing failures into existing systems and learn what can fail and what is the solution for it and that can help in terms of becoming more resilient and reliable system so devops has become popular and Adoption of that discussion on that is become more common across the organizations so next Enterprise solution delivery so Enterprise solution delivery let us look at the scenarios where a single art may not be able to deliver an appropriate solution a solution train which coordinates multiple arts and suppliers would be able to provide Solutions in large and complex scenarios so meaning consideration of Enterprise has a whole seeing end-to-end organization entire visibility so basically what is that we are trying to achieve so alignment we discussed about which requires the objective organization because organization is investing so whatever we do at various different levels should complement to each other rather than contradicting so that complementing thought or complementing visibility can happen only when someone has a bigger visibility Enterprise World Wide Outlook then the three major components that are required in the Enterprise solution delivery would be solution Management Solutions architect and solution train engineer the solution management holds content authority over what needs to be built solution architect handles the architecture across the Arts solution train engineer enables coaching and facilitating of solution strain events so next is lean portfolio management so lean portfolio management provides ways of creating and combining strategic themes and portfolio vision this enables solution development to be aligned with Enterprise strategy so the moment I say lean firstly we should keep in mind that it's about creating value to the stakeholders that is first thing second thing is elimination of waste now when I link this to strategy when a link to towards the organization's directions what it sets and while going in the directions I should ensure no defects are actually moved downstreams or are eliminated when it goes to Downstream so customer should see the value which is very important and identification of all the contributions of waste has to be done and eliminated so this ensures there is a value in organization's value stream which also ensures that these value streams remain funded so funding plays a very important role so next is organizational agility so when I say organizational agility it should ensure the organizations various business units in the organizations should be with that dynamics of agility which organization is going through which organization is moving through as I mentioned earlier if you have a project where you have you have adopted agile methodologies it's quite obvious for your pace for your flexibility for your speed other business units which are working with you to support you should also complement to that they cannot become slower they cannot have their own pace of doing things like in your project you have a procurement you have a recruitment you have some claims to be cleared from HR maybe you're dependent on certain tools and environments now if these are not agile if these are not responding in the same flexibility or same speed what the agile project team requires then obviously things will not flow further now when I say agile obviously we introduce products or Services quickly to the environment now someone needs to manage we have operations now can operations manage the products or Services which they are not aware of now even there the agility is required as I keep introducing the new products or services to the environment operation should also be well informed and educated about it so that they can monitor and manage them effectively and efficiently if they fail I think users will not have a good experience your product or Services may have a great features functionalities but however if Whenever there is a query about that product features or functionality Whenever there is an issue the incident which user actually calls the first point of contact foreign users would be the operations the moment operations fails to respond with the right clarifications or rights resolution quickly then obviously user experience will result in not a good way I think customer satisfaction or customer Delight will be at stake say when operation should be committed so rest of the business units which are supporting like funding we spoke about the funding is not done in agile way obviously the things cannot move smoother or easier so everything across organization should become agile organizational agility has to be ensured so enabling portfolio with strategic agility making change in the direction depending on the scenario then encouraging the growth of lean thinking people and agile teams so people should be working towards ensuring creating value always every task every transaction is what they do should be enabled through it so they should also know whatever we are doing how this particular task or the work or the results what I am creating results in value addition or value creation to the organization does it really align to the organization's requirement is it fulfilling maybe customer as a stakeholder or my own organization the business unit which is actually investing on this project so in that context or in that perspective everyone should be aware of that alignment the directions the vision then focusing on value and helping with organizing and reorganizing building an environment for the flow of value across the organization so everyone should realize value so value is what value can be defined in the perspective of every individual's background and every individual's requirement because it's a perceived one so there may be real thing what we have created but perception is different so the perceived versus what is actually created should be as closer as possible so zero deviation is expectation but difficult but however it should have a tendency towards it it should actually be very near to that perceived reality but two things involved one is that I create a features and functionality for my product or Services which fulfills customer requirements customer may not know not well educated not aware of it and don't know how to realize that value how to know how these features and functionalities can be used so now if you educate that customer the user how to use it what are the values it can create and do some exercise in terms of educating training coaching customer can visualize and understand that that is one possibility second thing is customer is very matured and our product does not have features and functionality required so these are the two scenarios which required lot of interactions and engagement so that increasing in terms of usage of product and services and realizing those values so this has to be encouraged more and more so further continuous learning culture so when we say learning it's quite obvious organization should keep maturing individuals in organizations should keep maturing in terms of capabilities in terms of ability to do new things innovate the knowledge the capability skills competencies so that can be possible only through learning so learning should be continuous so this ensures an atmosphere of innovation and constant Improvement until organizations becomes a learning organization so many at every level each individuals each professionals each Engineers each executives invest their time in learning they learn through what they are doing they go through formal training they bring in that formal training learning into the actions here for there they learn so continuous experimentation creating an hypothesis working on those hypothesis aligning that to the requirement of organizations and seeing how is it complementing to the organization's requirement so seeing through this are very essential so the organization which is having the culture of continuous learning can sustain and grow continually there is a question of looking back if organization has a scenario of not learning they will fade away they may fail to exist so it is very much required to understand the market dynamics continuous learning there capabilities and skill enhancement continuous learning here Innovations and making things better continuous learning so continuous learning helps organization to be there in the industry and continue with the competition so next is lean agile leadership so it's quite obvious leadership plays very important role it's about guiding it's about owning it's about showing directions it's about ensuring everyone does the task everybody is motivated so the leaders must embody teach and exhibit lean and agile principles and values so firstly they should understand what it is they should be aware of it they should have an exposure to it they should have full awareness of it as I was learning about continuous learning culture in the previous point so leaders should do that first so only then I think the followers will actually have learning adopted to themselves and things move smoother and better and this should happen across the organization so by doing this it is quite obvious organization can become better agile organization is complemented to achieve the objectives and goals what they wanted to accomplish and uh there is a safe configurations which one needs to ensure which involves essential safe raw solution safe portfolio safe and full save so when I say essential safe it acts as the foundation for all safe configurations and is the easiest starting point for implementation so large solution safe it is used for building large and complex Solutions whereas portfolio safe provides principles and strategies that can enable business agility in an Enterprise so when I say portfolio it should be understood as a portfolio of an organization as a whole the service portfolio the product portfolio the business portfolio so understanding of that and complementing to that is very essential so full safe is a comprehensive configuration that includes all competencies and ensures business agility so advantages and disadvantages of safe so advantages involves enabling decentralized decision making it eases collaboration across cross-functional teams it ensures decisions are made with strategic objectives in mind so disadvantages include additional layers of oversight which makes it resemble the waterfall approach the top-down approach can limit understanding of the software lifecycle and cause bad planning so visibility providing that visibility is very essential then larger planning cycles and roles that are fixed in development Cycles 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 challenges 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 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 mid-course 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 up front that would be followed by the necessary analysis and program design work then comes the actual 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 need 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 planned features the study summarized as follows the agile process is the universal remedy for software development project failure software applications develop 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 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 kanban even scrum for that matter let's talk about Strom now scrum is an implementation of the concepts of agile so basically most of the important components of a child can be applied to scrum as well it provides the customer with incremental builds that are delivered to the customer in the span of two to four weeks an organization can be agile but not practice crop however an organization cannot practice scrum without being agile next up let's have a look at projects agile is more suited towards projects that have a small 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 would rapidly next we have leadership now for agile a project head takes care of all the tasks and has a very important role to play in the process of a gem 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 guidance 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 every 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 Sprint 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 for scrum daily stand-up meetings take place with specific roles like scrum Master product owner and scrum team and finally we have design with agile 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's 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 kanban or is it scrum now if you do want to know more about how scrum and kanban are different from one another you can check out our video scrum versus canva kanban comes from the Japanese word can bam which literally means signboard like scrum kanban is a popular agile framework that is a visual system by which the work can be managed with ease as it progresses kanban uses something known as the kanban 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 kanban is transparency since everything related to 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 kanban 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 kanban 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 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 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 iterative 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 that 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 aim to deliver releasable software often and earlier than expected so now that we've reached Midway let me ask you guys a question do you guys use scrum or kanban 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 kanban it's even driven the next criteria we're going to have a look at this release methodology in scrum releases take place after each Sprint which usually takes two to four weeks to complete for kanman 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 this print is in progress once it's complete changes can be considered in the Sprint plan and then added to the Sprint backlog with kanban 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 kanban lead 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 kanban cross-functional teams are optional but specialized teams that focus on particular aspects of the workflow 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 nitration in kanban new items can be added to the board as long as there is 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 scrumpteen with kanban 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 kanban the board stays persistent throughout the entirety of the project and finally let's have a look at project length with scrum it's better suited for longer projects and with kanban 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 kanban 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 are Facebook General electronics and Adobe companies that have implemented kanban are Siemens BBC and sap and what I want to do team is I want to before we get into the user stories I want to go to the Whiteboard 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 ethics and user stories grouped together for planning purposes so an epic is Big you would never do an epic or pardon me a theme in a Sprint it's too big 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 ethic was higher up on the product backlog um it would have to be more detail 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 and the Epic rises in priority it will eventually be broken down into more manageable user stories so great big low priority user stories use your 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 the 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 stories into tasks that's then in the Sprint planning meeting and then those tasks are the things that are actually then done when the 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 tasks are estimated in I Ideal Time which is usually ours okay so now back to our slides so it's 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 ethic 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 a number of user stories 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 done 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 range these in priority so this one first and that one then that one and the team says well the only thing is is that we have to do some development work before we can actually do user story two 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 priorities because of you know successor predecessor relationships dependencies and things like that are 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 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 is usually going to contain um a brief description of the user story using some kind of a meta language format like we're suggesting right here as a user or Persona I want this feature so that I can so not unlike our um estimating session here as a frequent Graveler I want to eat grapes so I can be healthier in the one that we 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 tried to come up with these different roles right here executive buyer sells rep Etc 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 a multiple user stories in order to support that use case and so of course 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 are grouped to form an epic or higher level story so epic or theme stories can then be split into child stories or tasks and so that's what we were covering before right you see you have 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 stand 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 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 but she has she as if 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 barrage did you hear that team as a product supervisor I wanted 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 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 engine 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 exit has other options like you can do a paper-based test where you get a third party you know a buddy or somebody who will agree to sort of Proctor 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 they can verify that you don't have any cheat sheets up on the wall or anything like that but the point is is is you got to have this memorized whether you're going to dump it out on the paper or not when I took the test I actually did the paper-based option um and that was because of some kind of 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 reminds me that I've got to have i n v e s t 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 the necessity but um if you developed 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 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's 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 estimatable except estimatable is not really a word it's estimable um and as this model to be small enough to be done in a single Sprint if we're doing two-week 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 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's 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 card so user stories should be able to be written on a four by six inch index card or some media similar to that card does the check and see 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 in order to be used during the Sprint review to assure that it's acceptable that there's confirmation oh let's add that to the memorization list so three C's all right now I've got any people here of a user story card so we're looking right here and if we were to go out on the internet and search um user story cards 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 Ideal days but you know we'll cover both so you understand the difference is there is probably it's not listed here but there's probably going to be a value point assignment this is where the product owner kind of determines in a relative way the 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 this other one comparing them together and this is what these value points are what's used to 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 it could be words that has to do with you know where the story came from did it come from the customer that would be considered a functional requirement 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 you're from um here it's got uh customer tech you could also have defect you could maybe have risk and then there's also going to be an X Factor um which would be this kind of word probably like um stable erratic um incomplete something like that to uh so the team is designating the user story in 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 some efforts to actually figure out how to actually do that user story so that's the X Factor over to the right here on the same chart we have some comments about if you are using a 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 they're cards sometimes they're like on sticky notes and they're put up on a kanban board if you're using kanban to track the project foreign 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 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 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 canceling it so that could be split into in this construct here three separate user stories you could also separate based on exceptions or cross-cutting 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 over pays then 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 ads on other concerns like the check access restrictions or record name of operator so maybe um you know when you're working on uh accepting payments or processing refunds it's going to check on who the operator is or track that so that if at a later time you know who is 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 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 which could then be split into summary information and separately receivable details or you know maybe you could have AP you know so you could have different portions of the overall um balance sheet activities that need to be done so enter AR enter AP C makes 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 too big now when it comes to determining value for user stories this is primarily owned by the product owner right and it always comes back to 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 well below that there's another consideration incremental Revenue so somebody's in the process of placing an order um maybe there are some premium features that could be add-ons at that point in time 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 so that the cost of delivering the product is reduced so this then leads us to a discussion about priorities recognizing that there are some priority concerns that come from both the customer domain as well as the technical domain and there are some prioritization models 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 done 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 because that would happen yeah a uh oh excuse me fact on the future things that need to be done there's the the Cano model 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 or 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 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 channel model and then there's uyghur's relative waiting method and um this is all using numbers so each feature is given a value for its benefit and its penalty given a value for penalty meaning what's the pain is 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 priority for the user stories we also talked about Moscow didn't we did we talk about Moscow 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 Priyanka 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 the Sprints are going to be three weeks in duration obviously not all user stories can be completed in a shingle Sprint and be done with the project well I guess maybe I shouldn't say Obviously what 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 it's the team's capacity to complete work in a given Sprint and it is an observation it's not a prediction so if we're working on Sprint 5 and we're working on determining what our velocity is then it would be the average of the previous four sprints if there were any uh outliers you'd you would 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 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 five three eight thirteen 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 if you were 36 you were claiming half of the two that were five so that would be a total of 10 so you claim half of it would be 5 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 9 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 philosophy 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 this here up at the the brightest 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 working on has uh three versions which make up the product roadmap 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 roadmap 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 Preparatory is high level ethics and determine goals and releases so we'll use epics and themes in order to group things together you know it should be included and what's released 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 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 of Sprint length and then figure out what our velocity for each Sprint is and then 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 a definition of then or acceptance for the release and try not to pack too much into a release backlog so uh uh just like you would not want to pack too many user stories into a Sprint you want to have the timelines appropriate and what are included in the events 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 um or at least you're doing more of the detailed planning on that 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 release three and then you've got 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 and 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 intend them with high level planning for things in the future and we talked about deciding as late as possible I believe meaning that it's better to actually plan the latest releases yeah for purposes of making sure we have more information the most information available okay so 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 if I were to draw this chart I would make it a little bit more like this so clearly you're going to de-risk 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 team 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 Keem 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 ask you to have to do the work okay top right overestimation 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 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 re-estimating 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 could 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 from estimation techniques might be more inaccurate at the beginning of a project but they will quickly become very accurate as the project advances forward excuse the 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 can just use my mouse here if we were tracking velocity so this would be points completed over here 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 functional Behavior you know somebody's the team just keeps chugging on other things you know just um oh sorry I'd bumped the thing on my screen there um um so the team you know learns how to work better together and you know they ask them it's become more accurate Etc and you would expect a higher for 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 priyanta could sit down add a keyboard and code for eight 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 distractions so it has to be converted into elapsed time now we don't convert it to elapsed time at the user story level but we do convert it to elapsed 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 you determine how much time in a given day a team member is available to do work so say it's five 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 elapsed time um I should have circled this box here because we talked about this as well um and then I already mentioned this year only considers actual work time not the distraction 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 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 coconuts to that Baseline and we say okay you know what it's going to take more effort to eat the coconut than it is to eat grapes or apples 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 stand-up here it is if I had said Team I want you to pick a small user story a medium user story and a large user story and then we would then compare other stories to those three and so we would kind of triangulate on it let's say that we did you know two was small uh I'm sorry I'm saying that right grapes were 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 values you know now I used in our example the modified Fibonacci series what we do in scrum and agile if we're using story points we're going to use a non-linear 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 five plus eight a is three plus five five is two plus three and three is one plus two if we were doing the real Fibonacci series this wouldn't be 20 it would be 13 plus 8 which would be 21. um 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 three five eight thirteen and twenty um another non-linear scale is doubling one two four eight sixteen you typically don't go too far to the left with the values because 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 buffer time be included in the actual estimates um let me answer that question first by going back to ideal Prime 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 priante if based on your duties in the organization and our work day 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 elapsed 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 to user stories that we're using story points it is different 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 yeah 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 that user story to be completed so do we accommodate 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 say you know this is going to be a bigger user story than one that's similar but has 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 and it does kind of shine a light on wasted time waypoints are harder to explain outside the team um you know the suit says well 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 tennis system 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 in 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 when we got our day going we started with 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 decided what their vote was going to be and then everybody voted it once if there were outliers they were discussed and the reasons for that those variances those outliers 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 them 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 at the beginning of our day uh together 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 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. you're starting with that which is Affinity estimating foreign 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 hello Learners simply learn brings you a certified scrum Master certification training course that is the unlimited resource to equip you with the knowledge and tools you need for Success you can find the course Link in the description box below to learn more about this course now let us look at a typical scenario of an organization where the need of user stories would come in so looking at this scenarios an organization would have a scenario where the existing products are sold very well in the market and 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 products sold really well in the market now let's think about new products so we'll need to make sure we can understand the requirements and fulfill the 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 the 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 Insight 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 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 this 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 clear now what will happen now the user Community if you visualize there is a user as an employee of an organization who submit claims so there is a user in the finance perspective who is going to deposit the money similarly 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 write 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 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 these 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 storage so many user stories together forms epics which will provide certain Insight towards how these Visa stories are connected with each other so similarly initiative refers to combination of multiple epics forming that initiatives so which is very essential to groups of 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 teamwork to goals of the organization through epics and initiatives it should be looking at that objective exactly what is the directions we are getting into and how these combination of user stories so as an employee I am submitting my claims so what is that required in that user's perspective there should be story so Ayah as a finance person I'm going to clear this claims I'm going to pay with them when I 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 reality are added later after discussing with the team so I 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 eases collaboration with team members because finalization on the user stories and understanding of the user requirements should happen after discussing with the team members each one would give their own viewpoints and a 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 are 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 intact 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 it's 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 local Communications means lot of interactions happens while discussing on user stories so since people are doing it locally so there is some Personal Touch also established collaboration can get established save the 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 self-contined 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 Rewritten 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 these 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 discussable and should be open for negotiation for any change scenarios so next valuable when I say valuable it is quite obvious we're speaking about value what is being created for the users or consumers so a user story would represent the goal or an objective or 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 is a value being added to the consumers and customers or users always otherwise user story doesn't make any sense so esteemable so when we say estimable one should always be able 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 news 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 that scenarios and then come and discuss reasons may be anything so stories if you 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 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 too big it's quite obviously that is again indicative so user story should be subdivided in 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 three to four days these numbers are indicative so not necessarily you should be fixing with this number so just an indicative to show you that what would be the focus when I say use 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 I say testable obviously there should be metrics a Target Matrix 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 customer's need so then how to write user story this is very important uh 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 one two when we say one two 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 non-functional 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 a chart portal so claim processing requirement now this can be the 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 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 C's of user stories which we call it as card then conversation and then confirmation so when we say card card provides a written description of the user story so what do I mean by return 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 and 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 look in the perspective of invest what is invest what we 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 store 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 a 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 whatever the understanding we have maybe as a product owner or the team member a developer is my understanding correct the user perspectives 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 three C's refers to card conversation confirmation card provides the user stories which actually represents as we took an example so it will capture that so that it also fulfills the thought of invest 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 on 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 so it may be a related to a problem it may be relative 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 push towards creation of the requirements and user stories so the life cycle of user story starts from there so how does it go so it involves right from the point pending to to do the discussion then developing conforming 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 a 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 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 set pending to to do 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 feedback 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 there is a 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 users to refine 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 store is completed at this stage for new requirements or new features a new user story must be created any new features or new functionality I am required to add to this particular product then I would write another user story and the same life cycle starts continuous and this is not an ending thing so as I keep modifying the features as I add new features add a 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 am submitting a particular request or access 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 store 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 system's 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 I will say which one is the priority which user store is a priority first thing which I need to focus on so vertical Arrangements represents how in a given specific user Story how the activities perspective task perspective sub task 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 admission 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 which banking application would use so but here we need to visualize the user's Journey while accessing the net banking portal viewing the Account Details paying bills like utility bills doing a lot of transactions within that particular portal net banking access the moment they do like generating statements or transferring money to one of the benefit beneficiaries Etc so all these transactions so 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 logging into the account means net banking portal will come in then one would input their credentials and then they login now that journey of the users in a specific activity what they do is visualized Now log into account in a 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 working or if I don't remember it reset password is an option immediately now as I go through further from this sub task in all the particular columns which I have given here 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 subtasks 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 generating 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 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 art copy of this so similarly transferring money so you will go to that specific wage where you need to transfer the money so you may have the beneficiary there in the list already added if you have ordered earlier or newly you are adding a beneficiary so the various types of transfers like so International transfer you will have local domestic transfer you live within a bank accounts being within the same bank bank a to 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 and transferring your 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 this 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 the 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 a consumer would give I think initially if I go back when actual 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 uh there was no opportunity to transfer money there was no opportunity to do something beyond that so 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 evolved so as they evolve it is quite obvious we may require to keep adding those features functionality by writing the user stories this is how the announcement 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 study what happens throughout 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 an example similarly the focus is on user value the moment I click on web page www.abcbank.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 the response from the server where this particular website is hosted that experience needs to be looked at so that's how you look at 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 is is a genuine user is it just a password is there any captcha 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 in today's user if you just put in various different checks points they understand because they are well educated so white all those things like captcha or OTP scenario scheming so these are came in because more and more informed the people has become then their ability to hack also improve 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 roadblocks 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 beneficiary which I have added there's something which is not correct so they are given 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 beneficial is added if by chance someone who is not authorized adds it so who is going to disbenefit obviously user will be disc benefited so that block is 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 roadblocks 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 a 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 you are just adopted a waterfall methodology you have just adopted an agile you write user stories you write the Peaks you write bring in that various different methods to do something whatever you do whether there is a product or a service or a process or a specific transactions tasks 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 hello Learners simply brings you a certified scrum Master certification training course that is the unlimit resource to equip you with the knowledge and tools you need for Success you can find the course Link in the description box below to learn more about this course so explain agile in brief if this is the question what could 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 have seen people say whenever I ask the question what is agile 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 a child 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 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 agile 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 agile 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 a bit difficult it is rigid because it is 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 towards software development where involvement all the members involvement of all the members like customers maybe the team members the project managers so their active involvement is very much required so that things can be handled better so whereas waterfall models 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 bases 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 over a follower chat it is easy to adapt to the 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 comprehensive way detailed so that small changes may impact other parts of the the products or descriptions which is defined so software development 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 built 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 Declarations so that users can give the feedback quickly whereas testing phase is separate in 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 when the entire life cycle of the project wherever the change comes in taking the changes making the necessary changes will be 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 collaboration 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 the agile methodologies whatever is defined actually emphasizes on having the face-to-face conversation collaborating better uh contributing proactively and involvement proactively 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 nursery feedbacks so constant peace a gel 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 pays 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 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 HL approach self-organized the team is self-organized so self-organized teams provides best architectures requirements and design because they have in 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 terms of providing the Insight towards how is it progressing so that will help in quickly doing the necessary Corrections which are required to be done so next question number four explain iterative and incremental development in a chart 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 overtime 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 am just going that is my destination yes definitely there is a destination while progressing there are a lot of variations which happens those variations has to be considered and accordingly the necessary deviations or Corrections adjustments estimate and things to be progressed for that 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 projects 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 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 may be 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 this kind in the next iteration so that we can able to make this product better so such kind such a conversation the incremental lighterative approach helps our allows or provides that opportunity to express so causing product roadmaps to be built produced tested and conformed before the next iterations so that's where before we 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 are 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 enables team to create high quality software and improves their quality of life it enables software development with appropriate engineering practices so next is kanban 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 kanban 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 visualized 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 the to the client ensuring waste is minimized so lean principles real approaches says the flow in a flow if there is any bottleneck that tends 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 a contributor of the waste and eliminating those causes and moving forward this will help in smoothening the flow at the same time improving the system for better outcomes so that's where lean is become popular and well acknowledged so scrum is a framework that is used by teams to establish a hypothesis try it 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 a 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 in software development organizations so where it has a simple five events three roles and three artifacts so it helps to adopt and adapt to the changing conditions and it has become a proven practice now 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 became 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 feature's functionality of the product is helpful to accomplish that business requirement so this feedback comes from the customers and users when we produce that working piece of the product so all team roles testing development Etc need to be involved in testing process so one cannot work in isolation they should be very good collaboration people from various different teams working together complementing to each other very essential to become a major 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 their 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 that iterations some changes happens we developed it create rate 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 and shows 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 burn down of deliverables which is usually represented using burn down charts similarly we have burn up chart also where as we complete the task the height of the bar keeps increasing in burn up charts but most popular is burned 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 be done and plan are we going accordingly or not so this will help in terms of making our job as per the need so Matrix has to be selected very carefully so Matrix is not just a number it should have an interpretation and that interpretation should actually complement to the business needs and requirements so Matrix should have an clear description of what is this measurement is all about and what is that we are going to understand from that measuring that Matrix so next is what is kanban so kanban 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 it is a visual system so there will be bored or a display system where each of the tasks which needs to be accomplished are displayed there and the person who is who is 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 kanban 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 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 pulled that task it is my job my ownership to complete it 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 many many organizations today because if the value of using it the contribution of it is seen by organization and can't learn playing its 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 these 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 today whenever whenever people say we do Agile is uh some of these are listed here like jira software Trello Zoho audix Verizon one and many more I think 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 lot of analyzes uh assessment on the tools and the comparison with what is being done in 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 what needs to be there in place in the organization when they become agile or adopt and adopt certain practices what are the obstacles to the agile process so some of the obstacles that one could face 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 to 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 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 these unseen requirement is very Dynamic so when they will crop up we will not know but however the system is what we're designed should able to provide that opportunity whenever such variations happens you can able to easily adopt or involve 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 a very important role so a lot of resistance would come across to adopt the new way of doing things people may not appreciate the agile way of doing things so it requires a lot of effort motivation and making people to understand why the organization has taken up 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 manifests 2 and 12 principles acts as guidelines to become a child whereas 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 manifests to mentions about the required collaboration interactions to become agile 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 in agile way so uh agile manifest also mentions uh about the required focus on working software and focus on change whereas a 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 a 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 builds our delivered 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 stand-up meeting and other scrum events like Sprint meeting Sprint retrospective whereas people sitting and discussing about writing an user story they picks or selecting the product from the product backlog to the Sprint backlog so various events which happens in scrum demonstrating that uh point which is trusted in agile Manifesto about individuals interactions and customer collaboration by are demonstrated with various different events in scrum methodology so next question what are some popular agile certifications so some of the popular result certifications are PMI ACP certification which is offered by PMI us Chrome Master certification then certified scrum master prints two agile certification then scrum product owner certification so next we will move to a scenario based questions so before we 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 the online marketing campaign to increase the sales due to increased computation 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 organizations website with all the features and functionalities the various roles involved in the marketing campaign or marketing manager marketing team campaign coordinators creators of content and brochures for campaign and the participants of the campaign all of these rules should have access to platforms registration so that they can have the required access and make the marketing campaign successful besides marketing manager has told the reports needs to be generated which depicts the number of campaigns conducted responses registrations conversations Etc so this scenario speaking about the marketing 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 to ensure 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 marketing manager is something anyway we will look at it what it is but user Stories the one which depicts the requirements assuming the role as a specific role I need to do this I want to have this it gives it an explanation so that one can easily understand about that requirement what need of consumers or what need of business this particular features functionality is going to fulfill so let us see what is that user story relating to marketing manager and participants so yes why not here are a few examples marketing manager user 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 an 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 a participant perspective as a participant I need to register for the campaign so now there should be a registration page obviously and then whatever the process needs to be followed to create that registration for the participant that needs to be made and this simple user story helps in to visualize what features functionality has to be there when we go 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 HL why not I do just like that so 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 is dynamics of changes whenever I want to become someone who can able to become competitive because computation is also responding to the Dynamics of the market quickly I should be there in that business so obviously does the quiz 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 uh 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 requests exercising continuously and creating the products according business 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 likewise you 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 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 functionally developed in such an order where for that moment that which is in functionality are available we're not just jumping into everything and doing it one by one in a order in a priorities list so it is very essential to prioritize defining the definition of done and selecting the items accordingly and then what value 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 in involvement is very essential because it is a marketing campaign yes the involvement of marketing manager is very important and crucial and it is the 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 so with this we have come to the end of this agile boot camp if you have found this session informative and interesting please consider subscribing to our YouTube channel until next time thank you stay safe and keep learning hi there if you like this video subscribe to the simply learn YouTube channel and click here to watch similar videos turn it up and get certified click here foreign

Channel: Simplilearn

Views: 80,866

Keywords: agile bootcamp, complete agile scrum bootcamp, agile scrum bootcamp, agile bootcamp training, agile for beginners, agile training for beginners, agile scrum, agile scrum master, project management, agile scrum training, 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: IgcEIe5nwu4

Length: 217min 3sec (13023 seconds)

Published: Wed May 24 2023