Comprehensive Overview of Scrum Methodology and Practices

[Music] hey guys welcome to scrum master full course video by simplilearn 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 a

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 which needs to be created for customers any changes required to be done in any of

our projects involving that consumers and customer we may 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 a 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 gel 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 in specific have something called daily scrum where 15 minutes meeting where entire scrum team should

come in sit together self-organizing team as well as all that agile team has 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 discover 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're speaking about time to value which means how quickly 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 hirotaka

kuchi so japanese so now this terminology introduced but later in 1995 jeff sutherland and ken schubert 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 are 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 of 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 uh during the adoption of scrum when organization adopt describe 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 scam 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's a quick 15 minutes meeting

which gives the insight and further wherever there is a dependency deviations which occurs further maybe scrum masters 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 customers 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 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 these 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 responsibility so the entire focus is on ensuring the right product backlog prioritizing it and also adding that user stories and epics 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 scrub 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 will 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 which

is 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

devos we keep speaking about uh cicd in cicd we speak about continuous integration continuous uh 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 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 pending 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 achieved the goals of the stakeholders

we discussed 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 scrub 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 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 works like a lessons learnt 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 uh 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 the 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 backlog

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 or 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 epics 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 um you would never do an epic or pardon me a theme in a sprint it's too big so it's used for planning purposes below that i would put epics 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 uh priority levels of a product backlog and as user stories are completed and the epic rises in priority it will eventually be broken down into more manageable user stories so great big low priority user stories then

we have user stories themselves user stories are functions or features that the product owner wants to have developed a user story turns into working software that provides value to the customer and um and the product owner is the customer voice the product 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 like a use case could be um select and pay for items in a catalog now that could actually be an epic or maybe a

theme because maybe it would get disaggregated into log on screen catalog 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 priorities so this one first and that one and 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 2 and so what we really need to do is insert that before the the second priority user story and so the priority of the user stories in the product backlog while it might start with just being you know simple functional user

stories coming from the uh product owner it will evolve until it includes some other things that are also considerations when it comes to priorities because of you know successor predecessor relationships dependencies and things like that are considerations

a user story be uh back to the the screen bottom left now the user story 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 is usually going to contain 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 see you have um themes up at the top that's the biggest grouping if you will used primarily

for um you know high level planning purposes so you have your themes then you have your epics which are large user stories 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 um well not

if you wanted to what i recommend is being able to write out all of this stuff on plain white scrap paper in about 14 minutes because that's the amount of free time you have in the tutorial when you're at the uh or when you're taking the test um exin does a little

bit different you maybe won't have a tutorial the only time you 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 um 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 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 i-n-v-e-s-t 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 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 it has to be estimable as an estimatable except

estimatable is not really a word it's estimable um 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 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 the three c's of a user story so the first c team is card so user stories should be able to be written on a four by six inch index card or some media similar to that

card 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 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 in it itself so card 4x6 conversation that's the starting point that's where the team and the product owner discuss and then eventually there will be acceptance tests included on

the user story card in order to be used during the sprint review to assure that it's acceptable that there's confirmation okay so oh let's add that to the memorization list so three c's all right now i've got an example here of a user story card so we're looking

right here and if you were to go out on the internet and search um user story cards um they would be similar there would be some differences of course 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 court on the card rather then there will be an estimate of size it could be ideal days or story points as i mentioned most teams do story points that's more likely what you'll be tested on as opposed to ideal days but you know we'll cover both so you

understand the difference is there is probably it's not listed here but there's probably going to be a value point assignment this is where the product owner kind of determines in a relative way the value

of the stories just like we were doing in planning poker the product owner might say well this story is twice as valuable as 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 do that that's from where from

um here it's got customer tech you could also have defect you could maybe have risk and then there's also going to be an x factor which would be some kind of word probably like

stable erratic incomplete something like that to so the team is designating the user story in respect to the amount of uncertainty or risk that's associated with that user story and because all of that's a part of the story right the story is going to be turned into

working software there may need to be some efforts to actually figure out how to actually do that user story so that's the x factor over to the right here on the same chart we have some comments about if you are using a software package excuse me like trello or

jira or something like that excuse me the user story cards will generally be able to contain more information using you know dynamic links and things like that 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 uh that has to do with making a reservation another one that has to do with modifying it and yet another one that has to do with 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 you know when you're

working on accepting payments or processing refunds it's going to check on um who the operator is or track that so that if at a later time you know who was it that gave this uh refund here well you could look and see you know okay the the operator's name was

recorded or maybe you put some restrictions so that maybe not everybody um is allowed to do a refund and so you would have levels of users that have different privileges okay and then down at the bottom split based on data boundaries for an example you know as

an accountant one needs to enter balance sheet information which could then be split into summary information and separately um uh receivable details or you know maybe you could have ap you know so you could have different portions of the overall

balance sheet activities that need to be done so enter ar enter ap etc 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 uh so somebody's in the process of placing an order um maybe there are some premium features that could be add-ons at that point in time

or maybe added later on so you have an existing customer who actually buys 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 what he or she

wants them most listening to the team say well you know there's some you know greater risks with this user story than that and so you'd probably want to uh persuade the product owner to take care of high-risk stuff first because that would have

a uh excuse me sorry an impact on the future things that need to be done there's the kaya the cattle 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 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 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 uyghur's relative weighting method and this is all using numbers so each feature is given a value for its benefit and it's penalty given a value for penalty meaning what's the pain if that

feature or function is not included and then there is um the cost side and the risk side and then those are all calculated together and that results in

excuse me a ranking or a hierarchy which gives you the priority for the user stories we also talked about moscow didn't we did we talk about moscow moscow is another prioritization model must could i said that differently must should could won't moscow mscw must should

could won't and we talked about that one thank you for that confirmation does it seem like a long time ago or is it just me i know it was just last weekend but it's like last year okay so now let's talk about velocity um uh priyanka that is exactly right um so velocity

is the capacity of the team to complete work in a single iteration so the team has estimated the user stories uh for size or ideal days and um 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 uh box number two here velocity

is used to deal with um 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 five three eight 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 um if you were 36 you were claiming half of the two that were five so that would be a total of 10 so you claim half of it which would be 5 would take you to 36. but it's

not going to be 36 because the only thing that counts towards progress is working software so even if the team had finished 9 out of 10 story points for a user story meaning it's almost done and then the sprint ends that doesn't get counted towards velocity

and you don't mess around with velocity um you can mess around with your estimating and you can mess around with um you know what user stories are going to be completed in a sprint but you don't the the velocity is not variable it is what it is based on past

performance when it comes to levels of planning we have what's called the planning onion and let me walk you through 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 roadmap my example of

that website that i'm working on has uh three versions which make up the product roadmap version one is the free site version two is the membership site and version three is the um the pay referral commission's 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

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 road map concept here so let's just review this quickly predatory's high level ethics 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 um be able to estimate velocity and then assign stories to the sprints so we keep estimating the user stories and we keep organizing uh

that until we can do that we can come up with an iteration length or sprint length and then figure out what our velocity for each sprint is and then uh assign stories to the uh the sprints uh the the next bullet down iterate until the user stories and release date meets

conditions of satisfaction so that's 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 the 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 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 tandem 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 keem come on you can do this the team's like no we know what our velocity is no the product owner says i'm telling you there's no way that that can't be done i know you can do it i trust you i believe in you but the product

owner doesn't have to 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 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 um the first time as a team you know we didn't know each other we didn't know everybody's thoughts and concerns and those kinds of things you know get shared and absorbed as a project

goes on and so there's a higher awareness of that so 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

which is 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't it will increase if the team is learning how to work together better and better you would expect that if i can just use my mouse here

if we were tracking velocity so this would be points completed over here let me just do pts for points and down here is time and we go from sprint to sprint right you would expect that maybe you know the first

couple of sprints the team would be learning how to work together and there would be a steep curve and then it would kind of flatten out and maybe have you know a slow rise going forward as the team emerges as a high performing team they get better at their cross functional

behavior you know somebody's shake 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 etc 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 priyanta 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 so you can do it like we did you can also triangulate 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 three and the values you know now i used in our example the modified fibonacci series uh 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 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 twenty it would be thirteen plus 8 which would be 21. um i 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 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 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 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 um you know we will be building in extra time based on distractions and interruptions we would not call it a buffer but that's essentially

what we're doing now when it comes to user stories that we're using story points it is different the points are for the entire amount of the work and why might we need to have some extra time for a user story well it's likely going to be driven by uncertainty there

might be other 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 um so that's the story points let's compare the two um ideal time uses things like hours and days which is easier to explain outside the team

right the suit's 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 are harder to explain outside

the team you know the suit says well how long is it going to take to do user story 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 uh story

points now here's the thing it's a lot easier to get consensus when we're estimating in story points and once we get good at it it's going to be much faster we have to remember it's not comparable across teams so you know 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 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 um 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 uh 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 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

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 see 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 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 um 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 um 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

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 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 p s p 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 boxed 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 um 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 hang 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 um 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 um then that's going to argue for shorter durations um because there's uh 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 got to pay them 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 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 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 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 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'll 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 um 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 of course it should be realistic

and achievable and you know there can be a little bit of of 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 product owner is 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 uh you know assisting in the resolution of those kinds 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 is 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 um a good scrub master

being a facilitator in a retrospective would have some knowledge of control charts the five why's 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 uh 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 um like some that i mentioned control charts um ishikawa diagrams um five why's there's a number of things that you might use 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 um is uh going to happen um you know continuous improvements the result of other things but this is the main thing and if you were getting a question about the relevance or the necessity of retrospectives there is no equivocation

you do a retrospective after every sprint if you don't do a retro if you don't then there's no improvement 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

road map 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 road map is um got three versions it's a website the first version is free the second version includes a membership component and the third uh version

includes a referral commission uh 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 the 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 and 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 um 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 owner's 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 uh 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 scrub 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 but i would kind of flip that the scrub master is the facilitator it's the team that still owns that so 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 eighty percent code coverage um it could be more

than that um 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 are 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 tight rope 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 distributive 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 6 plus or minus 3.

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 spent 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 reprioritizing 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 run time 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

called based on a metadata value and then processing the 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 erin faced daily until it is removed you should let me know if i can help in any way right erin 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 stores 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 with this you can easily identify bottlenecks and then fix them cost effectively at optimal speeds the main focus with kanban is transparency since everything related to the tasks are on the board everyone can keep themselves updated it also ensures the 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 even driven the next criteria we're going to have a look at is release methodology in scrum releases take place after each sprint which usually takes 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 teams that focus on particular aspects of the workflow are required now let's talk about new additions in scrum just like handling changes you can't add any

items between a sprint or nitration in kanban new items can be added to the board as long as there is capacity available for it now let's have a look at the job roles within these frameworks scrum has three major job roles product owner scrum master and 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 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 skill 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 chrome 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 scrub 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

5 plus or minus 2 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 box 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 as 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 has been taken is 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 ager 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 agile so i adopt scrum so this definitely has to align to agile manifesto and take the guidelines whatever is mentioned in 12 principles of a gel 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 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'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 jail 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 experiment 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 completed 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 in scrum 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 pre-orders list you take from the product backlog so product backlog is independent of sprint backlog whereas sprint backlog is

dependent on product backlog reason we know already i explained so 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 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 uh helps in terms of visualizing what work is in progress and since it is a

visualized visualized system which 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 karamban 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 uh this was introduced there in extreme programming that is 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 chrome 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 a 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