Certified Scrum Master Full Course | Scrum Master Training | Scrum Master Course | Simplilearn

[Music] hey guys welcome to scrum master full course video by simply learn in this video we'll cover some of the most important concepts related to scrum we'll talk about what exactly scrum is the components of scrum process the role of a scrum master the scrum methodology how scrum meetings work how scrum and kanban are different from one another and finally we'll cover some important interview questions that will help you aco interview our instructors jeff and chandra will help you understand the topics with ease before we begin don't forget to subscribe and click that bell icon to never miss an update from us now let's jump right in hi welcome to scrum tutorial from simply learn i am cmr chandra mr a professional consultant and coach who is certified scrum master pmp prince2 practitioner itl for managing professional devops and kobit 5. as part of this tutorial we are going to understand the basic understanding requirements of scrum the agile methodology so let us look at the problem scenario what was there in the absence of adoption of agile in any given environment so in the given scenario there is a problem expressed so we have a problem our consumer doesn't like our product we will have to make changes immediately so now as usual any manager would respond the manager says make the changes so because it's always the changes or anything what we deliver is in the consumer's interest so keeping consumers interest in mind the value it needs to be created for customers any changes required to be done in any of our projects involving that consumers and customers we might require to do the change so but what is the problem here to do the change so we can't we already have started work on last batch the waterfall model we follow doesn't let changes to be made midway through the process so is it mean the waterfall model never allows the changes to happen that is not true hundred percent waterfall model allows us to make changes but it doesn't allows us to make the changes quickly so whenever there is a change it requires lot of effort it requires changes in documentation it asks for the changes in various different implementations which has already done which is executed already and then lot of efforts are involved which is time consuming and also it involves more cost now how do we make the change which is required to the customer and at the same time we don't have any specific additional effort which are required so these efforts whatever is being put is acceptable to both the parties both the stakeholders that is the project organization as well as the customer so how do you make it happen quickly as well that is very important for us so we should have used the agile methodologies so meaning agile methodology helps us to do this so one of the agile methodologies which we are going to look at as part of this tutorial is scrum so let us see how scrum is going to help the scenario so scenario of changes which are coming up more frequently right right before that let us understand what is the meaning of agile what is the meaning of agile what it means and why should we adopt agile so agile means moving faster being flexible responding to the changes now agile is a set of methods and practices that focuses on iterative development why iterative in each iterations agile methodologies helps us to create a working piece of the software product which will help us to make quick corrections to those software piece this is not a whole product it is part of that bigger product so requirements and solutions are obtained thanks to self-organizing cross-functional teams collaborating so when we say cross-functional team self-organizing team so these are the teams which are seven plus or minus two the size of the team what i'm speaking about who basically have various different skills each of the team members will have various different skills and they complement to it i think today the devops is speaking about this cross-functional team owning everything as a single team some of the organizations has already demonstrated their devops capabilities by having this approach like having self-organizing and cross-functional team having an accountability for the entire product the particular piece of the product module what they have created so this helps in improving accountability and also ensures better visibility of the product what is being created and delivered so further let us look at the advantages of using agile so what it gives to us how it helps so now the organization who follows the agile methodologies so we can see that projects follow a predefined schedule and have a predictable cause so schedules are seen but wherever there is a changes required wherever these directions need to be changed in terms of making necessary changes to adopt to the required scenario the change scenario agile helps us it gives that flexibility so clients have visibility of each phase of project so it is very essential whosoever adopts the agile methodology the active involvement of customer has to be ensured so they are actively involved so customers or clients actively involved in the sense they know it what is happening what they are getting they know they are acknowledging it by giving the feedbacks every now and then so that there is no surprise to them at the end which used to happen during waterfall approaches then greater interaction between project team and the project means there needs to be collaboration agile emphasizes on having the collaboration so scrum and specific have something called daily uh scrum where 15 minutes meeting where entire scrum team should come in sit together self-organizing team as well as all that agile teammates to come together express what they have completed before the last daily scrum meeting and what is spending why is it pending and what is that they are going to do before the next meeting so all these are expressed this will help the team as well as the scrum master as well as the product owner the visibility into what is complete what needs to be completed and this will help project manager or scrum master to provide the necessary inputs better visibility to the customers and stakeholders as well product output is predictable and can sometimes happen earlier than expected so now initially as we know so the visibility of anything what we do will be very less so now as we discuss more and more as we brainstorm more and more the visibility into it will become more then what would happen in future the ability to predict will also become easier and if this doesn't happen only with the project team it also happens with customers and every stakeholders who are involved in the project so next high quality development testing and collaboration is ensured since the project is broken down so now each iterations each module each piece of software which is being created are tested regularly feedbacks are obtained from the user as well active involvement of user are ensured so that they are acknowledging it so the what customer needs are given so it is not that i discovered something which i did not need i i'm seeing it i told something i'm getting something that scenario is eliminated then the product backlog can be refined and reprioritized so since we move iteration wise depending on the change scenario depending on the directions changes we can keep reordering or re-prioritizing our product backlog what needs to be created first if i have one two three four five item i can make it as three four one two five so depending on the change scenario whenever it needs to be executed it is bit flexible and easy to do then teams can maximize project value since clients can provide project priority so as we know the visibility also increases to the consumer as well as all the stakeholders they will also express what is that value they have seen from this and this will also help in making a decision should we continue with this project or should we not so better visibility better decision making better value realization the needs of the customer can be focused on increasing the value delivered so as customer gives the feedback as that visibility increases then a customer is getting that value and then expressing what is the changes what is that additionally they may required here how can make it better so these interactions can happen so customer can be focused on increasing the value delivery so in fact i think earlier we used to speak about time to market today we are speaking about time to value which means how quickly uh the consumers the users or customers realizes the value is that benefit realized so that's what the more and more discussion which is happening which requires closer collaboration with consumers and their feedbacks their experiences with the products or services which are being used by them it is very essential to understand so then various different methodologies what we have in agile we can speak about scrum kanban extreme programming that is xp lean methodologies the crystal so now in this video tutorial we are actually focusing on scrum so let us understand what is this scrum is all about right so before we go and understand what is the scrum itself so let us look at the history of scrum where it started how it started so right down the line during 1986 the name scrum is first introduced by the management experts yukujiro nanaka and hirotakat kuchi so japanese so now this terminology introduced but later in 1995 jeff suderland and ken shubar creates the early version of what would become the agile methodologies so now earlier 1995 so need for agile was sensed and it was spoken about i mean why do we need a gel methodologies in future what would be the future organization which would look like so that would trigger in terms of what kind of approaches we may require to have so further 2001 the agile alliance is founded and first look on scrum the agile software development with scrum is published so then further down the line 2002 the scrum alliance is founded by weber and certifications are added then later 2006 the scrum link is created the certified scrum courses are taught so people started getting certified on scrum then later 2009 scrum.org is created which offers the professionals scrum series of certifications then 2010 the first scrum guide is published so which made available to everyone so from then i think the more and more people start adopting scrum methodologies now interesting part is the journey started from 1980s till 2010 various changes which has happened to this particular methodology but one thing we should keep in mind is same 20 years back or 15 20 years back if we go the need for a jail was not seen so it was spoken but need for a gel was not spoken much but today we're speaking about it more and more the reason is i think the change in the market condition the increase in the competition the need of responding to the change which is asked by the consumers or the market variations has become more and more important for organizations and service providers if they don't respond to the change they may lose out in the competition so their survival is at stake so it is very essential for them to understand this dynamics and respond to those scenarios quickly so that's where the adoption of agile the benefit of adopting a jail were realized and scrum become popular so what is scrum so let us look at that so now scrum is a framework that enables teams to work together means collaboration is very important while we become agile so with scrum team one can look i mean see and experience so learning from experiences happens so those are captured self-organized working on problems so they work together they discuss brainstorm reflect on their victories means any achievements has to be celebrated acknowledged quick queens recognized and their losses to improve so wherever the things doesn't go good necessary corrections has to be done i think scrum approach would help in terms of doing it quicker better then some of the benefits using scrum would look like steam can provide project deliverables and in an efficient manner so in time we are completing all the features and functionality so the entire model the methodology what is there which helps in accomplishing those then further time and money are used efficiently so time is very important giving results in the mentioned schedule is very important ensuring results are coming up effectively is important efficiently the performance of that products now since we are creating those small piece working piece in every iterations so that experience of using that would also be there and quick feedbacks will come back so that time and money is saved and we are doing in time so projects are divided into smaller units called sprint so the iterations what are speaking about the quick iterations of activities which happens during the adoption of scrum when organization adopt this methodology so it is called a sprint it's a time box iterations which will have a set of subset of product backlog taken as a sprint backlog and those users stories and epics are delivered as part of that sprint and then those are reviewed on a daily basis as part of daily scrum meeting and also we have other meetings which will happen when we go and look at methodology how this happens i think we'll get better visibility work best for fast moving projects now whenever we need to respond quickly whenever we want to move faster now remember when we say moving faster means it doesn't mean that we can allow any defects to happen we can ignore something we cannot do that we need to ensure everything is taken care at the same time all those results what are created has to be acknowledged right confirmed yes it is defect free so all those which is supposed to be addressed are taken care and things are moving faster and better and the results are according to what was actually expressed as a requirement it is fulfilling those then scrum meetings provide the team great visibility since there is a daily scrum meeting which keeps happening people speaks about what they have done from the previous daily scream what is that they have accepted they will complete and what is complete is everything is complete or something is pending if it is pending why is that pending and what is that you are going to do further before the next daily scrum meeting so these are discussed understood so that there is a quick 15 minutes meeting which gives the insight and further wherever there is a dependency deviations which occurs further maybe scrum master sit with them separately to understand that in detail so daily scrum meetings give the quick insights so that it increases the visibility what is happening on ground constantly involves feedback from clients and customers as i mentioned earlier while discussing about agile active involvement of a customer is very essential so customer should give the feedbacks whenever that working piece of the application or a product is given so only then whether the product or that module what is created is having that features and functionality which helps in providing necessary requirement fulfillment is that happening or not then making changes based on feedback are very easy because everyone is informed and they are aware of what is being changed and what needs to be changed then individual efforts of the team members are given focus yes individual efforts is essential at the same time each team member cross skills we call it a self-organizing team as i was mentioning earlier so each team member will have a different different skills different different capabilities and also cross-skilling within the team is encouraged so that the ownership on individuals deliverables and team as a whole working together to deliver some features functionality can also be accomplished right then scrum team involves product owner scrum master and then scrum team so each of this are different roles having their own objectives to accomplish with the specific directions and each of this cannot be merged like for example the roles and responsibilities of product owner cannot be given to single individual who is a scrum master so both the roles cannot be given a single individual because it conflicts the objectives of both the rules so thinking about putting this one of the team member becoming scrum master product owner thinking in that angle is also something which is which will not work which will not give the required results so now what are these roles what are the responsibilities where is the focus of each of the roles so let us discuss on that now when it comes to product owner so the product owner is primarily responsible for maximizing the roi by determining the product features prioritizing it into a list what needs to be focused on for the next print and constantly reprioritizing and refining it so the key points what we need to see here is so one is determining the product features maximizing the roi the second one and then re-prioritizing and refining the product backlog now why is that needs to be done so maximizing roi in the sense obviously product owner should closely work with the business and have an insight towards what is that business require what is that customer require how it helps customer to accomplish that result so that it helps the justifying that investment what they're doing with the products features and functionalities then speaking about reprioritizing and refining it it depends on what features needs to be delivered in what order so there is already an order which is defined so based on the change scenario you can reorder it and product owner has that ownership and responsibilities so the entire focus is on ensuring the right product backlog prioritizing it and also adding that user stories and effects into product backlog depending on what makes sense to the business so the scrum master the next role helps teams learn and apply scrum to obtain business value means scrum master closely works with the team so he or she helps remove impediments what is impediments something which stops to move forward something which doesn't allow to deliver things the way it is required something which stops right so that needs to be eliminated that needs to be understood what are the impediments so when we say impediments what are the impediments we can think of the skills and capabilities of the team that is one thing maybe the testing environment may be a process so anything comes as a bottleneck or impediments which stops things to move smoothly forward so scrum master should work on it identify that and support team or guide team to overcome those so protects them from interfaces that helps the team to adopt agile practices so encouraging team to adopt agile practices and ensuring they demonstrate it and provides the required value as its move forwards so since scrum master focuses one side in terms of making scrum team to work whereas product owner is looking at the entire product backlog and working more closely with the business so they need to have a good handshake to ensure things go well but these two roles cannot be merged because since it has a two different angles and two different dynamics so spending time accomplishing both the things may become very challenging and conflicting and the prioritizing will also be difficult then scrum team is a collection of all the individuals who work together to deliver the requirements of the stakeholders so self-organizing team what i was mentioning what we were discussing earlier so these teams comes together each of the team member will have various different capabilities so they contribute at the individual level and as a team has a whole complement or contribute towards ultimate output and outcome and value what they need to create and this team should have a clear understanding about the deliverable what is being done so is that deliverable what features and functionality what they're thinking is that going to create that value ultimately what is need to be achieved the requirements fulfillment which is which needs to be happen to the customers so they need to have that understanding the direction should be clear to the team so there are certain artifacts to look at when it comes to scrum so let us look at that so now we speak about the artifacts which are the components of this crumb process that can improve transparency and understanding of the work so there are three artifacts mainly which we call it as a product backlog sprint backlog then product increment so let us see what is this one by one so when i say product backlog so it consists of list of new features changes to be made to existing features the bug fixes changes to the infrastructure and several other activities that the team needs to deliver to ensure a particular outcome so this list show product backlogs becomes with required features and functionalities what needs to be delivered so the prioritization of this has to happen in what order what needs to be delivered so the product backlog is the full list which needs to be delivered as part of this project and as the project progresses a lot of new backlog item would be added to the product backlog as the dynamics of the particular scenarios keeps changing so keeps adding reprioritizing additional items to the backlogs are added depending on what are those dynamics so further looking at a sprint backlog so sprint refers to that short period of iterations right so which team aims to get a given amount of work done so it helps teams deliver working software in a frequent manner so sprint could be between one to four weeks long depending on what is that deliverable is so sprint backlog is a subset of product backlogs so that prioritized item what is taken into sprint which is a time boxed iterations the sprint backlog contains the task the team aims to complete to satisfy the sprint goal so what is that sprint goal so each of those iterations the time box iterations will have a specific objective to accomplish so the sprint goal is the objective decided for the sprint as an outcome of negotiation between the product owner and the team so what can be delivered how long it takes to deliver so when it has to be delivered the target may be given by product owner but is it possible feasible to complete it there is some negotiation which happens there so they decide they agree yes we can do it we cannot do it if at all we can do it what is that it takes in terms of effort time and cost everything is decided discussed so that objective of that particular iterations is agreed upon so once it is agreed i think team should first identify the tasks from the product backlog that need to be delivered to achieve the goal so these stars are then added to spread backlog so there should be an agreement between both and once it is added once it is agreed as part of that print the deliverable the output of the sprint would be the one which needs to be completed as part of it the objectives the goal the results it's a specific working software then product increment so this refers to the combination of all product backlog tasks completed in the sprint and the value of the increment of previous sprints now when we speak about lean lean speaks about elimination of waste it speaks about value streams now in each of these prints as we have a working software being delivered now each of these piece should keep complementing to the what is the one which is already delivered and what is being delivered in future so keeping that in mind every deliverable will be implemented or configured in such a way that there is no specific bottlenecks there is no specific constraints which arises so this needs to be kept in mind which requires the entire visibility into what is that ultimate objective we are going to accomplish so in this product increment all those combination of the product backlogs task which is being done should keep this in mind team should be very clear about it so i in the first sprint i delivered something in the sprint two i delivered something but i cannot integrate them they cannot work together it will lead into the further issues and then complications that should not happen so when we say agile it's about moving faster fine so responding to change fine but that should not lead towards further complexity it should make things simpler smoother so scrum is stressing on that part so an increment refers to inspectable usable work done at the end of the sprint it represents a step towards overall goal or vision of the project as i was mentioning then the outcome should be in usable condition even if the product owner doesn't decide to release it so it should be in usable condition so two things we speak about so one is uh release other one is deployment now people usually get confused between release and deployment so release about this part what we're speaking about product is usable so it is released product is usable but only after deployment user will have an access to use it so that is the difference release makes that product usable whereas deployment makes it available to the user to use so this difference people should know so release doesn't mean that it is already available for user to use so this understanding of the difference should also be there so that one can understand what it means by release as well and what it means by deployment that's why when we speak about devops we keep speaking about cacd in cicd we speak about continuous integration continuous delivery and continuous deployment so in continuous delivery speaking about release basically so once it is released it becomes usable so once it is deployed it is available for user to use and that's about the scrum artifacts now let us look at uh scrum framework how that scrum framework looks like in entirety so what are the components comes into picture already we spoke about the scrum approach itself what it is now we spoke about understanding artifacts then we spoke about roles in scrum the activities for each of the roles we understood now where do we see all of this when we look at a scrum framework so that picture let us see so when we say scrum framework already we spoke about the product backlog we can see that it is in the left side in the beginning we have a sprint planning so we spoke about sprint the time box iterations and from the product backlog the items which is moving towards sprint to a specific sprint what needs to be delivered which become sprint backlog now the backlog items are taken and scrum team work on it and does this daily scrum meeting and once the deliverables of that particular sprint happens then there is a review on it then the increment is delivered and at the same time that retrospective what was planned versus what is delivered that is checked if you look at from sprint review so you have a retrospective to check what is planned versus what is being delivered at the same time the review points will come and get updated to product backlog as well to the product owner so product owner should be aware what is delivered what is spending to be delivered and that increment is further delivered so these increments what is delivered to production what is deployed in the production should have values that integration which happens both all the increments coming together to provide that fulfillment of the requirement as well as creating that value what is required so product backlog is the first step of scrum framework is a set of list of tasks to have successfully achieve the goals of the stakeholders we discuss that while discussing on product backlog so further sprint planning happens where the team determines the tasks from the product catalog they will work on and aim to deliver during the sprint now this is negotiated understood agreed and then most towards spring to get delivered then sprint backlog are the tasks discussed during the sprint planning means the previous step and also do the script planning and then add it to the sprint backlog once it goes to the sprint backlog as part of the time box iteration sprint the deliverables should happen now scrum team the scrum team which is actually self-organizing team as we mentioned maybe five to ten nine members of team working on the task in the sprint backlog and they will also have a daily scrums where the team also discusses for 15 minutes on the events where the team member synchronizes activities and plan what they aim to achieve in next 24 hours what is accomplished against what is discussed in previous daily scrum and then if at all any further discussions need to be done in the correction of those that can be taken as a separate meeting not as part of the daily scrum so generally daily scrum meeting would be 15 minutes it should not go more than that it's an indicative time so quicker updates to understand what is happening then uh the sprint review happens where once the sprint is complete so sprint review happens which involves the team the scrum master and product owner and stakeholders to understand what is being agreed upon and what is being delivered or reviewed is that fulfilled in the entirety that is discussed and then during this meeting the team shows what they accomplish during the sprint it allows time to ask questions make observations give feedback and provide suggestions right then the product owner also presents the product backlogs talk to the stakeholders to get feedback for upcoming sprints and about things related to the backlog now this one sprint is complete for the next print what should be the prioritization so the product owner has to speak with the stakeholders so that there is a good understanding good handshake that what needs to be delivered and what is the priority in the given list then sprint retrospective happens so after this print review sprint retrospective happens so during this meeting what went well like past mistakes potential issues what are the new ways to handle them which are required to be done correctly in the next iterations or next prints needs to be identified data from found from here are incorporated when planning the new sprint so it's works like a lessons learned what went well what did not go well what is that we did for those what did not go well so what is that learning we have in these iterations so how can we ensure that in the upcoming iterations the same mistakes are will not repeat so those can be discussed documented and then consider while moving to the next spring then the increment is a workable output which is given to the stakeholders so this is where the user actually sees that workable piece working item and then they give necessary feedback as well on the particular application piece or software piece then there is something called scrum board which is used during this flow of scrum right from product backlash to the creation of that increment so let us look at what is a scrum board which is used during the scrum practice so scrum board is a physical or virtual tool that helps team to visualize items in the sprint back clock so it helps in tracking what is being delivered what is in progress and what needs to be delivered further so it shows all action items during the daily scrum helping keeping the team focused on tasks that need to be completion and the priorities of those the scrum board is usually present in a place that's accessible to all team members it is a visual board right and can be physical white board and stickers are virtual software tools which can be used and displayed on the screen so the scrum board is divided into different slots like to-do in progress and done so when new sprints are started the existing board is reset and new scrum board is created so since it is visual system i think it is taking the thought from kanban so visual system always works effective because the moment i know i see something is put against my name that i need to complete this it's quite obvious to me that i will put efforts to complete it so it's a conscious effort what i will put it works on my consciousness so something which is not visible to me it is that out of sight is out of mind so i will not work on it so i may there is a tendency to forget first slide here has to do with user stories and ethics 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 epics and user stories grouped together for planning purposes so an epic is big you would never do an epic in 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 epics are low priority large user stories meaning that an epic will eventually have to be disaggregated into multiple user stories the reason it would be low priority is because if it if an epic was higher up on the product backlog it would have to be more detailed that's when you would break it down so epics are usually going to live at the lower 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 then we have user stories themselves user stories are functions or features that the product owner wants to have developed a user story turns into working software that provides value to the customer and 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 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 user stories into tasks that's done 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 hours okay so now back to our slides so at the top left a use case could be an example of a user story so it's something that the user wants to do and how the system should support it um like a use case could be select and pay for items in a catalog now that could actually be an epic or maybe a theme because maybe it would get disaggregated into log on screen uh catalog uh shopping cart and checkout but so the use case could either be a standalone user story or it could actually be 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 then but the team may know that it has to do some development work in order for the user stories to even be able to work you know there's some system level non-functional requirements that need to be done and so there could be tech user stories and then can you see this low i can't see your chats but then there could also be defect user stories there could even be risk user stories now what could happen is that um the product owner ranks these in priority so this one first then that one then that one and the team says well the only thing is is that 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 back to the screen 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 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 um 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 estimating session here as a frequent traveler i want to eat grapes so i can be healthier in the one that we didn't do the inventory system as a customer okay there's 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 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 sales 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 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 so you have themes up at the top that's the biggest grouping if you will used primarily for you know high-level planning purposes so you have your themes then you have your epics which are large user stories 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 the product owner needed something done and the team said well based on the size of this user story it's going to take three sprints to do well a user story has to be small enough to be completed within a single sprint so a sprint can contain more than one user story but a user story cannot span sprints so that feature or function that was in the question was probably more like an epic it was something that would need to be disaggregated into smaller user stories or perhaps it was more of a use case that would need more than one user story in order to actually deliver the overall use case let's see as a product supervisor i want to see an unfinished part list at the end of the day so that i can reallocate work the next day great user story description well done viraj did you hear that team as a product supervisor i want to see an unfinished part list at the end of day so i can reallocate work the next day that is a well-crafted description of a user story now here are some things that i want you to memorize you were hoping i was done with the memorization part so i want you to um remember that we have to invest in our user stories and i was going over to the white board 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 well not if you wanted to what i recommend is being able to write out all of this stuff on plain white scrap paper in about 14 minutes because that's the amount of free time you have in the tutorial when you're at the uh or when you're taking the test um eggs in 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 exam 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 um 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 and that was because of some kind time constraints and it was the quickest way to get me into the test and so i didn't write out any of the stuff i'd memorized but i had it memorized and i had it memorized well enough that i could kind of recall it in my mind's eye okay so we're talking about user stories and you have to invest in your user stories you know i like memorizing things by creating these charts that have the first letter of the word or phrase that you're memorizing in a separate column and then i make up a story you know that reminds me that i've got to have inv esp this one is pretty easy probably just invest works but so let's go over that i stands for independent independent meaning that each user story stands on its own 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 if you developed a logon screen you could demonstrate working software for the login screen there might be another user story that is 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 v stands for valuable meaning each user story has to create value for the customer or the end user e has to be estimable as an estimatable except estimatable is not really a word it's estimable and s is for small has to be small enough to be done in a single sprint if we're doing two week sprints it 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's story needs to be testable and it needs to be testable at two levels remember our triangle needs to be testable at the intrinsic quality level unit tests etc and also testable at the extrinsic level which is the customer point of view which is acceptance so every user story uh has to be testable okay so that's invest and so let's add that to our list of things to memorize invest and then the next one we have here is um the three keys 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 the the second c is conversation the user story card is the item that is used for the team and the product owner to talk and discuss in order to make sure that the product owner and the team are on the same page when it comes to what is actually supposed to be developed and um uh what you know so what it's supposed to look like at the end which leads us to the third one which is confirmation each user story essentially has to have acceptance tests um in it itself so card 4x6 conversation that's the starting point that's where uh the team and the product owner discuss and then eventually there will be acceptance tests included on the user story card in order to be used during the sprint review to um assure that it's acceptable that there's confirmation okay so oh let's add that to the memorization so three c's all right now i've got an example here of a user story card so we're looking right here and if you were to go out on the internet and search um user story cards um they would be similar there would be some differences of course um but typically what you're going to have is you're going to have a title or a name for the user story and then there's going to be some kind of unique identifier like user story 321 then there will be the description like we just talked about as a librarian i want to have the facility of searching a book by different criteria so that i will save time while serving a customer then there might be some other descriptive words or links to other information that might be necessary and then there would be acceptance criteria or tests sometimes these get included on the back of the card but the point is is that they are on the chord 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 uh the differences um there's probably it's not listed here but there's probably going to be a value point assignment this is where the product owner um kind of determines in a relative way the uh value of the stories just like we were doing in planning poker the product owner might say well this story is twice as valuable as uh this other one comparing them together and this is what um these value points are what's used to 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 you know it's not me team it's the mouse clearly it's hard to uh do that that's from where from um here it's got uh customer tech you could also have defect you could maybe have risk and then there's also going to be an x factor um which would be some kind of word probably like um stable erratic 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 uh some efforts to actually figure out how to actually do that user story so that's the x factor um over to the right here on the same chart we have some comments about 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 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 overpays 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 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 app makes sense so just to kind of prompt you give you some ideas about what to do [Music] in a scrum project if you have the scenario arise where a user story is being estimated by the team and it won't fit into a sprint it's too big now when it comes to determining value for user 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 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 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 persuade the product owner to take care of high-risk stuff first because that would have a uh excuse me sorry an impact 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 you would see that um it just gets it to neutral that's what's expected for the product linear items 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 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 canon model and then there's wieger's relative weighting method and 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 if that feature or function is not included and then there is 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 um 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 priyanka that is exactly right so velocity is the capacity of the team to complete work in a single iteration so the team has estimated the user stories for size or ideal days and the sprints are going to be three week weeks in duration obviously not all user stories can be completed in a single sprint and be done with the project well i guess maybe i shouldn't say obviously while 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 five 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 outliers you you would disregard those and so it's an observation if we look over to question or box number two here velocity is used to deal with determining how many user stories we're going to include in a given sprint and also how many sprints are we going to need to create a release or a set of user stories and here's an example in box number three a team completed five user stories that were sized 5 3 8 thirteen and two two user stories each size 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 ten so you claim half of it which would be five would take you to thirty six 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 velocity you can mess around with your estimating and you can mess around with you know what user stories are going to be completed in a sprint but you don't 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 broadest area is the vision level so the vision level that's the suits right they're the ones that have the strategy and objectives for the company and where it's going and so they have that overall big vision for the 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 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 and then the sprints are populated by the individual user stories which are then just aggregated 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 roadmap concept here so let's just review this quickly um prioritize high-level epochs and determine goals and releases so we'll use epics and themes in order to group things together you know what should be included in what's released so what are the goals for the releases then the first bullet point established 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 an iteration length i should that's it's blending some things here 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 a sprint length and then figure out what our velocity for each sprint is and then uh assign stories to uh the sprints the the next bullet down iterate until the user stories and release date meets conditions of satisfaction so that's a definition of done or acceptance for the release and try not to pack too much into a release backlog so 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 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 horizontally and you probably plan um about three releases in advance 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 um release three and then you've got um you know your subsequent releases where we're just doing very high level planning it's called rolling wave planning where we do detailed planning for things in the future in canada with doing high level planning for things in uh the future did i say that right detail planning for things in the near term and tend 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 later releases 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 team come on you can do this the team's like no we know what our velocity is no the product owner says i'm telling you there's no way that that can't be done i know you can do it i trust you i believe in you but the product owner doesn't actually have to do the work okay copyright 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 there could be some information that is showing us that we're underestimating for example meaning um 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 a 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 planning poker you could see that 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 using estimation techniques scrum 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 their question here can velocity be increased over a period of time for the project yes it can now it's not that it can 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 sick the team just keeps chugging along um other things you know just um oh sorry there i bumped a thing on my screen there um um so the team you know learns how to work better together and you know their estimates become more accurate etcetera and you would expect a high for a high performing team to have a a result like this for velocity where there's quick improvement and then it kind of stabilizes and then begins to kick upwards okay we talked about the cone of uncertainty let's talk about ideal time when we do estimating for user stories 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 priyanka could sit down at 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 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 i should have circled this box here because we talked about this as well and then i already mentioned this here only considers actual work time not the distractions so that's the concept of ideal time when it comes to story points it's different than that they are a measure of size relative to each other so we were doing planning poker this morning where we were looking at grapes versus apples and then we were looking at oranges and and what else 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 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 um so you can do it like we did you can also triangulate um for example when we did our planning project this morning or this morning for me rather at the beginning um oh that's not it that is the daily 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 i'm sorry i'm saying that wrong grapes was small apples were medium and coconuts were large well if we then looked at orange and we said well you know orange is um smaller than apples but bigger than grapes so we would know this would fit in between grapes and apples 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 3. 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 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 eight 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 um 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 should some buffer time be included in the actual estimates um let me answer that question first by going back to ideal time and then i'm going to come back to story points and answer the question when we're estimating in ideal time we don't add a special amount of time that we would call a buffer we just allow for the distractions and the interruptions which could look like a buffer right you're saying you know um you know priyante if um based on your duties in the organization and our uh 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 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 things that impact it but that's the main thing sorry team so when the team is estimating the size of the user story they will be including in their discussion and estimates any extra time or buffer time that would be needed for 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 so that's the story points let's compare the two 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 story points um 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 so the suits have to be converted to 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 18 working together will have its own kind of 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 and the velocity of another is 50 it doesn't mean that the team with the velocity of 50 is able to do more work than the teams whose velocity is 25. and we did 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 the team discussed each of the story cards and then decided what their vote was going to be and then everybody voted at 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 and 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 and let's see affinity estimating we go through that we're going to talk about tracking progress using um information radiators and then we're going to talk about what we do when we find variances between the plan and the actual results and then we'll have our quiz now let's talk about the values of scrum now this is different than pillars this is values so there are five values for that and this is something that i want you to memorize i'm going to switch my cameras here and go to the whiteboard and we're going to add to our list oh wrong color you can tell i'm a project manager because that would bother me so the five values of scrum and there's an acronym you can see that on the screen right c-force okay so five values of scrum and c f o r c and you kind of know my style here you don't have to do it this way you know whatever works for you but have some kind of a strategy for memorizing things it will probably serve you well so the um the first c is commitment the next one there are four four f is focus o is openness set two ends or one i don't know openness we'll blame it on the marker if it's not right r is for respect and the last c is courage and so there's your little chart right there and let me just briefly go over these none of these will be a big surprise here we've talked about some of them already in one context or another so the for commitment that means the commit the team is going to commit to deliver value to the customer they're on board there's the buy-in all of that's there focus the team is going to focus on the few important things um at a time so we're going to do time boxing we're not going to do things broadly specifically focus on a few things at a time o is openness that's analogous to the t transparency and the pillars meaning we're going to be completely open in sharing information about the project our own opinions our fears our concerns etc r stands for respect and that's kind of a 360 view we respect ourselves we respect others we respect the uh concepts that we are using as part of scrum and um um and and we respect the other stakeholders as well 360. and the last c stands for courage and that's the courage to make commitments uh even when we're in an uncertain environment um courage to deal with fear that comes from a failure courage to share disagreements openly yet respectfully courage to participate in debating technical approaches etc okay so now let's go to the scrum lifecycle chart and what i want to do is i want to elaborate on this just a little bit and i'm going to try and use my mouse to do some some additions to this first of all we have the product backlog the product backlog has to be kept current and we call that grooming grooming is adding user stories and removing user stories from the product backlog product backlog is the scope of the project the product owner owns that the team assists in that effort related to grooming is pruning pruning the backlog is prioritizing and re-prioritizing so the product backlog is pruned and groomed regularly throughout the course of the project now there is a meeting that takes place right here which is called the sprint planning meeting can i just do psp here sprint planning meeting okay that is one of the ceremonies or events that takes place in scrum in the um the sprint planning meeting it is a time box event and it is time boxed to two hours for each week of the sprint so in our example here we have a 30-day sprint so if we have a four-week sprint then our sprint planning meeting will be eight hours in duration and two things happen during the sprint planning meeting the user stories that are going to be included in the sprint are selected right they're put into the sprint backlog which is a subset of the product backlog containing the user stories that are going to be completed during the sprint and the second thing that happens during the sprint planning meeting is the selected user stories are then disaggregated into tasks and estimated once that's done then the work of the sprint begins there will be a daily scrum like we did at the beginning of our work day together as our team and then at the end of the work of the sprint there will be the sprint review the sprint review meeting or ceremony is also time boxed and it is time boxed to one hour for each week of the sprint so for doing a four week sprint the sprint review meeting would be four hours in length the primary purpose of the review is to showcase and demo the software and get feedback from relevant stakeholders and allow the product owner to say i accept or i reject the work that has been done then after that is the sprint retrospective now this is where the team asks and answers three questions what went well what did not go well and what are we going to do different going forward regarding the previous sprint that was just completed and the ones that is is just coming up and then the uh the sprint itself will result in working software or value for the customer and then of course everything goes back and repeats for as many sprints as necessary to complete the scope of the project um let's see i see a chat here how similar or different is the product backlog to srs software requirement specs document which is widely used in projects um it's different and if you will hang on to that question we're going to have a discussion later on about user stories and that will help you understand uh the differences and we'll get into the user stories that come from the customer and user stories that come from the text domain and that will help answer your question so you okay hanging on to that okay great thanks okay so a little bit more detailed view of the scrum project life cycle now let's talk about a couple other things here when it comes to a sprint there are some things that affect the duration of the sprint so the team is going to have to decide how long each of the sprints are going to be and things that are a factor include the stability of the product backlog if the product backlog is changing a great deal then that's going to argue for shorter durations because there's a high level of uncertainty and so you have a greater amount of control on your project if you have shorter sprints now on the other hand another factor is the cost of iterating every time we do a sprint there are costs associated with the sprint planning meeting the sprint review the sprint retrospective right people show up to those meetings you gotta pay him and um excuse me so there there is an overhead cost to actually doing sprints the goal of the sprint is working software at the end the end product should be near releasable or potentially shippable now there might be working software that the product owner isn't going to want to release um maybe because it as a standalone component of working software for the system doesn't create any value or any usability for end users and maybe you wait till the end of a release before you release everything but the idea is it's working software and it could be released if um the customer wanted to do that um sorry just dropped something i see a question there i will circle back to your question in just a sec the sprint duration and deliverables do not change once the team has committed this is another one of those things that has to be viewed as absolute when we're doing scrum so if we say that we're going to do a two-week sprint and we select five user stories based on our velocity or capacity once that decision has been made the duration of the sprint does not change and we do not add or remove any user stories now it could be possible for the product owner to cancel a sprint but that would be extreme that would be because there is such a major change to the product backlog that the work of the current sprint is going to be completely irrelevant you don't change the sprint you cancel the sprint and then the bottom one here the sprint begins with planning and ends with review and a retrospective and there was a question here are there any issues with combining the retrospective and the planning ceremonies and the answer to that is yes now could they be combined depending on the environment the answer is yes and the way we would arrive at whether or not it would make sense is who's going to be participating but they would be separate agendas so the agenda for the retrospective is what went well what did not go well what are we going to do different and the mandatory participants for that meeting are the the team the scrum team is the scrum master going to be there likely as a facilitator um is the product owner going to be there maybe maybe not if the product owner is there you know the product owner could maybe answer questions and help clarify but the product owner does not weigh in on what went well what did not go well and what are we going to do differently that is all owned by the team in the planning meeting the product owner has to be there and the product owner is the main driver of that meeting the product owner is talking about or dealing with the priority of the user stories the team's weighing in maybe there's some dependencies that need to be considered but the product owner has to make the hard decisions with regards to what's going to be done in the next sprint based on the constraints from the team like velocity and technology and sequencing and things like that so um i kind of answered that from a real world point of view yes it could be it's not desirable on the test they are completely separate did i get you there i keep my eye on the chat box make sure i got that answered well enough for you and let's move ahead okay the sprint planning meeting this is looking right down here this is conducted at the beginning of a new sprint it's attended by the team the product owner and the scrum master and there are two approaches to deciding what's going to be included in the sprint it can be based on commitment and it can also be based on velocity and the goal here is to get team buy-in make sure that there is clarity between the team and the product owner as to what the definition of done looks like for the user stories that are going to be included in the sprint and um of course it should be realistic and achievable and you know there can be a little bit of of um an issue where you've got you know a well-meaning product owner that's driving really hard and the team says you know we can do these sprints and the products owners saying no come on you got to do at least one more i got to have this one in this sprint you could get a question like that and it might be what would the scrum master do if you had a dominant product owner that's trying to persuade the team to do more than the team thinks it can do and that's where the scrum master comes in the scrum master plays the role of the mentor the coach and you know assisting in the resolution of those kind of issues without deciding the scrum master is not a decider the team decides uh when it comes to how and the product owner decides when it comes to what okay the scrum meeting daily scrum we've talked about it right the entire team attends the meeting could the product owner be there yes does the product owner need to be there no sometimes the product owner can be uh you know an impediment to the meeting but would be welcome but if the product owner started asking questions or became the focus of questions being asked the scrum master would have to help facilitate a change because that would not be effective for the daily scrum duration 15 minutes we talked about that and the agenda what did i do yesterday what am i going to do today and what are my impediments the sprint review now who attends it's going to be the team the product owner the scrum master and potentially others so optionally others you know that we would want to get feedback from would be end users operations folks pursuits all of those would be welcome depending on the relevance of the software that's being demoed and being subject to the acceptance testing and the product owner you know giving the thumbs up or the thumbs down when it comes to acceptance the duration for this we mentioned this before it's not just a flat two hours it's one hour per week so if you did a four week sprint you would plan on the review being a maximum of four hours in duration the agenda is to demo the completed software get feedback and then see where we are when it comes to the the release plan the retrospective who is there it's attended by the team and i would modify this slightly and i would say this is the the mandatory group that needs to be there optionally the scrum master would be there potentially you could have an external facilitator the role of the scrum master would be the facilitator now a good scrub master being a facilitator in a retrospective would have some knowledge of control charts the five why's um ishikawa diagrams things like that and although the scrum master would not be participating in the actual use of the tools the scrum master would be facilitating the effective use of those tools when it comes to duration the rule is 45 minutes for each week ooh that was a good four that was kind of a lousy five so if you had a two week um uh sprint then you would have an hour and a half retrospective max and what's the purpose there's the agenda for the retrospective three questions what worked well what did not go well what are we going to do different and it's not just a chat session well that would be part of it you will use tools and techniques like some that i mentioned control charts ishikawa diagrams um five why's there's a number of things that you might use uh in order to surface uh assignable causes for issues so that we could then come up with a resolution to those this is where continuous improvement is going to happen you know continuous improvements the result of other things but this is the main thing and if you read a question about the relevance or the necessity of retrospectives there is no equivocation you do a retrospective after every sprint um if you don't do a retro um if you don't then um there's no improvement um you know things just stay static okay so we talked about the four main ceremonies right in a scrum project sprint planning you with me daily stand up the sprint review and then the sprint retrospective all considered mandatory for effectively doing scrum and not doing them or one of them would be considered a sale okay artifacts that we use when it comes to scrum we've talked about the product backlog we talked about the sprint backlog there's also a release backlog depending on the size of the project it might be advisable to group user stories into releases if you have a product roadmap your releases would line up for that for example i've got a a real life project that i'm working on and my product roadmap is got three versions it's a website the first version is free the second version includes a membership component and the third version includes a referral commission portion to it and so i will then do three releases i'll have all the user stories that were resolved in version one all over the user stories that really result in version two so that's what the release backlog is and so if you look at it in sequence the product backlog is the overall scope of the project the release backlog is a subset of the product backlog and then the sprint backlog would be a subset of the release backlog the product backlog might look something like this it's a list of user stories that are written by the product owner and are going to be developed by the team members and didn't we have we had a product backlog for the thing that we did this morning right so here's another example of a product backlog this is more of a list it just has the title there would be a user story card for each of the items in the product backlog but the idea would be it would be prioritized there could be user stories that are added or removed depending on what the product owner wants product owner owns the product backlog that's a given does the product owner create all the user stories for the product backlog in isolation no absolutely not because there are technical considerations that the product back or the product owner might not even consider the product owner's perspective is more the customer side the end user side and so the product owner might not even think of things like security or architecture related things and there might even be user stories that come from the technical domain that need to be developed before some of the products owners user stories another artifact is the definition of done the definition of done is primarily a checklist and this is what forms the agreement between the product owner and the team as to when we consider something completely done and if we look down here it's um where's my i'm looking for my cursor it says here it's usually prepared by the scrum master in consultation with the team that is i would modify this slightly the definition of done is really driven by the team the see the scrum master is never a decision maker if you have a scrum master that's saying we have to have this in the definition of done then that's an infringement on the empowerment of the team i agree that the scrum master is a part of the effort to develop the definition of done um but i would kind of flip that uh the scrub master's the facilitator it's the team that still um owns that so um now is the product owner involved in this absolutely because the product owner is involved in defining the story and what a fully implemented story looks like so here's a list a short list of what a definition of done could look like the story has been fully implemented or the code completed as described automated unit tests have been developed with at least 80 percent code coverage it could be more than that this is just an example automated unit tests and acceptance tests of the story are passing no severity has one or two defects and then high priority test cases have been automated and added to the regression suite the definition of done we point out is likely to evolve as the team's maturity increases as the project advances there are three distinct roles in scrum the scrum master the product owner and the development team the scrum master assists both the development team and the product owner the scrum master works with the product owner to maximize return on investment the scrum master empowers the development team by fostering creativity removing impediments and coaching and mentoring as appropriate the product owner is responsible for project success by defining the project vision requirements and priorities the product owner has to resist the temptation to manage the team or add more important work after a sprint has begun the product owner has to be willing to make the hard choices during sprint planning the development team is comprised of five to nine members with a mix of roles and has the autonomy to self-organize and choose how best to meet the goals of the product owner and is responsible for the same a scrum master is a skilled servant leader a scrum master has very little formal authority however he or she is expected to assist the team achieve the intended outcomes without interfering with the team's autonomy the scrum master facilitates the scrum ceremony such as sprint planning daily stand up sprint review and sprint retrospective the scrum master removes obstacles or impediments faced by the team the scrum master is also a process coach and mentor the scrum master must not be a line manager of the team the scrum master is not to be a task master either the scrum master is not a technical or design authority nor is he or she a decision maker for the team throughout the course of the project the scrum master must not do anything to rob the team of its empowerment and ability to self-organize let's talk about the attributes of a scrum master scrum masters need to exhibit responsibility even though they are not solely accountable for the team's output they will consider it their responsibility to remove anything that impacts the team's productivity they will try to enable the team to do the best that it can they are humble they will work in the background and let the team take all the glory they will use we statements and seldom use any i statements they are able to set aside their ego and shower all their attention on the team they are by nature collaborative they will encourage the team to have conversations among each other and with other stakeholders outside the team they will nudge all the right people into getting involved and work together and trying to solve problems they are committed to the team cause even if being a scrum master is a part-time task for them they will give the highest priority to the team's needs hence the scrum master's work allocation especially if they are part-time needs to take this into consideration they're able to influence they are naturally good communicators and able to convince others to adopt different approaches they apply various techniques to mobilize organizational resources when required walk the political tightrope when required and in general do whatever it takes to get the team the assistance it needs they are knowledgeable it is clear that as process coaches for the team scrum masters need to be experts in the method they may not be the technical or domain experts however they are knowledgeable enough to be able to have productive conversations about the project being done by the team tasks for the scrum master the scrum master is a crucial role and it is important for you to be able to be clear about exactly how the scrum master serves the team scrum masters are servant leaders this means that they put the team before themselves and assist the team for example they set up ensure that the scrum ceremonies are effectively carried out they ensure that there is smooth flow of information within and outside the team and that there is a spirit of collaboration in decision making and problem solving scrum masters must make it their mission to resolve issues that hinder team progress it doesn't matter what the nature of the issue is a scrum master needs to mobilize the right resources within the organization to resolve those issues in a timely manner and escalate promptly if that does not happen we need to understand that in the short duration of a sprint even a few hours of being stuck can make the difference between a successful and unsuccessful sprint scrum masters protect the team they ensure that the team is not disturbed or asked to deviate from their commitments if pressure mounts due to unreasonable expectations they will step in and push back on the team's behalf they will also play the role of peacemaker when conflict arises by encouraging the parties to focus on the issue discuss the issue with an open mind and resolve the conflict finally scrum masters are the process coaches of the team they use their understanding of agile methods and scrum in particular to guide the team through the do's and don'ts of scrum they ensure that the team stays true to the principles of agile development scrum master roles scrum teams before we discuss the role of a developer on a scrum team let's talk about the desirable characteristics of scrum teams they should be small and nimble team size should be no less than three and no more than nine so that would be six plus or minus three exceptions are possible but uncommon the small attribute makes the team nimble and improves productivity it avoids the phenomenon mike cohn calls social loafing and instead produces focus on work the team size should be just large enough that the team members are able to produce and showcase a significant increment of work at the end of each sprint sprint after sprint self-sufficient and cross-functional for example if a team needs user interface development skills database expertise and service expertise all of those skills must be present on the team ideally team members are generalizing specialists team members should not only be an expert or a specialist at one aspect of the development effort but should also have enough skills and knowledge to fill in in other roles as necessary for example if you are a ui developer you should be able to don the hat of a services developer if needed if a large team is to be split up into smaller scrum teams scrum favors feature teams over component teams autonomous and self-organizing teams choose for themselves how they are going to organize and meet the goals of the product owner no one gets to dictate to the team how to get their work done the team decides in collaboration with the product owner the project direction and the pros and cons of different approaches let's talk about some key decision points or factors to consider when assembling scrum teams feature teams over component teams the first issue is whether it's best to align team members based on features or components scrum favors feature teams over component teams for example it's best to avoid putting all of the ui developers together and all of the api or services developers together why because each feature or user story will require both the ui and services or api organizing based on components will reduce the incentive to collaborate the only reason component teams may be justified would be if the components are likely to be used by multiple other teams assemble the right people it's important to get the right mix of people together for the team the right level of technical and domain expertise teams will naturally have both senior and junior level developers this works perfectly as there will be stuff that is more appropriate for the junior developers and stuff that is not also one of the risks of a small team is that the team may miss out on broader perspective and dissenting views one way to work around this is to deliberately favor diversity in all aspects gender ethnicity personality traits etc it may take some time for the team to advance through the storming stage of team development and develop the trust necessary to work effectively together but it can be done once a team has been formed it's best to preserve and assign whole teams rather than individuals to projects it's best to avoid assigning team members to multiple projects at the same time distributed team a distributed team may be unavoidable those based at the same geographical location should be co-located in the same team room and technology processes and ground rules should be put in place to overcome the disadvantages of all team members not being co-located plotting team size and productivity will likely result in an s-curve you can see here that a team can actually be too small or too large remember the sweet spot is six plus or minus three think of scrum as a lightweight framework that utilizes principles and practices that assist teams in delivering working software in short cycles to the customer enabling rapid feedback continuous improvement and quick response to change it promotes delivering value as in working software to the customer in an incremental and iterative way it is not a process or technique for developing software rather it is a framework within which various processes techniques and practices are employed in scrum the iterations that deliver working software to the customer are called sprints in each iteration or sprint results in potentially shippable software this slide is a graphical representation of an agile project using scrum starting at the left you can see that the product owner owns the product backlog and in collaboration with the team develops the user stories or requirements for the project the product backlog is prioritized with the higher priority items occupying the top of the product backlog in collaboration with the product owner the team decides how to group the user stories into releases based on the product roadmap once the release planning has been completed the user stories are then selected for a sprint the duration of the sprint is going to be two to four weeks once the sprint backlog has been determined the team then disaggregates each user story into tasks during each sprint the user stories are developed as the 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 to the customer for acceptance the team then conducts a sprint retrospective during the retrospective the team looks at primarily three things what went well what did not go well and what should be done differently going forward the team's velocity is then updated as are the information radiators which transparently display the status and progress of the project and then the cycle repeats itself until the project is complete a sprint is an iteration in scrum at the beginning of a project the scrum team determines the duration of sprints for the project most sprints are going to be two to four weeks in duration factors affecting sprint duration include the stability of the product backlog once a sprint has begun the duration is never changed nor are any user stories added or removed therefore if many changes are expected a shorter sprint duration would be best however if the product backlog is relatively stable a longer sprint duration may be appropriate overhead there are overhead costs associated with each sprint for example every spin is going to have a sprint planning meeting a sprint review and a sprint retrospective if a team has been able to lower these overhead costs by automated testing continuous integration etc these costs can be absorbed more easily making shorter sprints more desirable however if these overhead costs remain high the team may need to use longer duration sprints a team may be tempted to extend the duration of sprints in an effort to hide their inefficiencies remember agile projects favor shorter duration sprints and it is the scrum master's responsibility to coach and mentor the team so it can reduce waste irregularities and overuse and make the sprint shorter the goal of a sprint is to deliver working software at the conclusion of each sprint the team should be able to deliver near releasable or potentially shippable software this is not easy especially for an existing product with a lot of legacy features but it can be done with the right technical practices and mature development processes once the sprint duration has been determined and the user stories for the sprint have been selected the duration of the sprint cannot be altered nor can any user stories be added or removed the sprint will end at the appointed time irrespective of whether the team has met the sprint goals or not this allows for effective continuous improvement if the team is unable to deliver the working software as planned the team will have to figure out why that happened and then make changes to improve going forward the product owner may choose to cancel or terminate a sprint in specific situations for example a significant change in priorities or a mid-course correction may render the current sprint backlog invalid given that we are only talking about a couple of weeks of work the cancellation of a sprint would be an extremely rare event a sprint will begin with a sprint planning meeting and end with a sprint review in retrospective there are three backlogs used in scrum the product backlog the release backlog and the sprint backlog the product backlog is the master container of all the user stories for the project the product backlog is continually pruned or prioritized so that maximum value is delivered to the customer the release backlog is a subset of the product backlog releases support the product roadmap and each release is populated with user stories necessary for that release the sprint backlog is a subset of the release backlog and contains the user stories to be developed in the sprint as we said the product backlog contains the user stories for the entire project and it is the responsibility of the product owner user stories are features functions or requirements that deliver value to the customer however the product backlog will also have to contain technical or non-functional user stories necessary for the system to work properly the product backlog may also include risk or defect related user stories the product owner is responsible for keeping the product backlog current and up to date this is accomplished by pruning the backlog which is prioritizing and re-prioritizing the product backlog must also be continually groomed this is the process of adding and removing user stories based on the needs and desires of the customer there are four scrum ceremonies the sprint planning meeting the daily scrum the sprint review and the sprint retrospective let's take a detailed look at each of these ceremonies the sprint planning meeting is time boxed at two hours for each week of the sprint if the sprint is going to be two weeks in duration then the time box will be four hours if the sprint is going to be four weeks in duration then the time box for the sprint planning meeting will be eight hours it should be attended by the complete scrum team including all roles the most important aspects of this meeting are the team's capacity and the definition of done there are two approaches to selecting user stories for a sprint one is based on the velocity of the team the other is commitment driven team buy-in is critical and the goals of the sprint should be clearly understood and the desired outcome should be clearly articulated with the definition of done then there's the daily scrum the time box for the daily scrum is 15 minutes regardless of the duration of the sprint length the entire scrum team including all roles should attend the daily scrum each development team member individually answers three questions what did i do yesterday what am i going to do today and what are my impediments this is how the team members coordinate their work and the scrum master learns of the impediments he or she should be taking care of the sprint review takes place at the end of the sprint and is time boxed at one hour for each week of the sprint so if the sprint were four weeks in duration the sprint review meeting would be four hours it should be attended by the complete scrum team including all roles plus any other stakeholders who are interested in project success the purpose of the review is to demonstrate working software and obtain and assess feedback feedback may range from full acceptance of the completed software to complete rejection the sprint retrospective takes place after the conclusion of the sprint review and is time boxed at 45 minutes for each week of the sprint so if the sprint has two weeks in duration then the retrospective would be one and a half hours in length it should be attended by the complete scrum team including all roles however the product owner's attendance is considered optional during the retrospective the team answers four questions what worked well what did not work well what should be done differently and what still puzzles us one or several problem detection techniques may be used in the retrospectives and this ceremony is a vital part of continuous improvement at the conclusion of the retrospective the teams velocity and the project's information radiators are updated then the next sprint's planning meeting takes place and this cycle continues until the project is complete the definition of done is an important artifact for a scrum team it is the primary reporting mechanism for team members and there may be a different definition of done at various levels definition of done for a feature or user story the definition of done for a sprint and the definition of done for a release it's really just a checklist of activities that add verifiable and demonstrable value to the product it's created by the scrum master in consultation with the team a sample list of the items for the definition of done criteria is given here the story is fully implemented or code completed as described automated unit tests have been developed with at least 80 percent code coverage automated unit tests and acceptance tests in the story are passing high priority test cases have been automated and added to the regression suite note this is only meant to be an example each team's definition of done will vary slightly depending on the maturity of the team and the specific situation of the team the product team has taken up a new project called weather master the team is planning to move to scrum methodology and this is an outline of its first scrum meeting time box to 15 minutes rick is the scrum master of this meeting where the team members discuss what they did yesterday their plans for today and the impediments they faced all team members are standing up including todd who's joined the meeting via video chat rick holds the meeting near a scrum board angela the product owner is absent rick reiterates that all discussions would be parked until after the scrum meeting and encourages this team to keep the meeting short people can chime in to resolve obstacles hi team welcome to the daily stand-up meeting for the product team on project weather master we are in sprint one and today is the second day as we are planning to transition to scrum methodology i hope you will find this daily stand-up meeting helpful in this meeting you will provide information about what you did yesterday what you plan to do today and what challenges you faced i think everyone's here let's start i don't see angela shouldn't she be here i did add angela as an optional attendee to this meeting and since she hasn't showed up we don't have to wait for her susan scrum doesn't provide a specific yes or no about the product owner's participation in the daily scrum the po's primary role is to provide direction and clarify requirements and priorities since we don't always discuss those in detail at this meeting the po is not required to be here if the pos want to attend they are generally in listen-only mode for the duration of the meeting they can use the information gathered during the meeting for separate offline conversations [Music] [Music] what about todd he works from his home office right todd will be a part of the meeting through video chat it is important that we include every team member in the meeting hi todd how are you i'm fine thanks am i audible yes todd team let's all stand up for the meeting [Music] [Music] why don't you go first erin yesterday i was working on creating the mock objects to mask the database calls from the unit tests the difficulty with this approach is that our server side logic is so dependent on the metadata that writing a true mock is a mammoth exercise there are decisions that are taken during runtime based on the data some of the stored procedure calls are also made based on the values returned through inline queries that are also embedded in the code i was debugging the code until about 9 pm but for the life of me i couldn't figure this out aaron could we request you to be concise when you provide an update if you think some of the details you described might be interesting to others why don't you write a wiki page on it and share the link so getting back to your update did you finish the task yesterday no it turned out to be much more complex than i had imagined i'll continue to work on it today and see if i can figure out an xml structure to mock the schema and hard code some return values but i am really stuck as far as the inline queries are concerned i know what you're talking about there is a reason why the inline queries are there in the code this is mainly for performance reasons when the overheads of making a procedure call based on a metadata value and then processing them sorry for the interruption again guys this is a really great conversation may i suggest we write this issue in the parking lot i'm not sure what you mean by that rick let me explain what aaron just brought up is a blocking issue team members should bring these up during the daily scrum so that everybody knows that one of the team members is stuck however the daily scrum is not necessarily the meeting where solutions to every obstacle can or should be found it looks like mary knows a thing or two about the issue that erin has brought up let's jot this down as a parking lot topic this means the team can have offline conversations after the daily scrum to track it down i'm also going to make a note that will track the impediment aaron faced daily until it is removed you should let me know if i can help in any way right aaron is there anything else you would like to say no i am done thanks yesterday i worked on developing the wizards for bulk order creation i'm almost done today i need to write code to handle some of the exception scenarios before i can get them over to susan for testing that's it for me i guess did you forget to mention any impediments not really an impediment at present but i would like to mention that my computer probably needs to be upgraded with more ram it has been slow for the past few weeks okay i wrote up some scenarios to test the bulk order wizard i'm looking to get my hands on the code as soon as mary is done today i'm also hoping to complete the company order testing that has been pending for a while i'm okay for the moment but i do have one question shouldn't we all be updating the task board as we speak we could it is up to you guys if you think you want to do this during the meeting if you ask my opinion we should update the board as soon as we are ready to move the tasks and not wait for the meeting this will ensure that the board is always up to date and also that we use the meeting time to focus on the conversations that's a great point rick i can't see the board very well from here anyway so maybe we should find a way to create an electronic version of it too at some point great point todd why don't you go next with your updates all right hey rick would you like to know about my work on the advertising module first or the integration server whatever the team decides is fine with me remember this is really your meeting and i'm only here to facilitate and ensure we get the most out of this meeting [Music] [Music] all right then i guess i'll start with the integration server i would like to inform everybody that i managed to set up the integration server that we can use as a sandbox to test the code before checking it in source control i'll send everybody a link with some instructions and credentials i have also started looking at the stories for the advertising module it looks like there are a lot of open statements in the stories that i don't really understand i guess i should have been paying more attention during the sprint planning i really need to have a conversation with angela about this that is my main impediment right now i sent her an email but haven't received a response yet i don't have anything new to add today i'm almost through with setting up our project on the freeware tool that i downloaded yesterday i'll show you guys a demo in the meeting i set up later today i'll try to chase down some of these parking lot items anything else before we close the meeting all right that's it for today have a great day do you have a moment to chat about the inline queries real quick the purpose of a scrum meeting is to keep the team members updated and resolve any impediments it's an ideal way to kick-start the day on a positive note the scrum master reinforces the sense of the self-managing team facilitates communication between team members brings the team's focus back to what's important and supports improvement so before we dive into the differences between scrum and kanban let's have a look at what exactly scrum is scrum is a simple agile project management framework that is used by organizations to help teams collaborate handle unpredictability and complex projects or products while ensuring the products delivered are of the highest value it describes a set of meetings tools and roles that enable teams to work in sync and help them structure themselves and manage their work scrum is one of those things that's really easy to understand but very difficult to master and although scrum is seen to be used generally by software development teams its principles and themes are pretty universal and can be used with just about all kinds of teamwork with scrum teams are able to learn from their experiences what worked out what didn't and things like that they're also able to organize themselves to handle their problems effectively and basically improve themselves by reflecting on them so how does scrum work here we have the first component the product backlog the product backlog consists of a list of tasks that need to be completed so that the goals of the stakeholders are achieved then the team decides what tasks from the product backlog they want to take up and deliver in a two to four week period called sprint hence the name sprint planning next the tasks that were discussed in the previous phase are added to the sprint backlog this is a set of tasks which will be focused on in the ongoing sprint following this the scrum team which is usually 5 to 9 members strong will work on these tasks now they also have regular scrum meetings where they talk about their victories the issues they face and what they plan to do in the next 24 hours and then they have the sprint review the sprint review is a meeting during which the team shows what they accomplished during the sprint now during this time questions are asked observations feedback and suggestions are made the product owner also gets feedback for upcoming sprints from stakeholders they also have a sprint retrospective now during this session past mistakes potential issues and new ways to handle them are identified data from here is incorporated into the new sprint plan the final step is increment here a workable and usable output is provided to the stakeholders so now that we know how scrum works let's have a look at kanban kanban comes from the japanese word kanbam 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 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 teams 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 the products are only built based on demand rather than forecasts transparency plays a major role in both these frameworks by helping them drive process improvement and in both cases the release plan is continuously optimized and finally both these methods 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 event driven the next criteria we're going to have a look at is release methodology in scrum releases take place after each sprint which usually takes two to four weeks to complete for kanban releases take place in the form of continuous delivery they happen in such a way that changes like new features configuration changes bug fixes and experiments get to the users in a safe quick and sustainable manner next up let's have a look at how changes are addressed in both these frameworks in scrum no change can be made while the sprint is in progress once it'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 themes that focus on particular aspects of the workflow are required now let's talk about new additions inscrum 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 scrum team 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 link 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 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 on 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 if getting your learning started is half the battle what if you could do that for free visit scale up by simply learn click on the link in the description to know more so as part of this tutorial we are going to understand the typical interview questions which would come across when someone faces the interview for any of the roles in the scrum so question number one what is chrom so scrum is a framework that enables team to work together so with scrum teams can learn from experiences self-organize working on problems to reflect on their victories and their losses to improve so this is a simple framework which will provide a better ability and methodology one can able to handle it better so scrum is very well defined articulated and this provides a better insights and capabilities building access is very easier and roles are well defined so define the roles in scrum so what are the typical roles we come across in scrum so one of the roles we come across is product owner so product owner is primarily responsible for maximizing the roi by determining the product features prioritizing it into a list what needs to be focused on for the next print and constantly reprioritizing and refining it so what happens is whenever we may require to deliver it is very important for us to have the requirements clear what requirements needs to be fulfilled to fulfill the requirements the products what is produced should have specific features and functionalities so product owner will have the list of features and functionalities which needs to be created when product comes out as a result of a project so product owner owns this primary responsible to ensure these list of features are identified and those are prioritized as required so next role we can think of a scrum master who helps teams learn and apply scrum to obtain business value so scrum master helps removing impediments impediment is anything which can stop things to flow smoothly so protects them from interface and helps the team to adopt agile practices now scrum is one of the methodologies for agile approaches and practices now remember the term agile itself is not a practice it it refers to indicate that move faster become flexible respond to change be flexible now scrum methodology especially scrum master should understand this dynamics and ensure the team understands this and scrum master should guide the team to adopt these methodologies and ensure the results are accomplished accordingly so next role is scrum team so scrum team is a group of individuals who work together to deliver the requirements of the stakeholders so scrum team is generally of the size like five plus or minus two who are self organizing so various different capabilities the scrum team members would have so each of their capabilities complement to accomplish the results required so question number three what are the responsibilities of this chrome team so scrum team is self-organizing as i mentioned earlier so it is a self-organizing team that has five to seven members and the responsibilities would include the development and delivery of working products during each sprint now we are seeing the new terminology sprint so what is the meaning of this print now sprint refers to an iteration a time-boxed iteration which will have a specific deliverables to be accomplished as part of it so self-organizing team takes that specific working piece what needs to be delivered so that is a sprint backlog we call it s so from the product backlog the features functionalities which needs to be delivered as part of this specific iteration called sprint time box iteration and those sprint backlog items are delivered the output of the sprint would be the features what is being taken as a working piece working product so to demonstrate ownership and transparency for work assigned to them so they own it the entire thing assigned to them there is there should be ownership so ensuring the success of daily scrum meeting by providing crisp and correct information so scrum has one event there are five events basically so one of the events which happens daily is daily scrum meeting where the team comes with scrum master so they would speak about what is that they have accomplished from the previous stand up to till now is there anything which is stopping them to move forward so giving the crisp updates specific summary updates so that scrum master understands the status so any specific uh changes or any specific support which are required scrum master would discuss separately with those individuals and get it done so it should be minimum 15 minutes meeting when we say daily stand-up meeting so scrum team collaborate with each of the team members they work together and they self-organize so next question differentiate between a jail and scrum now it is very essential to understand the terminology's differences so if we just end up with looking at a wrong understanding of each of the terminologies then explaining will become difficult so what does it mean by agile and what it is when it comes to the terminology called scrum the term agile refers to ability to move quickly and easily by becoming more flexible and adaptable this is what the meaning which gets associated with the term agile so many times i have seen people answering agile is a methodology edger is a iterative and increment methodology and also i think when you search through the popular search engines you may come across that which is wrong so agile is the terminology which is used to state to move quickly and easily by becoming more flexible and adaptable this we should keep in mind so if the question may be like what are agile methodologies then you can come across like one of the agile methodologies scrum and you can go on on various different methodologies what we have so scrum is an agile methodology right the term scrum is the name given to the agile material methodology which enables organization to become a child right so to become agile obviously there are various methodologies scrum is very popular so that is the main difference so further if you look at agile manifesto on 12 principles which acts as guidelines to become a child so there is something called agile manifesto four points clearly articulates what needs to be focused on to become a child and that support that is supported through the 12 principles which guides so scrum is used in projects where requirements are constantly changing means i want to become agent so i adopt scrum so this definitely has to align to agile manifesto and take the guidelines whatever is mentioned in 12 principles of agile manifesto then looking at leadership perspective roles perspective so manifesto mentions the required collaboration interactions to become a child whereas crumb defines the roles like the scrum master the product owner the self-organizing teams which is cross-functional self-organizing team so these are the main three roles which scrum defines now generally when we say projects we come across the role like project manager so do we see uh such project managers in scrum answer is no because the scrum master who engages with team regularly more than management they focus on doing facilitating role to the scrum teams so that things can be delivered the way it is required and more flexibility is given to the team to take the calls to accomplish the results so scrum master facilitates whereas the product owner as i mentioned earlier looks at the product backlog and prioritizes and provides what are the features functionalities needs to be created in the next iterations so speaking about flexibility definitely agile manifesto mentions the required focus on working software and focusing on changes so that that's the focus the direction what it provides so scrum approaches enables teams to react to changes quickly the scrum methodology is made such a way the team understanding that can able to react and those changes and modifications are made visible to the team so delivery perspective manifesto provides necessary guidelines on frequent delivery of product or software so scrum with time-boxed iterations called sprints builds delivers to the users regularly and half-held agile principles that is very important so delivery here is as per the user's requirement as per the customer requirements because customer when we want to become a child customer has to involve very closely stakeholder has to collaborate without that you cannot become a jack so next point is about collaboration agile manifesto stresses on individual interactions and customer collaborations so based on this if you look at in the scrum how are they demonstrating this so there are various events which happens in scrum so as i mentioned earlier we have daily stand-up meetings and other scrum events like sprinters retrospective sprint reviews daily stand-up meetings which happens like sprint planning which happens regularly so it it becomes a reason for collaboration and everyone to discuss and take the call so question number five what are the main artifacts of this chrome process now product backlog so which consists of list of new features changes which are looking organization is looking for to bring into the existing features changes to the existing features bug fixes changes to the infrastructure and several other activities to ensure a particular outcome so product backlog so then we can speak about sprint backlog a subset of product backlog so the sprint backlog contains tasks that the team aims to complete to satisfy the sprint's goals so set off product backlog things are taken put into spin backlog and those are the features which are supposed to be produced as a result as part of that particular sprint the team first identifies tasks from the product backlog that need to be delivered to achieve a goal so these tasks are then added to the sprint backlog so the team first identifies tasks from product backlog as per the priorities the list which is prioritized in the product backlog that is taken put into sprint backlog and then those are delivered so next you can think about product increment the product increment is the combination of all product backlog tasks compared in the sprint and the value of the increments of previous sprints the outcome should be in the usable condition even if the product owner doesn't decide to release it it is very important each of the increments which comes out so needs to fulfill this now question number six how are the product and sprint backlog different from one another product backlog versus sprint backlog let us see a few differences so product backlog is the list of items that needs to be completed for developing the product which is the list of all the features functionality consolidated one whereas print backlog is the list of items to be completed during each sprint which are taken from product backlog the backlog when it comes to product backlog the backlog is collected from the customer by product owner and assigned to the team whereas in sprint backlog the teams collects the backlog from the product owner and sets up the time frame for the sprint so product backlog is specific to end goal ultimate objective whereas print backlog is spread specific to that sprint specific iteration called sprint instagram what is that we are going to produce as part of it product backlog is based on customer vision whereas print backlog will vary based on the product vision defined by product owner so prior test list you take from the product backlog so product backlog is independent of sprint backlog whereas sprint backlog is dependent on product backlog reason you we know already i explained so this this is the prioritized list of backlogs we take from product backlog and create this uh per specific product as part of sprint which become sprint backdrop so product backlog refers to until the project is complete the product owner maintains the product backlog for a sprint backlog when it comes to sprint backlog each news prints as backlogs added by the team as each sprints are initiated so next question who is the scrum master and what does he or she do so a scrum master promotes and supports the adoption of scrum in the team scrum master helps everyone to understand the theory practices rules and values in the scrum so scrum master is playing the role of facilitation enablement right so scum master ensures the team follows chrome values principles and practices removes blockages that may hamper the progress of the project protects the team from being distracted ensuring the team delivers value during every sprint so next question what happens in daily stand-up sessions so daily stand-up sessions are the discussion which are done daily that takes place under usually 15 minutes in duration the objective is to understand what went well what tasks are completed from the last stand-up session what tasks are pending and the obstacles the team was facing if at all any uh specific task is not accomplished for certain reasons so what are stopping them stopping the team to accomplish that that needs to be made visible so that separate meeting can be held to discuss on that and do the necessary corrections by taking proper actions so the objective of this daily stand-up meeting is to understand the overall scope and status of the project further individual discussion can be taken up after the daily stand-up sessions as i mentioned earlier if at all if you find something is not accomplished as per the plan now how do we ensure that is corrected and why is it happening is there anything any support is required by the team to focus on that so something like that can be checked out question number nine what is scrum ban so scrum ban is a development methodology that is a combination of scrum and kanban so this can be used to meet the needs of the team that aims to minimize the batching of work and to adopt a pull based system so kanban is called as pull-based system so which actually helps in terms of visualizing what work is in progress and since it is a visualized visualized system it is visible to everyone so it works in terms of making people become conscious to take that work and get it closed quickly so it's also called pull system because work is pulled from that particular list so when this kanban approach or methodology or thought is applied in scrum we call it as crumb so combination of this definitely helps in terms of making that entire journey successful and supports the scrum methodology so scrumbar includes the structure of scrum along with the flexibility and visualization of kanban so scrumbar is used by the teams that need to be structure of scrum that has the structure of scrum and the flexibility of a flow based method like on1 so question number 10 what is sprint 0 and spike so the term sprint 0 refers to the short amount of effort put for creation of vision a rough skeleton of the product backlog so now we do this whenever we need to understand certain things how things looks like to get certain insights so this also includes insight towards estimating the release of products so you get some vision it gives some clarity right so this sprint zero are required to create project skeleton alongside research spikes keeping minimal design develop a small number of stories completely have low velocity and be lightweight so speaking about this spike so spike is set off activities used in extreme programming i think this was introduced there in extreme programming that is of one of the agile methodologies so involving research design investigation making proof of concepts etc so the objective of spike is to reduce the risk of technical approach by gaining knowledge which helps understanding requirements and to improve reliability so more aware we are more clarity we have i think putting step further will become easier so informed decisions you can take so next question what is crumb of scrums now scrum of scrums is a terminology used for scaled agile techniques which is required to control and collaborate with multiple scrum teams so when will we come across the need for collaborating between multiple scrum teams so these are the scenarios where organization has a complex structure complex in nature where you may require to handle them together all of them uh together for accomplishing the common objective for business various crime teams you would have so scrum of scrum helps in terms of better collaboration and handle them easily or better way better control it is best used in the situations where teams are working together on complex assignments just visualizing the system various different deliverables which are not a simple deliverables which we can do with the simple scrum team instead we have various different deliverables which needs to be made and dynamics are too complex so bigger projects then scrum of scrum approaches can be taken so scaling the agile methodology to that level so it is used to establish the required transparency collaboration adaption adoption to the required scale to ensure the products can be developed and delivered so whatever the products are delivered whatever we consider to be delivered so those needs to focus on the business objectives which is very essential so what is user story mapping so user story mapping represents and arranges user stories that help with understanding the system's functionalities the system's backlog planning releases and providing value to the customers so first of all we write user stories to understand the required features functionality in their user perspective now if we map those user stories which use a story link to other user story which functionality links to other functionality determining that will become easier so now user story maps arranges user story based on the priority along the horizontal axis on the vertical axis they are represented based on increasing level of sophistications so this will help in terms of handling in a regular flow in a specific flow not regular specific flow so that things can be done in order with full clarity so question number 13 what happens in sprint retrospective so after this print review so sprint completes so sprint review happens the sprint retrospective is done so during this meeting the lessons learnt what went well what mistakes we did what were the issues so is there any new way of doing things so all these are discussed so that these necessary corrections can be considered in the upcoming iterations the sprints so data from here is incorporated when planning the new sprint so the learning what you had you are going to collect it what went well what went wrong what was supposed to be the best approach and how did we approach it is there any other way of doing it so these are discussed and very essential to do it at the end of completion of each of the sprints review question number 14 what is empirical process control in scrum so empirism refers to work based on facts experiences evidences observations and experimentation so empirical process control is established and followed in scrum ensuring project progress and project interpretation is based on facts of observation so actual facts and figure is very important any decisions what we make any progression what we make should be always based on on ground facts and actual pictures we should not deviate from it so these rely on transparency observation adoption obviously when you're working on the data on ground reality so you're working on the actual one it is transparent it is on the observed data the mindset of the team and the shift required in thought process and culture are very essential to accomplish the agility required by organization so mindset of the team is very essential and adoption of process compliance to the process the culture the behavior obviously plays a very important role when you do something within the organization so that needs to be done as per the need which should complement to the business objectives very important and that should be based on facts not on some thoughts or assumptions or ideas so next question is what are some drawbacks of using scrum so scum requires individuals who have experience without whom the project risks will have a risk of failure so one does not have a capability difficult scrum requests team to be collaborative and committed so while people collaborating individuals collaborating itself is a big challenge in many organizations so bringing this into the place is very important when you want to adopt scrum so scrum requires teams to be collaborative and committed to ensure the required results they should work together and also they should collaborate with customers stakeholders the less experienced crumb master can cause the failure of the project so be careful scrub master is the one who is facilitator we should understand this who enable the scrum teams who ensure scrum teams goes the way we need them to work if scrum master doesn't understand this dynamics does not have the clarity on this obviously the e or she can not enable to team to become that if tasks are not well defined the project can have any inaccuracies chrome works better for smaller projects and would be difficult to scale to large complex projects that's where we are discussing on a few questions before this scrum of scrum we were discussing about when it becomes a complex project which those needs to be handled together which will become complex so next question is what are the skills of a scrum master so a strong understanding of scrum and agile concept scrum master should have fine-tuned organizational skills so when scrum master is working with the self-organizing team with various different capabilities so unless the organization skills interpersonal skills if scrum master does not have working with them will become difficult so if scum master should be familiar with technology that the team uses basic understanding of that how it works the dynamics associated with that and scrum master should have an ability to coach and teach the team to follow scrum and its methodologies and very clear about the terminologies artifacts and all the events what happens so scrum master should have an ability to handle conflicts and resolve them quickly so conflict is a scenario which would happen for various different reason however when conflict occurs the scrum master should not shy away from it own it to resolve in the interest of the project whatever is being done it is very important scrum master has to be a servant leader so it is not like i am a specific manager or leader of certain kind and i am doing this with certain way no i am actually facilitating i am guiding i am showing certain direction to the organization so that says to the team when i say organization speaking about scrum team so that they are unable to take up the specific project and accomplish the results accordingly question number 17 how can discord be dealt within the scrum team now the root cause of the issue need to be identified and addressed complete ownership needs to be established when you deal with this and try to diffuse the disagreements so emphasizing on the focus area that complements the project so here when we take up any of the discussions any of the opportunities or any actions what we take everything should be revolving around objective of ultimate objective of whatever we are doing so when we need to resolve something when we get into the root causes always it helps to look at the actions in terms of eliminating those causes so once the causes are eliminated it is quite obvious you can able to deal with it and address it with easily with the right set of actions so emphasize on focus areas that complements the project in the sense that should be the ultimate direction not my individual interest not that individual interest i favor this person i feel that person that's not to be the case so favoring this solution or favoring that solution i'm okay with this particular technology i'm very happy with this technology not such thoughts it is the direction what is set i should move things in that direction so to establish a common understanding and to guide the team to that direction performing continuous monitoring and providing complete visibility very very important next question what is a user story so user stories are an agile software development project management tools it provides the team with simple natural language explanations of one or more features written from the end user's perspective now for example i'm a account holder in a bank so first what is the facility a bank would give to um account holders there is atm banking there is net banking there is mobile banking and there is over the counter now when bank is working on creating certain specific features or specific mobile app to the account holders now what are the things user needs that needs to be visualized now if i say the role here is account holder as a account holder i want to download the statements of every month as an account holder i want to download the statements every month this is what my requirement is how will you facilitate this this will provide the insight towards how the bank what are the features and functionalities and how these requirements are can be fulfilled by the bank and what features functionality the particular mobile app should have so that account holder can download the statements so user stories will provide that insights whatever users so account holder is not just an user here there are many users when it comes to mobile app of a bank we have uh people who monitor it manage it would develop it so they need to have a clarity on what exactly they need and that needs to be written as part of user story that what features functionality can be easily determined out of it so a user story does not go into detail it just mentions as i gave an example it just mentions how a certain type of work will bring well into the end user the end user in this case could be an external end users or even internal customers or colleagues within the organization so if i am an organization i produce an hr application i create an hr application for claim processing which i don't have till today so that is for internal users in the bank example and speaking about external customers so user stories also form the building blocks of agile framework like epics and initiatives these help ensure that the team work to the goals of the organization through epics and initiatives so further the requirements for making the user stories a reality or added later after discussing with the team so to write as a story the involvement of the team members are very essential they should discuss and come out and agree yes this is the features functionality which should be there user stories are recorded on post-it notes index cards or project management software whatever is visible and whatever is available there next question how are the user stories epics and tasks different so user stories provides the team with simple explanation of business requirements created from the end user perspective as we saw the few examples in the previous questions epics are the collection of related user stories they're usually large and complex so these epics are created with specific objectives in mind and user stories are grouped so that will form an epic whereas task refers to the one which are used to track work so they are used to further broken down from the user stories so there's a smallest unit in the scrum used to track work a person or a team or two people usually work on the tasks so these tasks are these through this task i think the features functionality what are required to be accomplished are done so question number 20 what is sprint now as i mentioned earlier in the question number four so sprint is the terminology used in the scrum i think we explained various different concepts as we went through so sprint is the terminologies used in scrum which refers to time box iterations so we understood what is this iterations in scrum approaches when we are going through that the creation of specific modular feature which is part of a product is done during the sprint the duration of sprint varies between a week or two so means it's a short duration simple few features functionalities are taken and created so what is velocity so velocity is the metric used in scrum that is a measurement of the amount of work that is completed by team during the sprint so this is help to measure how things are moving how faster they are moving it refers to the number of user stories completed in single sprint so this speaks about that speed so our velocity velocity uh how faster we are going how slower we are going this helps to vary the variations we can do that velocity depending on what business need so what are the responsibilities of a product owner so product owner define the vision of the project they anticipate the needs of the customer and to create appropriate user stories so they don't write user stories as such they definitely have a set of people who should get involved the team to write the user stories lot of discussion has to happen brainstorming has to happen to write user stories but product owner is accountable so product owner has to evaluate the progress of the project based on this backlog what project a product owner has and has to be licensed for all product related questions the team may have certain questions as prints as the sprint progresses the scrum team may have certain questions clarification relating to the user stories those needs to be clarified what is burn up and burn down charts so generally when we say chart it is a graphical representation so burn up chart is a tool that is used to track the amount of work that has been completed so it is a bar chart the amount of work completed the height of the bars keeps increasing in burn of chart based on what is completed which will show the total amount of work the need to be done for a sprint or a project so it is it's a bar chart where each of the bars keeps increasing in its height as number of things get delivered increases so burn down charts typically again a graphical representation a bar chart so what is pending to be delivered it shows that now initially we'll have a bigger bar and as the project progresses the height of the bars reduces indicating what is that is pending for deliverables it is a representation of how fast the team is working through the user stories it helps you to understand that so it shows total effort against the amount of work for each iterations which is helpful for it oc to that what is pending to complete question 24 how is estimation in the scrum project done so the estimation of user stories is done based on its difficulty a particular scale in which which is used to assess the difficulty of user stories so to analyze how difficult or easy is this some of these scales which are used like numeric sizing 1 to 10 t-shirt sizing like sml excel fibonacci series or dog breeds based on their value so many such approaches are taken what are some risks in scrum and how are they handled so first of all we should know what is risk so some types of risk in scrum are related to budget people sprint product knowledge and capability now when we say budget risk of increase exceeding that allocated budget taking more as looking for more variations i estimated for x it is going like x plus delta x so can we control it we need to look at that so you need to assess that risk when what possibilities the cost can escalate people related like team members need to be of appropriate skills and capabilities if they lack that obviously difficult it's not about just skills and capabilities the culture the behavior the attitude the energy this energy that collaboration what people will have then sprint related in terms of duration and deliverables exceeding the duration addition of scope to that sprint in between so that challenges that difficulties so product referring to user stories and epics having ill-defined user stories and topics not properly articulated there is no proper visualization when you look at that user story not understanding so nobody is explaining it correctly so then knowledge and capabilities so it is not just related to the people here itself entire system everyone was who is involved with the specific resource with its capability it can be technology capabilities also so when i say risk it basically involves identification assessment analysis and defining risk response plans and implementing them now when i say assess assessing the risks should be qualitative as well as quantitative so depending on the impact and probability of a risk if it is a high impact risk obviously we are equated to both qualitative and quantitative if a simple one with very less impacts you can take the call accordingly to what extent you may require to analyze and have the response plans for it so once you have implemented and defined and implemented the response plans quite obvious you should keep monitoring it and manage the risks now risk impacts and probabilities may vary as the project progresses so we may require to keep assessing the identified risk and keep identifying the new risks as you as we progress in the project so these are done on a continual basis right from starting of the project till completion the reason i told it is essential to understand that the impact of the risk is based on the proximity of actual occurrence of the risk now for example if you start uh working on something nothing is delivered at the at the moment now if specific risk of peep no people not available our customer is not involved initial stage very initial stage so you risk impact is accordingly project would delay in entirety or requirements not very clear it is delaying something of that sort of impact you will have now as the project progresses almost like 50 of the project complete now the there is some uh challenges or risk associated with issues are occurring related to customers involvement now you are made of project so again you will have a different kind of impact 50 percent is delivered now you need to progress because active involvement of stakeholders including customer is very important when you are becoming a child so when that is not happening as an example i am taking the involvement of customers the collaboration part of it that is not happening now here the impact level is not equal to the impact level when when this happens in the starting of the project same type of risk what we are assessing so that is the reason each of the risks you should keep assessing the identified one keep assessing as the project progresses and check on is any new risk is introduced as the project is progressing so next question what are some popular tools used in scrum so these are the list so you can think of github soho trello jira software yodex varies of version one so now what i'm saying is these are the tools technology tools so when we say tools we cannot just limit our thought to technology tools so what exactly this tool does what are the techniques used that we need to be very clear right the metrics what is measured and methodology of measuring it and what processes are used what steps are used so what needs to be used so unless we are clear relating to specific type of project usage of these tools may not make any sense you cannot even implement or customize this for the requirement what you are trying to accomplish so you be clear about it when you are selecting the tool so 27 how does scrum master track sprint progress so we have various different events which happens in uh scrum like daily scrum meetings scrum retrospective scrum planning scrum review and checking on the defects which are escaped density of the defects burn down [Music] spring burn down velocity so so checking all of this provides the better insight to scrub master so that tracking the progress of the sprint will become easier so how to deal with the scope creep now before we understand the dealing with scope tree we need to understand what is scope creep so the term scope creep refers to the change which is uncontrolled and added without checking the impact on the constraints like scope time cost now what happens is you will be doing certain or delivering certain features now you are forced or you are influenced or without your knowledge some additional things are put in place so which may impact later it may add value it may not add value later it doesn't matter but it may lead in terms of impact your cost time and schedules which is unexplained and that extra effort what you have put in extra cost what you put in uh will become like not recognized by customers and you will not get anything paid for it so scope to avoid the scope creep to deal with it one has to ensure close monitoring of works being done on day to day basis because scope creep can happen through team members influencing team members are influenced by consumer because of that it may happen so understanding communicating the vision to the team for ensuring the alignment so the team is very sensitive about that changes what is happening then capturing reviewing the project requirements regularly against what is delivered to emphasize to the team and customer about the requirements signed off so that someone will not come and influence you or make that additional things to be delivered they need not push you right ensuring any change introduced to go through change control so no changes without any proper approval by the authorities so that only those what is required to be implemented is implemented and that is done formally through the formal change request so avoiding gold plating so it is with different thought process when we say gold plating so we were doing the projects are trying to add certain things into the scope to please the customer as an example doing something additional providing some additional features and functionality for which we are not paid so scro creep is not a terminology used for it but gold plating is the term used but however since it is an additional scoping so we're just added here so don't say that when the moment scope creep we says that is not gold plating gold plating is a different direction so just to explain you along with scope creep what else would happen to where the additional deliverables would come in which is gold plating so question 29 what is mvp and mmp which means minimum viable product and minimal marketing product so now minimum viable product is a concept of lean startup which stresses upon the impact of learning while performing product development so this allows one to test and understand the idea by getting exposed to the initial version of the product for target customers and users so to accomplish this one has to collect all the required relevant data and learn from the collected data so the thought behind mvp is to produce a product to provide access to the users and to observe how the product is used pursued and understood this will also provide more insight towards what the customers or users needs are so when it comes to minimal marketable product this refers to the description of the product which will have a minimal number of features that addresses the requirements of the users the mmp would help also the organization reduce the time to market because you have the clarity what is that we may require to provide the question number 30 what does dod means definition of done right so dod refers to the collection of deliverables which includes written quotes comments on coding unit tests integration testing design documents release notes etc this would add variable and demonstratable values to the project development so deword is very helpful to scrum while identifying the deliverables to achieve the objectives of project for the stated reasonable so defining the steps required to deliver the iterations the usage of appropriate tool like burn down to make the process more effective ensuring on-time feedback throughout the project life cycle ensuring the walkthrough of the product backlog items are done and understood correctly so then creation of checklist for product backlog item ensuring the devotee is defined to become task oriented involving the product owner for reviewing during this print and sprint retrospective that is about dod the next question how can a scrum master be a servant leader it's a very important thing to understand so what is the meaning of the servant leader the term servant leader mainly stresses on service orientation which a leader should demonstrate so today we say every organization is service organization even an organization who is producing card if there is no service orientation they cannot sell so more stresses on being service orientation the scrum master needs to be facilitator a guide a mentor etc this helps the team have increased involvement and empowerment so now question number 32 how can one coordinate between multiple teams so one of the most common approaches for this is krum of scrum's meeting so where members representing each scrum team discusses the progress performance issues risk etc together this is complex structure what you're speaking about the frequency of these meetings must be predefined well articulated well defined generally scrum master would represent the particular scrum team on behalf of that scrum team they would go and represent the meeting represent in the meeting besides having a chief scrum master who's responsible is coordination and collaboration among all scrums who facilitates these meetings thank you guys with that we have reached the end of the scrum full course video by simply learn i hope you have found this informative and helpful thank you for watching stay tuned for more from simply learn hi there if you like this video subscribe to the simply learn youtube channel and click here to watch similar videos to nerd up and get certified click here

Channel: Simplilearn

Views: 53,229

Rating: 4.9203539 out of 5

Keywords: certified scrum master training, certified scrum master full course, certified scrum master interview questions, certified scrum master class, certified scrum master (csm), scrum master, scrum master training, scrum master roles and responsibilities, scrum master certification, scrum master tutorial, scrum master course, agile scrum master training, agile scrum master tutorial, learn agile scrum, learn agile scrum methodology, simplilearn agile scrum, simplilearn

Id: YqAZi5poCmo

Length: 208min 36sec (12516 seconds)

Published: Thu Apr 08 2021