[𝐑𝐄𝐀𝐋 𝐖𝐎𝐑𝐋𝐃] scrum master interview questions and answers ⭐ agile interview questions⭐ [𝑷𝑨𝑹𝑻-2]

okay hello friends and welcome in one more session so today again priyanka is with us i'm sure friend if you are our subscriber you definitely have seen this video so far in part one uh priyanka along with priyanka we have covered around close to 20 different questions which are asked in 10 different interviews in the past and here we are with the part two so first of all thank you everyone with the so much uh love you have given so much likes and so much views so first of all thank you for that and hopefully

this session will be like that only so prank again welcome and uh let's rock it again thank you and i would also like to thank the audiences who have watched my uh video and given so much of appreciation and love to the video and i'm happy to deliver more content for the for other people who are really aspiring to get a scrum master role so if it's giving some value to somebody that's really great thank you thanks springer thanks a lot really appreciate it okay so if you allow shall we start bring the yes we

can start okay so let's start with this one and again this is the i think most asked nowadays this question that what is your favorite scrum event and why so my favorite scrum event uh i would say that scrum framework is defined in such a way that if you remove any of the thing from the framework it will not add much value because uh it's a foundation and structure of a methodology so if you have all the things into the framework that will go best and you will be able to deliver best if you're using

all of the things but uh if we are talking about something which is really favorite i would say retrospective even that is the most favorite event uh for me as a scrum master because that's the one i play major role in and it's a it's a technique it's a meeting where we talk about uh what did not went well what went well and what is it that we can improve upon so together with the team we can collaborate and get honest feedback so that we can improve into our future sprints scrum is based again on

three pillars which is transparency inspection and adaption and with the help of retrospective uh it's it's one of the best platform or a event wherein we are able to inspect uh or we are able we are transparent enough to talk about uh what is it that we have done into our sprint and we are giving an opportunity to each of the team members to inspect what went well during the sprint and what were the opportunity areas where we can improve into our future sprints yeah and then according to that we can adapt it into our

further sprint so i think that's a good platform where we can together as a team work upon and then as a scrum master i can gather those those areas and coach my team that what is the right approach that we can follow into the furthest prince so i think retrospective is something my favorite as a scrub master thanks uh prince for that okay okay so let's let's talk about uh refinement and sprint planning so what is your key role in those these two events uh refinement and sprint planning yeah so uh sprint refinement meeting i

would first like to explain what is a refinement meeting and what is a sprint planning meeting a sprint refinement meeting is uh not one of the events from the framework however again it's a really important meeting that should happen during the sprint where uh the team the entire scrum team including the product owner and the developers uh sit together and talk about what are the functionalities that we they are going to deliver nicks so they are they talk about the features and functionality they order it or prioritize it bases the business value and again estimation

is again one of the one of the things that is done during refinement meeting as a scrum master during the refinement meeting my role is to facilitate the meeting uh understanding what uh if if the developers are able to understand the functionality which product owner is trying to explain and again understanding the body language of the team so that if there is any anything the team needs any kind of information the team needs to push to the product owner they are open enough to talk about it they are courageous enough to talk about it and

if there are any concerns there are any dependencies related to any of those uh user stories they feel any challenges on any risk they talk about it openly um so as as a observer in the team my role as a scrum master is to observe and push the team that if there is any item that they that can hinder uh the performance of a sprint uh that that can stop the spring for delivering something valuable i should bring it up i think that's the role of a scrum master during the refinement meeting and spent planning

meetings this is the very first event in a scrum framework and it happens at the first day of the sprint as soon as the spread starts where again the entire scrum meets meet together and talk about uh what are the high priority user stories they want to pick up for the sprint that they want to you know with the help of which they are they want to deliver some shippable increment at the end of a sprint so pick using or choosing those user stories the developers commit to a following user story that these are the

ones they will be able to deliver and with the help of this this is their sprint goal they will be able to come out with this functionality after the end of a sprint this is what is covered in the sprint planning meeting which covers why we are doing the sprint and uh what is it that we will be able to build and how we are going to do that and again my role as a scrum master is similar as we have done in the sprint sorry refinement meeting where as an observer or as a good

listener i will observe the thing and asking the right questions if understanding if all of the team members have really understood the functionality that we want to develop and if not what are the challenges that they are facing and if there are any impediments that can i that i can help soul so yeah it's basically a good listener and observer observation skills that is needed by a scrum master during these two meetings thanks a lot uh prince for this little explanation okay okay so this one is again very interesting uh so what is your strength

and a weakness as a scrum master okay so working in a scrum master role for a good number of years now i would say my strength as a scrum master is that i am able to collaborate with my team well and i am very empathetic person so i am able to build that empathy within the team so that team can or people can come find in me they can come to me anytime and sharing their challenges and concerns what is it they are facing they can openly talk about it and as a scrum master since

i am responsible for solving their problems they are brokers um i'll do my best to solve those problems so i think my strength is that people can confined in me they can come and share their experiences their challenges so that i can help solve them as a weakness i would say my weakness as a scrum master is that i have worked with many geographical teams and uh working with multi geographical teams is a kind of a challenge sometimes because there are delays there are cultural differences there are time zone differences so at times there are

collaboration gets delayed and some of the situations where some of the people are working in different time zones so you need to get all of those together especially for those five events that we have in the in the sprint so collaborating them in that respect when they are working in different geographical regions is kind of a challenge sometimes so i think that is i would say is a weakness as a scrum master and this is in journal i would say anybody working as a scrum master might face this problem okay through anger okay uh okay

so let's let's talk about uh most asked question what is burn up chart and burn down chart and when we can use which one which matters which we can which we can use yeah so burn down chart and burn down chart are two of the metrics that we use in the scrum framework and both of them basically serve the same purpose to tell the progress of the product or the project that we are doing burn down chart tells us how many work has been completed however burn up chart tells us how much work is sorry

i did it wrong burn down tells us that how much work has been uh done or completed yeah i was right and then burn up chart tells us how much work is still left explaining them one by one burn down chart again is a graph which is x to y axis on x axis we have the days the total time we have in our cadence uh if we have a two week sprint so the those of 10 days will be there in the x-axis on y-axis we have the efforts we can have it in terms

of hours or in terms of story points and then there is a ideal line which tells us that if we work in a ideal situation how much work should be burned down each day and then there is an actual line which tells us based on that ideal line how much we are able to cover um and how much stories we are able to burn day by day so that is what is uh done with the help of a burn down chart as uh the team uses it during the daily scrum so that they can see

whatever what is it what is the work they have been able to complete day by day and in a way it helps to track the progress of their sprint and similarly burn up chat again serve the same purpose tells us about the progress of the project or maybe as a whole i would say because it again tells us in terms of the total time versus the efforts so day by day how much work we have been able to complete we are able to mark that line on the graph that after each day or after every

sprint how much work we have been able to complete and if we have a rough idea of how many total story points or user stories we have into our project say if it is 200 and then basis that every day we are able to mark that uh how many stories we are able to complete each day so basically burn down and burn up chart are doing the same thing but in a reverse order yeah that's about burn down and burn objective okay thanks a lot principal okay now this one is again very interesting uh how

you are going to explain agile to your grandmother okay yeah this one is really interesting because in this uh the question is like we are trying to explain agile concepts to somebody who is a non-technical person who has never done something called software development so if i have been given a chance to explain agile to somebody a grandmother or maybe a grandfather or maybe a child i would explain it in terms of a real time example a real problem that we are facing so let me share an example and considering i am explaining this agile

terminology to to my grandmother so i will say that agile as an english word has a meaning is to deliver fastly and incrementally so for taking an example that suppose we want to hire a house help for uh 24 cross 7 and this is the project we have in hand and we want to do it and we have no idea what all work we could have we have some basic understanding of what all should be done by that household so maybe doing the dishes and cooking and then washing the clothes and then taking care of

the kids so we have we know some of the basic function of functions that the house help will do but we do not have a clear picture of what all needs to be done so instead of hiring somebody for 24 cross 7 i would suggest if we can hire somebody for maybe two hours each day and then understand what our requirements are and how the other person will be able to perform and this is then how are the expectations from the family members coming up which may be our end users who are going to use

that uh functionality uh or maybe the house help the people who are going to use that so they can give their feedback and basis that we can you know explain those uh roles or responsibility that that house help is going to do and uh this is that uh we're going to increase the time we maybe will take it to four hours and then six hours and then finally um making that house help work for 24 7. so that is how maybe a non-technical person uh get a gisp of what uh agile is and how agile

works in software development okay thanks a lot thank you for that okay okay so this one is uh about mvp and mmp minimum marketable product so first of all what are these two uh terms and what's the difference between these two mvp and mmp mvp is minimum viable i'm sorry mvp is minimum viable product and mmp is minimum marketable product and minimum viable product if i say is that the minimum features that we should develop you know the minimum functionality that we should have um which will tell us which will help us you know ensure

that the assumptions that we have made to ensure that these assumptions are correct or maybe the idea we have taken if we are developing a software the idea we have in mind is it going to work if we are going to develop that minimum functionality that will be called as minimum viable product and which will basically decide the future of a product that we have we have an idea in mind we created some minimum functionality is it really going to work and can we take it further that we call as a minimum viable product and

then after having multiple minimum viable products making changes getting feedback we will come out with a minimum marketable product that is something which will actually launch to the market as the term says minimum marketable product so something which is ready enough to be delivered to the early customers so that they can uh use it and this will be a few versions after mvp where we are adding certain features when it is actually ready to be put into the market as the basic the basic functionalities that we are giving to the end users yeah so this

is uh mvp and mmp in my terms true true okay thanks uh okay so this one is again i think a good one uh so when you have a multiple offers in hand why you are looking for other opportunity how you tackle this question uh sure so i have also been asked this question now and that's why we have been bringing it up that uh i've been asked this multiple times that or if you're already holding an offer in hand by looking for other opportunities so my reason for this is that and it it changes

from person to person and it is different from person to person for me it's that i have been working in an organization for a good number of years so i've worked in a single organization for 12 years so although i was given multiple opportunities to grow my skill set my technical skills i was a qa i was into a cure role at the beginning of my career and then i moved to scrum master so i was able to grow my skill set however financially i was not able to grow much being into the same organization

so that's why when i am going to look for a new job now i want to be financially convinced enough so that where i am wherever i am going i can stay there for long i can be financially uh you know i can make my financials match to the market standard so that even after one year i'm not going back again and looking for change to match my package to my peers so that's why to make my financials uh mark up to the market standard i'm still looking out for a job and yeah that's my

reason thanks sprinkler for owners answer not sure whether people will like it or not but then there's always okay to tell yeah okay i don't know if people will like or not but that's the reality keep it up okay thank you okay so let's let's talk about uh prioritization technique which you know or which maybe your product owner uh used in the past uh for user story providation sure so in our organization uh the po use multiple uh prioritization techniques uh while prioritizing or ordering the user stories and uh some of the ones that i

would like to bring up is like stack ranking is stack ranking which is one of the most common one where in we order the user stories as uh number one number two number three so the number one has the highest priority and the number two is lesser priority than number one against number three is again much lesser than number two so it's a stack ranking and some of the benefits of this is that we have a clearly defined order and the priority will not change the number one will always be go going first into our

sprint backlog and will be delivered first so that's how this is one of the approach the po users another one that is being used is the moscow technique which talks about uh must have uh so in moscow we have must have and then we have should have could have and won't have must have talks about what are the functionalities or features or the user stories which are must have and should be must be there for the customers to be used and should have are some of the features that if not there in the product would

not make a good product so these uh should be there in the product but it will be delivered after the master functionalities have been delivered then we have could have functionalities uh which tells us that these functionalities if are there would be liked by the customer and the customer would be delighted if those functionalities are there but if even if they are not there we are fine the product will still do fine these are could have functionalities and won't have functionalities are the features which are really not needed and we can remove those phone from

the product backlog so that's another technique that is used by the product owner third one that i would like to talk about is the cano model in canon model we have different thresholds that we defined like attractive we have indifferent we have one dimensional let me talk about them one by one attractive are the ones which should be there in the product and if it's there in the product that it will be liked by the customer so the satisfaction rate of customer would be high one-dimensional uh functionalities are those which are there if if they

are there the customer would like it they will be satisfied and if they are not there customers will not be happy about it and then there are delighters the lightest is again some some functionality which is not needed but yeah if it's there it will definitely make a customer happy so there are one two more which i'm not able to recall right now but i think in canada model we have these uh four thresholds that we use which my product owner uses in some of the products is not very common but yeah this is used

in some of the products to order or prioritize the user stories no shoes thanks thanks bring up all that so let's talk about uh technical depth what is technical depth and why it's accumulated over a period of time if you want to share your thoughts okay so technical depth is a functionality which although the developers have delivered and they have been passed on to the production or maybe for the end users to use however it was kind of a band-aid fix or maybe the it was not done in a very good manner the code was

not perfect and maybe because of some tight deadlines and it was because of a high urgent business need the developers have delivered the functionality for the users to use however there are some uh technical uh glitches and that the performance may be low so they need to work upon it in future and that is called a technical debt so over a period of time if we do not work on those technical depth and uh they keep on adding up into our product this will increase the uh or maybe sorry reduce the quality of our product

in a later stage but yeah to explain our technical debt it is something which is not delivered perfectly and the code needs to be refactored in future that is defined as technical debt so as a scrum master how we can uh help our team to reduce this technical depth i think a follow-up question for you yeah so as a scrum master uh i need to ensure that these are not piling up the technical debts are not pining piling up and maybe we can spare we can i can encourage the team that during our planning we

can spare some of our capacity to work on these technical tests so these are not keep on piling up and we are keep on improving our product uh sprint by sprint so i think as a scrum master to coach and guide the team that um instead of just taking the new work all the time just spare at least maybe 10 of the capacity to work on those technical depths so we can improve the performance of the product at the same time true true thanks yeah okay thanks uh think about that yeah okay uh let's talk

about uh conflict management so let's assume that as a scrub master there is a situation where your one of one of your developer is blaming other one because you guys are not able to finish one or two user stories on time so how you work on this kind of situation sure so handling conflict management is one of the important role that is played by a scrum master as a scrum master you need to first acknowledge the problem that yes this is something happening in the team and we first acknowledge we should first acknowledge the problem

because uh just leaving it as it will increase the problem in future acknowledge the problem and then just talk about it whenever you get that opportunity maybe if it's related to a particular individual or two of them just set up a meeting with them talk about it openly or if it's within the team we can talk about it into the rest retrospective uh considering this particular question where there's a conflict between two team members who are playing playing games so we can as a scrum master have a 101 fill with those team members talk about

the problem and as a good scrum master listen to their perspective one by one that what is your point of view in this term and what is your point of view and then coming out to a common ground that what is the best possible solution we can do to avoid this and uh getting their suggestions that what do you think is the right approach and involving them in the solution making um is something we can do as a scrum master and apart from that once we are able to you know talk about it and solve

this problem guiding them that this is not a right approach and we should take the ownership of the work we are doing rather than blaming somebody else for the problem that is happening and then telling them that you should go with the scrum values and you should be courageous enough to talk about what is your problem you can talk about it to the scrum master to the team members and then follow another principle which is respect we should respect each other in the team so again taking the ownership so guiding the team in the right

direction and coming to a common ground a common consensus during the meeting would help the team resolve this conflict okay thanks uh think about that okay so uh what is dor and dod and if you can just give example like what consists of dor and dod yeah so d dor and dod in terms of scrum is definition of ready and definition of done these both are basically the checklist which tells us that let me first talk about dor the urs definition of ready which is a some of the items in the checklist that needs to

be completed before we can say that functionality can be taken up for the or the user story can be taken up for the sprint because it is uh all of the items in the dor definition are have been checked that is called definition of ready and some of the items in dor can be like everybody in the team has been able to understand the functionality pretty well there are no dependencies attached uh the acceptance criteria at least one of the acceptance criteria has been defined for the user story and then the user story is following

the invest criteria the uh the story has been estimated and like dependencies have been removed yeah some of these can be the items in the in the definition of ready checklist similarly dod is definition of done which is again a checklist of items which needs to be marked or checked before the developers can say that the user story has been completed and it can be moved to the production um and again if this definition of ready is not done we cannot say that you the user story can be moved to release or it can be

released to the customers to use and some of the examples that can be some of the items in the dod can be that the qa work has been completed means the critical scenarios have been tested all of the acceptance criterias that were defined for the user story has been met uh the critical defects or bug have been fixed the code has been committed to the server um yeah i think these are some of the items that can be in the definition of done and everybody sorry every team can define their own definition of ready and

definition of done checklist so it varies from project to project and it's not against static we can change its dynamic we can change it anytime um within the project based upon the requirements or new functionalities that are coming in the project okay thanks uh okay so let's talk about uh cross-functional team so what is a cross-functional team okay so a cross-functional team in general towns is a team which uh in which uh all of the team members have different uh functional specialist specialism so they possess different uh qualities uh i mean we say the technical

skills uh in terms of a scrum framework i would say a cross-functional team is one where uh the development team have different uh specialism to perform so if if a developer is there he um he's a sme or a subject matter expert you know in one of the language so maybe java so he's a good coder in java and that's his specialization however he has that uh ability or skills to also do some basic testing and so that even in the absence of a qa the team is not stuck and they are still able to

perform their task and they are still able to deliver the functionality that they committed to uh yeah i think that's a cross-functional team and as a scrum master we should ensure we should ensure that our team is cross-functional we should give the team that opportunity where they can learn different skills uh maybe we can conduct those workshops or those training sessions where sme can give or present that knowledge to other people in the team so that everybody in the team is aware that what is happening a developer perfectly understands what are the things that are

being tested similarly our tester has an idea of what has been coded and what are the functionalities that have been used and that's how a cross-functional team is there in a scrum framework and i would also like to add that a closed functional team really helps the team to collaborate they are more innovative they are able uh they are able to deliver their uh you know product or the functionality faster the delays are less so a cross-functional team with the help of a cross-functional team we are able to deliver our sprints or functionality faster faster

rather than a team which is uh you know expert in only one area so we have dependencies on other people and that's how close functional teams helps in a scrum framework okay thanks think about that okay so as a scrum master what do you do differently to make your retrospective more effective or more fun sure so retrospective is one of the events in the scrum framework and it's a it's a meeting or it's a ceremony where the entire team meet together and they talk about what what how how well we did as a sprint what

went well what did not went well and what is it that we can improve into our future sprints that's all is covered in a sprint retrospective so we use inspect and adapt in terms of the processes or tools or individuals now we do not talk about the product during this meeting we talk about processes and tools because for product we have a separate meeting which is called sprint review so in sprint retrospective as a scrum master i ensure that all of my team members are openly talking about uh what did not went well i give

each of them the opportunity to talk so maybe creating that kind of environment where people can talk to each other and they do not feel that closed uh creating that kind of open environment where people can share their views and adding value by whatever suggestions they have given taking those pointers uh prioritizing them that what is it that we can implement into our next print so maybe taking those two three pointers and then following up into the next print so that people really see value out of the retrospective meeting that yes this is some of

the idea that i gave and it was appreciated and we have started to work upon it we have started to improve upon that so that's my approach in conducting the retrospective meetings apart from that i prefer to use different techniques at different times rather than just following the same agenda every time or maybe using only one of the method for doing retrospecting every time using different techniques gives encouragement to the team to participate and again making it more interactive in terms of giving sometimes appreciation to the people who have done well or coming out with

the coming out with some rewards and recognition within the retrospective this really helps to make them meeting more collaborative and engaging true sure okay thanks springer for that okay so could you uh tell us few differences between the latest version of scrum guide versus the previous version so we have in 2020 right yeah so in 2020 we came out with our latest version of scrum guide by jeff and ken and i think uh in the latest version uh the number of pages has in this scrum guide has been reduced i think the intent was they

want to make it more simpler now and so that people can understand the from framework and note adding more and more things into the framework rather simplifying it is something that has been happened apart from that there are few changes that uh i think i know have noticed in the previous version versus the latest version first one i would like to point out is that each of our artifacts which is product backlog string backlog and the increment has been tied to a commitment in our latest version of sprint scrum guide so product backlog has a

commitment that it is tied to a product goal similarly sprint backlog is tied to a sprint goal and the increment is tied to a commitment that it will add or deliver value to the customers apart from that there were other changes like in the previous version we used to call the roles as product owner scrum master and the development team in the latest version we call them product owners scrum master and developers so the third role which is development team has been changed to developers now and uh to make it more clearer the purpose of

this is to ensure that we cannot have teams within teams so instead of calling it as the development team we now call it as developers and these developers include everybody and anybody who is responsible for creating that functionality it can be a business analyst or a ui developer or a tester um or yeah so whoever whatever the role we have into the the team we call them as developers apart from scrum master and product owner along with that other changes that have observed is that in the previous version the scrum master role is called as

a servant leadership role the term used was called as servant leader now in the latest version it is now called as leader who serves and the reason behind is to ensure that the scrum master is not considered somebody who is just a facilitator or somebody who is a admin scheduling meetings for the for the teams but uh there are some other terms that are there for the for the scrum master like he he somebody who is a leader who is coaching the team who is guiding them to follow the right direction during the sprint he

is giving them ideas that what all we can do to make our teams more self-sufficient and self-organizing so that's how the term has been changed from servant leader to leader who serves i think these are some of the ones that i can recall i there are some others also that's okay okay thank you thanks for that okay so uh according to you what's the difference between a capability and a feature and if you can just give some example that would be great okay so capability and feature other terms i would say not from the scrum

framework but rather from the safe which is scaled agile framework uh capability let me think of a good example which i can share which will help people to understand it um so for example if we are developing a software and within that the capability would be that it it can be delivered on multiple browsers the functionality should work on multiple browsers that would be called as a capability and feature is something which is the actual functionality which is working so if we are developing a login page uh what all the features would be there there

will be a user name there will be password and then there'll be submit button which will be press which will we will press to get that functionality work that would be a feature and capability is um will this functionality or feature will work on different browsers i think that's how i would like to explain capability and future and yes these are safe terms and not uh something we can see in scrum framework hey thanks brinker that's okay that's okay and uh what about uh impediments so could you just give us some example uh based on

your past experience that as a scrum master how you resolve some of the impediments for your team sure so as a scrum master one of the basic responsibility is to solve employment for the team or at least helping the team members so that giving them right direction with the help of which they can resolve that problem some of the examples that i can share about impediments is that there was a situation during a time when we were working on a functionality and for testing that functionality we needed to use a third party server and that

server used to get uh down many times and the team got stuck there they were not able to proceed with the testing and due to that uh no this was delaying our work a lot so as together i call up the team we talked about this problem that how we can really work upon that and there came an idea where we talked about that how we can really resolve this um somebody gave that idea that if we can create an automated script which will run and which will tell us that server is down and there

will be a jira ticket created automatically and it will be assigned to the owner who is responsible for fixing the problem and it will be communicated to the entire team at the same time by an email that yes this is not working and there is a chat defined for this that we need to fix it within three hours so this is how this is one of the idea that came out that maybe we can create an automated script so as a scrum master i suggested this idea in a bigger forum and we finally implemented this

idea which worked for us with the help of it we were able to minimize our delays because uh since the ticket was created uh the problem was solved in a much lesser time and the idea was really appreciated that if it was even implemented at uh it was implemented in many other teams and it is now very well working in the organization so this was one of the area along with that another example of impediment is that suppose somebody and the developers team is facing challenges with some of the technical work so guiding them if

i myself cannot solve that problem being a non-technical person i can guide them to the right person i can you know conduct that i can schedule that meeting with the i can talk to the person who is the right person to help in that technical skill to my team so facilitating that meeting or maybe scheduling that meeting getting the time from that person and then in a way helping the team so that they can uh work on that problem they can get the idea from other person and they can work on that solution is something

we can do and that is one of the impediment okay thanks uh thank you for that okay so this one is again an interesting one the question is what is your x factor or why we are going to hire you so how to deal with this kind of questions so x factor we can explain it in the terms of the achievements that we have done into our role as a scrum master what i what i do as a scrum master is that or what i would say my expected would be that i keep looking for

forums or the opportunities where i can showcase my knowledge about the scrum framework so that i can help apart from my team i can help other teams in the organization who are still not following the framework so guiding them or coaching them that what is this framework all about and what are the kind of projects where we implement it and how will it help the organization as well as the team to build the right project which will give a good you know business value to the organization and it will give the opportunity for the team

members to attend themselves uh this is a process which uh with the help of which we can be transparent enough and we we can follow inspect and adapt so yeah that's one of the way that we can say that looking for various forums where i can showcase my knowledge about the framework and helping other teams adopt the framework apart from that um explaining that with my current team i have been able to make my team mature enough that they are now self-organizing they are able to manage their work within themselves and with the help of

which there is a least involvement of me as a scrum master now even if my absence they are able to facilitate all the ceremonies they are able to work upon their defects during the time downtime they are able to come up with certain ideas or suggestions during the retrospective meeting so this is a way i can see that my team is growing they are maturing from gnoming to performing now and i think that's one of the things i i would say as a achievement for the scrum master and these are these are some of the

good qualities that scrum master should have and basis that i think i am a good fit for the organization yes you are that's why you have 10 of us okay okay thanks a lot i think yes we have covered all our remaining questions as well so thanks again one more time and it's not like this is going to be a just one more session obviously we are going to uh invite you again and again uh maybe in in future when you settle down in your new job so thanks again and uh best of luck yeah

thank you thank you so much for the time thank you