Transcription
Hello everyone, welcome to our channel career talk. My name is Sur Sharma and I'm an agile consultant based in Netherlands. And at career talk, we invite industry experts from around the world to share their real experiences with us.
So today, we are going to discuss 15 Scrum Master scenario-based interview questions shared by one of our community members who recently attended a couple of interviews at LTI Mindtree, Wipro, and Cognizant. And to help us, we are glad to have Ashutosh Agraal with us. He is working as an Agile Project Manager at Capgemini. But before we start, please subscribe to our channel if you appreciate our quality content. Don't forget to hit that like button and please share your thoughts in the comment section. We love to see your comments. And uh, yeah, also make sure to check out our exclusive interview questions shared with our silver and gold members. So if you are not yet a YouTube member, you can join at a very small fee. Apart from exclusive content, you will also become a part of our discussion group and WhatsApp job community. Okay, enough promotion, let's move on.
All right, let's get started. Hello Ashutosh, thank you for joining us today. Over to you, Ashutosh.
>> Hi, Sunand. Thank you. Uh, like it is a privilege to join Career Talk's podcast and uh, to talk with you face to face because I have been listening to this podcast and these videos of yours, and this has helped me a lot in my preparation of interviews. And now I am again coming forward to give something back to the community. So that is, that is a privilege. Thank you for that. We can, uh, start, uh, our session.
>> Okay. Wonderful. Okay. So here comes the first question. Um, pretty common. What do you do as a Scrum Master? So you can describe what are your day-to-day responsibilities? How your day looks like?
>> Okay. So for this question, uh, what I have answered generally, and it has come pretty out well, that, uh, as a Scrum Master, I divide that thing into two parts. That, uh, because most of the organizations are working in a SAFe environment, uh, nowadays. So I tell them that it would be divided into two parts, as in, say, like a Scrum Master on a team level and a Scrum Master on an ART level. So on team level, I tell them my day-to-day activities would be connecting to stakeholders, connecting to my team members if they face any impediment, guiding them about the Scrum and Agile practices, um, facilitating all the Scrum ceremonies that would be over a sprint, like a sprint planning, uh, retrospective sessions, sprint demos, um, daily stand-ups, and backlog refinement sessions. Apart from that, when I talk about, uh, uh, SAFe scenarios, like what we do in an ART, I tell them that I would be handling the dependencies with other teams in SoS, that is Scrum of Scrums, for the audience. Then I would be syncing up with other stakeholders. Suppose if there are some dependencies that are not answered in SoS, and I have to connect with some Product Owners, Scrum Masters out of my team, I will tell them that I will be connecting. I would be doing capacity planning for my team in PI Planning. So I would be representing, uh, as a facilitator for my team in PI Planning also, uh, doing capacity planning, uh, conducting breakout sessions, and all these stuff. Then, um, I will tell them that I would also be coaching my team members to align their, uh, sprint goals to PI objectives. So that, like, if they are working in a SAFe environment, they should be, uh, able to, um, you can say, able to align those sprint goals, uh, wonderfully with the PI objectives so that, uh, they, they could be in sync with the ART. Okay.
>> Yeah. Over to you, Sunand. That's it.
>> Okay. Thank you. So you mentioned about PI Planning, right? So let's say your organization is planning the next PI with multiple Agile teams. So is it possible for to explain, um, step by step, how you would prepare, how you conduct, and how you're going to do a follow-up on a PI Planning? So how you're going to manage all these risks, dependencies, and commitment?
>> Yeah. So, um, yeah, let me start with the pre-PI Planning phase because, uh, most of the, uh, most of the answer givers or most of the people missed that, you can say, pre-PI Planning phase. And I have cut it down to a short form that I want to give to the community, that is MESSO. I call it pre-PI Planning, short form is MESSO. M for, uh, any Miro or Mural board that your team is going to play with at the time of PI Planning. You will make sure that the board is in place. It should be handy, and your team should be able to use that board. It should not be like that that you step into PI Planning and nobody knows how to use that board. Second is E. E is for Epics. You make sure that your epics are aligned. Uh, if, like, it may be possible like some of the epics would be there in your, if you are moving from one PI to another PI. So, uh, the, there should be some clarity of epics to your team, or at least you and Product Owner should be discussing on what epics should be taken into the PI Planning, what is the agenda. Third is S. Oh, sorry, third is S. S is Sprints. I make sure that all my sprints are created into the Mural board or the Miro board that we are using for collaboration in PI Planning, and those sprints should be, should also be, uh, created in Jira. Whatever tool we are using for management, mostly industries are using Jira. So I would take an example of Jira, that your sprints should be created there. Then C is Capacity Planning. Your capacity planning should be in place before you step into the PI Planning. Let it be a guesstimate, because sometimes we are not able to, um, predict the emergency leaves and so on. But yes, uh, tentative capacity should be there. O stands for the Older Epics. Older epics means that some epics that drag from one PI to another PI, then again, you have to check that whatever has been completed and what we need to complete, and should be prioritized that in the coming sprints or not. So that is a short form that I have made, uh, as a pre-planning, pre-PI Planning, uh, abbreviation MESSO to remember, uh, to remember this, this answer. Then, uh, moving to actual PI Planning, these, these are the prerequisites of PI Planning. And then when we move into the PI Planning, we start with a kickoff from the business team, where, uh, business stakeholders tell us about the business functionalities they are expecting for a quarter. Those business functionalities make the basis of discussion for, uh, product management team and the architectural team. Then product management team tells us the, uh, functionalities, uh, they want to, uh, inculcate, uh, within the quarter. Suppose if they want to design an app of, uh, online food delivery, then they would be including some, um, payment check-ins, some gate, like payment gateway, security of payment gateway, how, uh, we are com, like, how we communicate with all the, uh, restaurants and hotels, how the customer will be getting the discount. So all these functionalities, the list would be there, and they will be broken out into smaller functionalities later on in breakout sessions. But yes, uh, for an example, I just gave an example of a food delivery app. So this would be the basis of again, a discussion where architectural team would tell us what technologies, what, um, backends, what, uh, uh, you can say, uh, connections or, uh, infrastructure, I would say infrastructure, storage, we would be using in terms of technical terms. Then this business, functional, and technical base would make, uh, the basis of maybe 8 to 10 prioritized features that would be discussed along with all of the teams of the ART in, in a, in a common meeting, and then along with our PO, uh, we would discuss that, and we will go into the breakout sessions. Like each team would be going into the breakout sessions. They would be breaking those features into smaller stories, smaller functionalities that maybe those smaller functionalities may be containing one or two stories later on on Jira. But these would be broken down or decomposed into smaller functionalities. We would be giving a guesstimation also that okay, if we, if we are a mature team and we know that for a particular capacity, our velocity is this much, we would be giving a rough estimation of story points also. Uh, but yes, this story point estimation would be revised at the time of sprint planning. But for the sake of prediction and, uh, clarity that how much work we can take, we would be doing that. After one day or one and a half day of this, uh, breakout sessions going on, we would be taking a review from the management team for, uh, for our breakdown of the stories. Apart from that, parallelly, we would be, uh, when we were planning about about the stories, we would be figuring out the risk and dependencies. Uh, I would firstly talk about the dependencies. So dependencies, what we do, uh, generally on the Miro or Mural board that we are using, we call out the dependencies for different teams. Uh, say my team is A. So if I'm dependent on team B, C, D, and so on, and mark it with a color code, red, green, or amber. Red being, uh, that is not being addressed. Green, that is being addressed, or we see that it is a polar dependency that can be addressed. Amber means that it is something in between. It is not, it is not burning, but it has not been addressed. And, uh, risk, we use, uh, ROME technique, uh, again, like, if there is a risk, we would like to categorize it at, uh, on the basis of ROME: Resolved, Accepted, Owned, and Mitigated. Resolved being that it is already being taken care of, and nothing can, nothing would be required in future. Accepted means that it is accepted, but we are not doing anything because the likelihood, maybe the probability is very low of that risk, or the impact is very low, or the cost is very high to mitigate that risk, and we don't think that it is fruitful to, uh, waste our effort and time on that risk. Um, then third one is Owned, that is owned by a team or, uh, owned by a, uh, individual member of the team. So that he should be, he or she should be working in future and keeping an eye on that, monitoring that. Negotiated risk is again slightly different from resolved. It is negotiated, but there is a 1 or 2% chance that it can happen. So we have to monitor that regularly, and if there is a date, uh, for that, that when we will be checking that, we will point out the date and the owner of that risk again. So this is how we, uh, manage risk and dependencies. Coming back to, uh, the review, we take the management review, and then if everything is good, we also take a confidence vote at the end that how our team feels, how much confidence is there within each team member, and if we think that any team member is going below average or whatever the norm we have set up, that okay, um, only, only one person can, can be there in the below, or sometimes practically, if there is a below average vote, we do it. We review our planning again. Ask the team member very frankly, very transparently, that why and how do you feel that your confidence vote is, uh, not so much, and what, what is the area that you think that can be improved to increase your confidence. Then after that, uh, we again go to the review for the management team, and then we close the PI Planning. After PI Planning, we set up, we, uh, we finalize, or maybe the final stage of this PI Planning would be setting up the PI objectives. Mostly, uh, 70 to 80% should be committed objectives that we see that okay, these are the committed objectives that have been agreed by team members and the stakeholders. Uncommitted PI objectives, I would say that, uh, we see some risks are there, but we want to develop it with the time, or we want to develop it when we, uh, finish all of the PI objectives within the quarter, and we have some buffer time, we can look upon that. So this is how, uh, PI Planning works for me. Uh, over to you.
>> Wonderful, Ashutosh, for that detailed explanation. So that's good.
>> Okay. So, uh, you mentioned so many things. I have just a small follow-up question that how you, as a Scrum Master, calculate your team capacity at team level, at program level?
>> Okay. So I would say that, uh, there are different methods for capacity planning. Um, if the team is following a pattern, I would like to follow this pattern. But, uh, personally, my pattern is, take the mandates. Suppose my team, I would take an example of 10 team members, and my sprint is of 10 days. So 10 team members for 10 days equal to 100 man-days, like 100 working days, 10, 10 team members, and 10 man-days. Then, if suppose two persons are on vacation for 3 days, 2 into 3, six. Then I would be cutting down six days from my 100 days, that comes out to be 94 days. Suppose there is one public holiday for all of the team members. So 1 into 10, again 10. So that would be minusing 10 again. So 94 minus 84. So 94 minus 10 is 84. So 84 man-days is my capacity. In some teams, or many of the industries also calculate this capacity into hours. So I would again extend this calculation, 84 man-days into the working hours that would be suppose, uh, 8 working hours. So 84 into 8, I'm not doing the calculation, but it would be coming around something.
>> So industry practice to take eight, or sometimes it's six?
>> Um, sometimes eight, sometimes it is 8.5, something is nine. But yeah, mostly we take an eight. But I'm not, I have not considered focus factor. I will be coming to that. So it is like, uh, it is the actual hours, not the real productive hours. But yes, like, if you want to take real productive hours, we would be taking again a focus factor of 80%, like cutting down 20% from this actual capacity for day-to-day, um, Scrum ceremonies, uh, day-to-day ad hoc requests, day-to-day calls. So I would be cutting them down. Some people, like I can say that some people cut it down at the initial stage, they take, they don't take 8 hours, they directly take 6 hours, that they have cut it down around 20% of time. So the calculation is basically same, either you cut down that time in the Scrum ceremonies initially, or either do you cut down that time at the end as a focus factor.
>> Yeah, over to you.
>> Okay, that's good. Great. Uh, thanks, Ashutosh. So friends, I hope you are enjoying this session. We are halfway through our session, and, uh, I request you to please take a moment to hit the like button. If you're not subscribed, please do so. Take a moment. We are just taking a pause so that you can hit a like and subscribe. Okay, now that you have liked and subscribed, let's move on to our next question. And next question is regarding velocity. So it's a little tricky question. So why do we calculate velocity if we have capacity in a PI plan?
>> Yeah. So, yeah, I have, uh, gone through this question many times in the interviews because it is, as you said, Sunand, it is a tricky question, and sometimes we just don't know like how to answer this. Yes, capacity planning is there, and velocity is also needed. So how I have answered, and it has gone very, very well, that capacity and velocity planning, both are needed because capacity gives us the actual hours, uh, for the predictability. But yes, if we are a mature team, and we know that, okay, if we are, uh, for 500 hours, for an example, for 500 hours, if my team is, uh, uh, delivering around 45 to 50 story points, and in one of the sprints, my capacity is only 400, then I would be, uh, in a predictive, uh, phase that my team would be delivering around 36 to 40 story points. So that is a unit-based method that we are applying. So yes, this is not a hard and fast rule, and we are, as a Scrum Master, we are not imposing our thoughts that, okay, in 500 hours, you people are doing, you people are delivering 50, now in 400 hours, you have to deliver 40. No, that is not the scene. But yes, for the predictability sake of it, or you can say, to, uh, to get a rough idea of predictability, we do the velocity, uh, we, we take into account the velocity in the PI Planning. But yes, this velocity can differ because we are not really, uh, pointing the hours exactly to the story points. That is a bad practice. Though, if the team is not very mature, we sometimes tell them that, okay, you consider one day, one day of work as a one story point, sometimes in practical scenarios. But yes, we are not directly, that Scrum also doesn't suggest that you should be pointing those, um, hours directly to the story points. So that is how we should not be doing. But yes, um, there is always a predictability in the mind as a Scrum Master that how much my team can take up. So that they should not feel burned down also, like it is not like that I am only, I only want them to work. I also want them to, uh, to save from burning out. So there should be a, uh, guesstimation of predictability. So that is, that is why velocity planning is also necessary. Yeah, done. Thank you.
>> Okay, that's good. Okay. So let's talk about some of the dependencies. So if you can share how you are going to manage dependency in your previous organization or in your previous, uh, project in a SAFe environment, that will be great. If you can share a couple of, you know, scenarios and the dependencies which you have found out and how you are going to overcome those dependencies.
>> Yeah. So as we discussed in the PI Planning, Sunand, so the first step is to figure out those dependencies at the time of PI Planning. So we would be having some dependencies that are clear from the PI Planning, or maybe some dependencies would emerge at the time of our sprint planning or when the sprints are going on. So those dependencies, uh, how I have managed them, divide into three small points. First point is, uh, participating as a Scrum Master in Scrum of Scrums, or if there are more calls, maybe in some scenarios, there are dependency calls weekly. So Scrum of Scrums and dependency calls will make sure that you talk about your dependencies with other teams, and you also answer the dependencies that are, uh, marked to your team, like some teams would also be dependent on your teams sometimes. So for this, we use, in, in the team call, we use a board, maybe we use a Mural board, and that can be any board, collaborative board, and it is a board like a chessboard, if you see, like we have eight into eight columns. So suppose, take an example of eight teams, eight teams could be dependent on other seven teams. So team A can write down the dependencies for team B, C, D, and so on. Team B can write down dependencies for B, C, oh, sorry, for A, B, A, B is not there, C, D, E, like that. So that would be discussed in that call. Second point, those dependencies should be mapped. As we are working under the same umbrella of the ART, we can also, we should also link these dependencies on Jira. Suppose my story is dependent on some other party, uh, party story, some other team story, then we should be doing the proper linkage so that if their story is going to finish in sprint two, and I, their story is input to my story in sprint three, I would be aware, uh, of what they are developing, and if, if that is not going in sync, I should be, uh, asking them or taking follow-up with the Scrum Master of that team. Third is, uh, participating in every sprint demo. It is not like that you are accountable in an ART for your demo. You should be participating in demos from other teams so that you keep an eye on what they are developing. Suppose it may be possible that you are demanding a story completion in sprint two, in sprint two for a sprint three, but there are some stories that they are not completing in sprint one. So you would be aware that, okay, they are still lacking in sprint one, then they would not be able to deliver, uh, those stories in sprint two. So when you take into account and you follow up with them, and you would attend them all the sprint demos from all the teams, you are aware what is happening, uh, within the ART, not only your team. So that is how these three points I take into account for, um, managing the dependencies. Yeah, over to you.
>> Wonderful. Wonderful. Great. Thank you. Okay. Uh, let's move on to our next question. So what are the different factors or the parameters do you consider while you're estimating any user story?
>> So while my team is estimating the user story, I would say that is again a tricky question. When somebody asks that you are estimating a user story, sometimes people start to answer that, okay, while I am estimating the story, the Scrum Master is not estimating the user story. First of all, it is the team effort. So whenever this question hits you in the interview, you should be saying that not only me, but my team would be estimating the story. And for the factors that, uh, uh, the factors that I consider, uh, for the estimation of user story would be the amount of work, like what, how big is the story, what is the ask of the story, the amount of work is needed, the complexity of the story, how tough, how difficult the story is, uh, that is the second point. The third point is risk and dependencies involved. Sometimes we have also have to give a buffer because sometimes we are not sure that these dependencies would get resolved on time or not, or this risk would appear, uh, suddenly. So these, these three factors, the amount of work, uh, the complexity, the risk, and dependencies would be taken into account while estimating a story. Yeah, finish.
>> Wonderful. Uh, thank you, Ashutosh. Great. Okay. So now the last question for the day. How do you coach a team as a Scrum Master? So, so let's say your team is new to Agile, or they're struggling with self-organization. So how you are going to guide them? How you are going to create that Agile mindset? How you are going to help them with the collaboration, or how you are going to help them with specific? Do you use any specific coaching techniques, or how you are going to do that as a Scrum Master?
>> Okay, again, I divide that answer into two parts. Uh, as a Scrum Master is a servant leader. So I believe strongly that you can't serve a team as a servant if you don't lead them as a leader. You have to take out the shortcomings or the, or the, you can say, their weak areas. So you have to talk with them. You have to identify before coaching, you have to identify where they are lacking, where they are standing at, at the platform of Agile and Scrum, or maybe something else. So it may be possible they are lacking of competency. They are lacking of knowledge of estimation. They are lacking of Agile and Scrum knowledge. They are lacking on the understanding of Definition of Done, Acceptance Criteria, or maybe they are not lacking, they are, they are not updating Jira. They are not, uh, uh, having some family issues. Anything could be there which is hindering their performance at the level of team or at the level of ART. So I will make sure that firstly, I diagnose this that where they are lacking, what they need. Then I will make a roadmap, a plan that, uh, accordingly, where they are standing, that, okay, my team needs this, this, this, this training, and this coaching needs to be, uh, needs to be provided to them. If I am able, I will, uh, surely, uh, according to their availability and according to the bandwidth, I will make sure that I, uh, plan some sessions, maybe weekly for 30 minutes or 40 minutes with them. If there are some, uh, pre-recorded trainings in the company portals, I will guide them to them, like, uh, they can also do those trainings. Uh, if there are some external help required, or there are some external trainers, or external certifications, certifications are required, I will take into account and I will ask my team members and inform my stakeholders accordingly that this is the place where my team is standing, you should be expecting my team to learn gradually for the Agile and Scrum, you should not be thinking that they are very mature. So this is how I, like, this is how I would be doing some coaching. Apart from these, I should make sure that my team follows Scrum values very transparently, like, speaking in all of the calls, they should not be hesitant, they should be, uh, open about saying no to a story if they don't understand it, they should be open about asking the right questions, they should feel that they are being heard. If they feel they are being heard, that develops a trust. They would come with their silly questions, and sometimes the most silly question is the most important question.
>> Take no silly questions.
>> There are no silly questions. Absolutely.
>> Okay. Great. Uh, wonderful, Ashutosh. I think we are good for this. I think we are already crossed half an hour session. So thank you. Thank you all of you for joining us today's session, and we hope you found it helpful and informative. And if you enjoyed this session, please don't forget to like and subscribe. Second part coming soon, so don't miss that. Uh, we hope to see you in our next session. Until then, take care. This is Sunand Sharma signing off along with Ashutosh. Thank you. Bye. Thank you, Ashutosh.
>> Thank you. Thank you, Sunand.