Scrum Methodology | Agile Scrum Framework | Scrum Master Tutorial | Edureka

[Music] hi all this is a parsnip from Eddy Rekha and in this session we are going to learn all about scrum so before I begin let me discuss the agenda for today you're going to start out by discussing a little bit about scrum this is where I introduce you to what scrum is a little bit about the framework you can discuss why we do not follow the waterfall method anymore followed by which we are going to talk about from framework the basic elements of scrum framework what it is built upon empiricism and the life cycle of scrum then we will discuss what is a sprint the various elements then we are going to discuss scrum ceremonies where and we are going to talk about a sprint planning daily scrum sprint review and sprint retrospective and then I'm going to conclude the session all right also kindly take up this time to go ahead and hit the subscribe button so you never miss an update from the a Eureka YouTube channel so without wasting any further time let's get started so what a scrum now to understand the importance of scrum let's look at how scrum compares to the older alternative which is the waterfall development the waterfall model consists of a long time which is involved in planning then again by long time I mean a couple of weeks maybe a couple of months then it might take about the same amount of time to build the product say a couple of months more then testing followed by reviewing and then finally deploying the product at this point you might end up bringing the wrong product according to the market demands to the market because when you started out with planning this product it was almost a year ago and now the market demand might have changed now I'm sure a lot of you might already have guessed what the problem is with such a model firstly the entire plan should be complete before you start building or testing your product now obviously if you are doing this in one whole iteration it means that to the planning is being done without understanding the project or the difficulties that you might face while building the project the drawbacks the loopholes and most times up to start building the project it is sent back to the planning phase again which brings you back to your square one in which case your project has to start over or the developers are just criticized for not understanding the plan properly this process can be repeated many a times which consumes a lot of time followed by the product getting thrown over the fence to test where in case you encounter problems the project is thrown back to the building process or sometimes again back to the planning process and the same thing can happen over the next few steps including a lot of back stepping and doing over this can lead to lag times and many months or several years in order to get a product out the door scrum solves this problem by breaking the project into smaller parts first you start out with just enough planning to get the project started next you build the project with the minimum amount of features which is like your base features and then you test for the same and review for the same and once the cycle is complete you have in your hands a potentially shippable product now this process takes around two to four weeks and it is repeated time and time again reducing the time taken for the cycle of planning - testing - reviewing a certain product this way you end up with several different versions or several different incremental releases each taking lesser time than the previous or just about the same time and by the time you have five iterations of these you already have five vividly improved versions of the same product each keeping up with the market development that's going on outside of your company and this is called scrub so scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value now you need to understand three things about scrum firstly scrum is lightweight second it is simple to understand and third it is very difficult to master scrum itself is a simple framework for effective team collaboration based on agile and it is the opposite of a big collection of interwoven mandatory components which are a part of the previously discussed waterfall alternative now scrum promotes developing products through processes techniques and practices with various iterations and increments to deliver maximum value as I had mentioned before so that way the first cycle of your planning building testing previewing shall be called your first iteration the second one will be your second iteration the third time you plan build test and review will be a third iteration followed by the fourth and finally the fifth now these items are called strengths and at the end of each sprint you have the launch of a potentially deliverable software each software version much better than the previous one each sprint takes up about one to four weeks and you keep repeating these Sprint's until your product is feature complete sometimes you might even end up shipping your product after just the second sprint but sometimes it may also take three four or five or even more sprints but at the end of it you have a good product and that is what matters now scrum follows an agile approach to tackle complex problems now agile is not a methodology or framework or process now Eagle promotes self learning and self-organization as opposed to a lot of planning and a big collection of interwoven mandatory components it implements a scientific method which replaces a programmed algorithmic approach with a more heuristic one with respect for people and self-organization to deal with the unpredictability of complain problems this approach basically means not planning the whole entire process to create a potentially shippable product but to only plan enough to start out with and then react to the responses that you get with each sprint or each iteration now there are three rules and scrub first of all you have the person with the bright ideas who is the product owner next you have the scrum master who is the one basically implementing agile and preparing the team to follow the agile approach and making them more efficient and finally you have the team mostly the team consists of developers testers writers it can be anything each of them can be replaceable by either one of them so on certain days you might find that developers are testing testers are writing so on and so forth the main objective here is to create the product in the best possible way there are a lot of reversible roles that are being played in the team now to make you understand the approach of the scrum master or the agile approach let me take a problem statement so take for example there are a number of people in the room and they have to queue up according to their respective heights taking as less time as possible so that these many people in the room now to this problem there can be two solutions first of all we have the supervisor approach here we have a traditional supervisor or a manager and basically what they do is they arrange people one by one taking up the time for each person to align themselves which basically takes up a lot of time and also as a team you learn nothing about organization but then you have what you call the agile approach here let's bring about the same number of people and we have a scrum master now what the scrum master does is he allows the team to organize themselves and in the end he brings about whatever changes he deems necessary and that my friends is the agile approach now the étoile approach which is mostly used for software development as an approach under which requirements and solutions evolve through the collaborative effort of self-organizing and cross functional teams so basically people here are self-organizing which consumes less time under the continuous guidance of their scrum master so what it is is that it's a set of practices that promotes continuous iteration of development and testing throughout the development cycle of the project as I had mentioned before it promotes self for organizations and assists teams in responding to the unpredictability of the problem in hand and the person that promotes such an approach is called the scrum master he or she is a person which allows the team to self organize and manages the process for how information is exchanged now there are few anti-patterns when it comes to the scrum master first the scrum master is a not a supervisor now this problem is quite common with people that are usually old project managers being a scrum master is completely a different role than a project manager and therefore the way the individuals act must be completely different typical project managers tend to organize the work of the people instead of allowing them to self organize they tend to say how by whom and by when the work must be done not giving the team much space to think on their own the result of this is basically a team full of robots instead of people who have the mind to think on their own a scrum master must be aware of his behavior to be able to correct it it's not easy usually these people have worked for several years in a typical project management position and simply deleting this behavior will take up some time but being aware is the first step let people grow let people have their own breathing space and do not try to be a supervisor it is not a control situation here second the scrum master is not just a secretary now many people think this way in such a situation I get extremely worried because it means that people do not know what a scrum master should do when people think the scrum master is just a guy booking meetings felicitating dailies and serving coffee to their colleagues this is where things get very dark and unfortunately this is very common the scrum master has dozens of different roles and hats but this is way far away from the secretary job that most companies associate scrum masters with scrum masters teach recruit and poach people to grow into true leaders and work cohesively as a team and finally self-organization does not mean the absence of management like I had mentioned before a scrum master is there to constantly monitor the growth of the team letting the team self organize does not mean that there is nobody to supervise them with that let's move on to the scrum framework the scrum is a simple lightweight framework it is not a methodology scrum implements the scientific method of empiricism which replaces a programmed algorithmic approach with a more heuristic or is self learning one with respect for people and self-organization to deal with unpredictability and solving complex problems as you can see in the graphic in front of you it starts with the inputs from stakeholders and then the product owner with the bright ideas all the way till the finished products which is then reviewed in the sprint retrospective now most of you might wonder what empiricism is now empiricism basically means you're working in a fact-based experience based an evidence based manner scrum implements an empirical process where progress is based on observations of reality and not fictitious plans swamp also plays great emphasis on the mindset and cultural shift to achieve business and organizational agility so basically there are three pillars two empires first of all you have transparency now this means that you are presenting facts as is all people involved the customer the CEO the individual contributors are transparent in their day-to-day dealings with others they all trust each other and they have the courage to keep each other a breast of good news as well as bad news everyone strives and collectively collaborates for the common organizational objective and no one has any hidden agenda the next pillar of empiricism is inspection now inspection in this context is not an inspection by the inspector or Auditor or supervisor but it is an inspection by everyone on the scrum team the inspection can be done for the product processes the people's aspects practices and continuous improvements for example the team openly and transparently shows the product at the end of each sprint to the customer in order to gather value feedback if the customer changes the requirements during inspection the team does not complain but rather adapts by using this as an opportunity to collaborate with the customer to clarify the requirements and test out the new hypotheses and finally as I had just mentioned adaptation is the third and final pillar of empiricism adaptation is this context which is about continuous improvement the ability to adapt based on results of the inspection everyone in the organisation must ask this question regularly are we better off than yesterday for profit based organizations the value is represented in terms of profit the adaptation should eventually relay back to one of the reasons for adapting a joy for example faster time to the market increased return on investment through value value based delivery reduce total cost of ownership through enhanced software quality and improved customer and employee satisfaction so these were the three pillars of Empires now let's go ahead and look at the scrum lifecycle now this slide is a graphical representation of an agile project using scrum starting on the extreme left you can see the product owner owning the backlog and developing user stories with the team or requirements for the project or the product the product backlog is prioritized with a higher priority items on the top of the backlog the team with the product owner then decides to group the user stories into releases based on the product roadmap once the release plans have been completed the user stories are then selected for a sprint the Sprint can be from two to four weeks or sometimes one to three weeks the team then this aggregates each user story into tasks and then in each sprint the product is developed and after code is written it is integrated into the system and daily scrums are held at the end of a sprint there is a sprint review where the working software is demonstrated and presented then it is presented to the customer for acceptance the team then conducts a sprint retrospective to ask themselves the question what could be done better the stats on the team are then updated as are the information radiators which transparently displays the status of the team which again make their way back to the user stories and then the whole cycle begins again next let's discuss what is a sprint now as I had mentioned earlier Sprint is basically an iteration of planning building testing and reviewing a sprint has consistent durations throughout the development phase and this is mostly between two to four weeks it cannot be more than four weeks long as described in the scrum guide the Sprint is an iteration as I'd mentioned before it has a time box of two to four weeks during which a product is unusable or potentially releasable and by product I mean an increment of a product like a version of a product now Sprint's have consistent durations which are usually limited to one calendar month now during the sprint no changes are made that would endanger the Sprint goal the quality of goals do not decrease and the scope may have to be clarified now each sprint may be considered a project with no more than a months horizon in which you have to accomplish something each Sprint has its own goal a design and a flexible plan that would guide in building it what's the resultant product increment now the thing with the Sprint is if the Sprint's time box is too long then the definition of what is being built may change complexities may arise and the risks may increase hence Sprint's enable predictability by ensuring inspection and adaptation of the progress towards a sprint goal at least every calendar month now there are a few factors which affect the duration of the sprint first of all the stability of backlog now obviously if backlogs keep increasing that may push the date of the sprint and secondly you have overhead costs now Sprint's also limit risk to one calendar month of cost if the cost increases then it may affect the duration of his sprint now overhead costs now each sprint is going to have a sprint meeting the testing phase review and a retrospective now these are overhead costs now if the overhead costs can be reduced by planning and automation integration etc these costs can be absorbed now by reducing these costs overhead costs you can reduce the duration of the sprint now it is the scrum masters job to make sure that the development of the product goes according to the sprint planning now there are a few others print terminology which I want to make you aware of first of all you have your sprint goal now as the name suggests what you want to achieve at the end of the Sprint your product with the feature sets that you have decided with your product owner and your customer is your sprint goal then you have your sprint cancelation now once the sprint duration has been determined and the user stories are selected neither the duration of the sprint nor any user story can be altered however a sprint cancellation occurs if there is a significant change in priorities or mid-course correction in between a sprint considering we are only talking about two to four weeks of work the cancellation of a sprint is highly unlikely to occur next let's discuss the scrum artifacts now scrum has three artifacts product backlog sprint backlog and product increment firstly you have product backlog now for backlog as it is described in the scrum guide is an ordered list of everything that is known to be needed in a product it is the single source of requirements for any changes to be made in the product and the owner is responsible for the product backlog including its content availability and ordering now a product backlog is never complete the earliest development of it lays out the initial known and best understood requirements the product backlog evolves as the product and the environment in which you were to use it evolve continuously it is dynamic and constantly changes to identify what the product needs to be appropriate it is competitive and useful if a product exists the product backlog also exists now from the backlog refinement is the act of adding detail estimates and order to items in the backlog this is an ongoing process in which the product owner and the development team collaborate on the details of the product backlog items during this product backlog refinement items are reviewed and revised multiple scrum teams often work together on the same product one product backlog is used to describe the upcoming work on this particular product next you have something known as a sprint backlog now the sprint backlog is a set of product backlog items that are selected for the Sprint plus a plan for delivering the product increment and realizing the Sprint goal the sprint backlog is a forecast by the development team about what functionality will be in the next increment and the work needed to deliver the functionality into a complete increment now the Sprint backlog makes visible all the work that the development team identifies as necessary to meet the Sprint goal to ensure continuous improvement it includes at least one high priority process improvement identified in the previous retrospective meeting the Sprint backlog is a plan with enough detail that changes in progress can be understood in the dailies from the development team modifies the Sprint backlog throughout the Sprint only the development team can change its Sprint backlog during a sprint the Sprint backlog is a highly visible real-time picture of the work that the development team plans to accomplish during a sprint next you have the increment now the increment is the sum of all product backlog items completed during a sprint and the value of the increments of all previous Sprint's at the end of a sprint the new increment must be done and done in scrum has a different meaning done in scrum or basically means that the product must be in a usable condition and meet the scrum teams definition of done now you might think your product is done but if that differs from my definition of done and we both are in the same scrum team then your product is not considered done an increment is a body of inspectable done work that supports empiricism at the end of the Sprint now the increment is a step towards a vision or a goal and it must be in usable condition regardless whether the product owner decides or not to release it with that let's move on to the ceremonies or events in scrum now scrum has four ceremonies first you have sprint planning then you have the daily scrum then you have Sprint review and finally you have Sprint retrospective now I'm going to touch up on each of these one by one first you have sprint planning now sprint planning is basically the plan of work to be performed during the Sprint it is time boxed to a maximum of eight hours for one month or two hours a week for shorter sprints the event is usually shorter and the scrum master ensures that the event takes place and attendants understand its purpose the scrum master teaches the scrum team to keep it within the time box now sprint planning answers three major questions first what can be delivered in the increment resulting from the upcoming sprint this basically discusses the advanced feature set that you are going to deliver in your upcoming version of your product next how will the work needed to deliver the increment we achieved this is where you plan what you do in the week and the week next to it it is a scrum master that teaches the scrum team to keep their work within the time box and three when is your work considered done as we discussed the definition of done is very important to the entire scrum team everybody has to agree upon a checklist on completing which your work should be considered as done next we have the daily scrum now the daily scrum is an internal meeting for the development team it is a 15-minute time boxed event to synchronize your activities and create a plan for the next 24 hours it has held every day of the sprint and the development team plans work for today and tomorrow this optimizes team collaboration and performance by inspecting the work since the last daily scrum and forecasting upcoming sprint work the daily scrum is held at the same time and place each day to reduce complexity and answers fundamentally three questions what did i do yesterday what am I going to do today and what are my impediments my impediments I mean challenges and requirements that you have while completing your work it is very important that your scrum master know the challenges that you're facing and why you couldn't complete your work yesterday or why it might be difficult to complete your work to be the scrum master ensures that the development team has the meeting but the development team is responsible for conducting the daily scrum the scrum master teaches the team to keep the daily scrum within the 15-minute time box and he or she also ensures that if there are others present they do not disrupt the meeting next we have the Sprint review the Sprint review is an event to inspect the increment and adapt the product backlog if needed there could have been a single deployment or many deployments during the Sprint which lead up to that increment to be inspected during a review the scrum team and the stakeholders collaborate about what was done in the sprint and based on that any changes to the product backlog during the Sprint attendees collaborate on the next things that could be done to optimize the value and this comes in the form of an informal meeting and not a status meeting the presentation of the increment is intended to elicit feedback and foster collaboration in a style box at one our a week and the Sprint review includes first the product owner explaining what product backlog items have been done and what has not and to the development team demonstrating the work that it has done and finally the entire group collaborates on what to do next this is at most of for our meeting for one month sprints and for shorter Sprint's as I mentioned it is one hour a week finally the aim here is so that a sprint review provides valuable input to subsequent sprint planning the review of how the marketplace or the potential use of the product might have changed will obviously affect what is the most valuable thing to do next and review of the timeline budget potential capabilities and marketplace and competition for the next anticipated releases of the functionality and capability of the product is also discussed the result of the sprint review is a revised product backlog that defines the probable product backlog items for the next sprint now this backlog may also be adjusted overall to meet new opportunities finally you have the Sprint retrospective now this is basically an opportunity for the scrum team to inspect itself and create a plan for improvements to be enacted during the next sprint this occurs after the sprint review process and prior to the next sprint planning this is almost a three-hour meeting for one month sprints and at this time box at 45 minutes a week this is an opportunity for the scrum team to improve and all members should be in attendance now each team member has to answer three questions firstly what went well this basically helps you tell your scrum master what went well in your previous sprint and those practices should be enforced in your coming Sprint's as well next what didn't work well what were the impedances difficulties and requirement which won't fulfilled in the pita sprint and finally what should be done differently here you introduce the changes that you want in your working process or in terms of software that you're using and these are the differences that you need to commit to to improve in the next sprint the scrum master encourages the scrum team to improve its development process and practices to make it more effective and enjoyable in the next sprint during each sprint retrospective the scrum team plans ways to increase product quality by improving work processes or adapting to the definition of done if appropriate or not in conflict with the product or organizational standards by the end of the retrospective the scrum team should have identified improvements that it will implement in the next sprint and implementing these improvements in the next sprint is the adaptation to the inspection of the scrum team itself although improvements may be implemented at any time the Sprint retrospective provides a formal opportunity to focus on inspection and adaptation with that we've come to the end of all the scrum ceremonies that I had to discuss finally let me conclude the session so so far we've covered what a scrum and in that we have discussed why don't we use the waterfall model what is scrum what is agile and who is a scrum master in our next topic scrum framework we discussed what is from framework what is embarrasses 'm and three pillars that support it and what is the lifecycle of scrum in the third module we discussed what is a sprint what factors affect the sprint and what are Sprint artifacts finally we discussed scrum ceremonies where we discuss sprint planning daily scrum sprint review and what is the Sprint retrospective now it is very important to understand that scrum works not because it has three roles for events and three artifacts but because it adheres to the underlying agile principles of iterative value-based and incremental delivery it frequently customer review and embraces change this results in faster time-to-market better delivery more predictability and increased customer responsiveness the ability to change by managing changing priorities enhances software quality and improves risk management and that is the reason that scrum works with that I am closing my session thank you and have a great day I hope you have enjoyed listening to this video please be kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest do look out for more videos in our playlist and subscribe to any Rekha channel to learn more happy learning

Channel: edureka!

Views: 115,540

Keywords: yt:cc=on, scrum methodology, scrum framework, scrum master, scrum tutorial, scrum process, agile scrum framework, scrum framework in agile, scrum master tutorial, scrum framework tutorial, scrum framework explained, scrum framework example, scrum framework definition, scrum framework summary, scrum framework meaning, scrum framework overview, agile scrum, agile methodology, agile project management, scrum master training, certified scrum master, scrum edureka, edureka

Id: 8dGdIcyDk1w

Length: 34min 13sec (2053 seconds)

Published: Wed Jul 17 2019