Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. This episode is a previous recording of our live ask professional scrum trainer series, where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Good morning. Good afternoon. Good evening, wherever you're located today, welcome to today's Ask a PST session. My name is Lindsay Velecina and I will be your moderator today. And I am very lucky to have one of our professional scrum trainers with us Simran Nagrani. She is here to answer any scrum questions that you have. So start thinking of those as we go through some quick items here before we get started. So just a little bit about who scrum.org is. We are the home of Scrum. We were founded by Ken swaybar in 2009. And we our mission is to help people in teams solve complex problems. We offer training and certification and professional Scrum, along with numerous ongoing learning offerings that are free on our website. We have a lot of free content, including learning paths, and webinars like this one and other resources. So please feel free to check those out. You know that learning goes beyond the classroom and we'd like to offer different ways to do so. So with that, I would like to hand it over to Simran to introduce herself before we dive into some questions.

Simran Nagrani: 1:46

Thank you, Lindsay. Hello, everyone. My name is Simran. I'm a professional scrum trainer with scrum.org. One of the approximately 350 people across the globe licensed to teach scrum.org workshops. I am passionate about Scrum. I got introduced to scrum in the year 2009. And the way scrum changed the way I thought about work I dealt with work. I felt that it is not just me who needs to benefit from Scrum. My team, my organization and right now. I'm serving the community with the knowledge of Scrum. I am, also the co founder of a young company called Agile for growth we were founded in the year 2014. And our only focus area is scrum training and agile coaching. We offer scrum training and agile coaching across the globe. So I would love to see you hear from you one day in one of our workshops. That's a little bit about me.

Lindsay Velecina: 2:50

Thanks, Simran. Okay, so we ask that you all utilize the q&a box at the bottom of your screen to start entering your questions for Simran. And we will kick this off. So this first question here comes from Andreas, and does all work in the sprint backlog needs to be related to the sprint goal?

Simran Nagrani: 3:14

Wonderful question on this? So the short answer to that question is no. All the work in the sprint backlog doesn't have to be something that aligns to the sprint goal. But definitely every sprint has a sprint goal, which is your business purpose of why the work why the team is working together this sprint that should drive what is the most important stuff that we are going to focus on this sprint? Right. So definitely we do have a sprint goal. But there could be items like addressing some kind of technical debt. Is that aligned with a sprint goal? Very likely not. Right? Is it part of the sprint backlog? Yes. Is it part of the work that the developers are going to do this sprint? Yes, it is. Yeah, so all the work in a sprint backlog doesn't have to align with the sprint goal. There could be part of it. That doesn't align. I hope that answers the question.

Lindsay Velecina: 4:19

Okay, great. Thank you. That was a good explanation there. So we have questions. A couple questions have come in around estimation. This first one here, what's the most effective way to transition from time based estimation to story point estimation?

Simran Nagrani: 4:39

All right, wonderful question one more time. I would like to first take a step back and help all of us align on why are we making this transition in the first place? So if you go through research, research says that human brains are not designed to do absolute estimates. What does that mean? It means that if there was a whiteboard, I draw a straight line on that whiteboard. And I asked you, how long is it? The level of variation in the answer that I get from a class of let's say, 100 people, is very, very high. So human brains are not designed for absolute estimates, absolute guesses. What human brains are good at, is relatively estimated. What does that mean? It means that instead of drawing a straight line, if I were to draw a rectangle, and I asked you how long is one line with respect to the other, the level of variation that I get from a class of 100 would be lesser than the previous. And that's why a whole lot of teams that use Scrum, use relative estimation techniques. Right? That's the reason why we use relative estimates. Now coming back to your question. The common of these relative estimation techniques that are used are store story points, where we use a Fibonacci series to assign a number against each product backlog item. And this number is assigned based on the complexity of the work based on how difficult this work is, what is the integration that is required means based on the amount of effort that will be required in order to get this item done. And these estimates are offered by the developers. It is not the scrum master, not the product owner, not anyone else. Because they are the ones who are going to work on this item. The developers come up with a single number against each product backlog item. I also want to emphasize the fact that any kind of estimation is a complimentary practice. It is not part of core Scrum. So if you open up the scrum guide, you look for this term, you will not find it. It is something that a lot of teams do very, very commonly. But it's not part of course. I hope that answers that question on estimation.

Lindsay Velecina: 7:16

Great, thank you. And there was another question that was super similar to that that came in from Nicole and Nicole, if that did not answer your question, please let us know if you want to dive deeper on that. But it was very, very similar question. So this next question here. So who is responsible for measuring the progress of the sprint?

Simran Nagrani: 7:39

Who is working in the sprint is the entire scrum team? Right? However, it is the developers who are primarily working from the sprint backlog. So if your question is who is monitoring the progress, who's making sure that things are moving? It is the developers who needs to know what is the progress it is the entire scrum team, sometimes even beyond? Because one of the purposes of creating those sprint backlog is to create that level of transparency on what is the progress we have been able to make. Creating transparency is the accountability of the developers. If they need help, sure, they can reach out the scrum master and ask the Scrum Master. How can we create transparency about our progress? There are different ways of doing it. The scrum master may introduce a technique or two.

Lindsay Velecina: 8:31

Yeah, very true. Thank you. Question from Marco here during an agile transition. What do you do when the PIO and the development team show skepticism and working in Agile?

Simran Nagrani: 8:49

Thank you for that question, Marco. And this is not uncommon at all I'd like to share with you that this is you are in a situation that a lot of teams that a lot of organizations are why because change most of the times is not comfortable. When you're transitioning from what you have been doing so far, to something new, very likely, there will be people that will start becoming uncomfortable. What you got to do as Scrum Masters or scrum practitioners, agile practitioners is help everyone understand what is in it for them. Why are we doing this change? What how is it going to benefit? The team, the organization, the developers who are working, the product owner? What kind of white? What kind of control does scrum offer to the product owner? What kind of control does develop does scrum offered to the developers what kind of decision making is now in the hands of the developers? So I think that's where the education All scrum needs to begin. I hope that answers the question.

Lindsay Velecina: 10:05

That makes a lot of sense. Thank you. So this question from Tracy, these questions, by the way, are all across the board. So I'm gonna be jumping around different topics, which is, which is fun. So what is your perspective on a healthy backlog? How much? Let me try to read this correctly. How far ahead should a team be? That is on a four week sprint cadence? So how far ahead should a team be? If the team is on a four week sprint cadence?

Simran Nagrani: 10:45

Awesome question again. My answer to that question is going to begin with it depends. It depends on how huge is your product? How many teams are working off of that product of that product backlog? So to say? What is what does the product roadmap look like? Are there any specific dates that the product owner has in mind to make some value available to the end customers? Typically, if you have a product backlog refinement that is going on every sprint and your team is so the developers and the product owner and having discussions about what is likely to come up in the next sprint two or three, my recommendation is don't go beyond three Sprint's of having these discussions, no product backlog refinement session, because things can change, they may evolve, some of the things that are there in the product backlog may not be required by the time we reach there. So we don't want to go for heavy upfront planning. We want to plan as time goes. And that's why we only look ahead for a sprint two or three at the most. Hope that answers the question.

Lindsay Velecina: 12:05

Great, thank you. Right, so this question from Daniel. So I'm going to try to interpret this the best that I can. And if you need to add any clarifications, Daniel, I suggest that you drop that in the chat. So I work with a team that is predominantly research and development, the team spikes, does prototypes and then develops, the spike generally dictates where the work goes next. Is it possible for r&d teams to work with Scrum as obtaining a velocity for predictability to get to end dates? It's very difficult.

Simran Nagrani: 12:44

Thank you, Daniel. Thank you for that question. In fact, I would say that Scrum is really, really, really relevant in your context as well. If you if you notice Scrum, as a framework is designed to address complex problems. And anywhere where there is a team of people who is working together in order to address a complex problem. That's where Scrum is very, very relevant, very, very applicable. r&d is one such place. Before we talk about spiker prototypes, let me help you understand that you're using sprint as one of the frameworks under the Agile umbrella. And why. So the end purpose is for us to use this framework so that we can we can become more agile, more nimble, more flexible, more adaptable. And we are able to gather feedback. And if this feedback gives us some information, which results into us changing direction, Scrum helps us do that as well, with an ever changing ever evolving product backlog. Now coming to your question, I read the team spike, do prototypes and then develop which means you're really doing an experiment just like a sprint, you will do an experiment, you validate that experiment. And then based on the feedback that you receive, in that experiment, you're adapting your path. Something that Scrum is designed to do. Then I hope that answers the question.

Lindsay Velecina: 14:29

Thank you Simran. That's great. And if you have any follow up Staniel up please let us know. So I just got a question in from the chat. That someone someone who had just joined had asked so for anyone who just joined, we are collecting questions in the q&a box. So if you have a question for Simran, please enter them into the q&a. We're just using utilizing the chat for any side questions or questions around them. In the technical aspects of this webinar, if you're having any sound issues and things like that, so if you have questions for Simran, please add them to the q&a. Okay, so, next question here. So, last spot. Okay. So can you share some insight on when it is best to use Scrum over any other framework and maybe dive into some different scenarios?

Simran Nagrani: 15:33

Sure. So Scrum, first, let me share that is, like I said, applicable in the complex domain. What is the complex domain, again, this is a domain where you have a lot of variability, there are things that are changing dynamically, you have requirements that are changing, you have technology that is evolving, the people that are working together in this team need to start acquiring newer and newer skills all the time in order to continue to stay relevant and in order to continue to work on the product that is flowing in through the product backlog. In such places, Scrum is very, very relevant in the complex domain. Now, there are other domains as well. And what are those domains? There is simple there is complicated and there is chaotic domain. So, in all four domains, simple domain would be let's say we are trying to manufacture 500 pens. Can we nail down the requirements? Absolutely. Can we nail down the technology? Is it going to change by the time we manufacture those 500? Pens? No, it's not going to change? Is the people who are going to work on this product? Are they pretty interchangeable? Do they need highly specialized skills? No, they don't. So this is a simple domain problem. This crumb may not be as helpful because there is very limited variability. This second domain we talk about is a complicated domain where there is repetition. For example, work that includes let's say the work of a mechanic. The work of a mechanic, this mechanic is trying to fix 500 cars, there might be a little bit of variability unknowingness. But there is a whole lot that is already known. And it's same across the cars. And that's why this is a complicated domain problem. This is where best practices work. We learn from what has happened in the past. And we apply the same solution for our future problems as well. That's a complicated domain. There is a third domain I mentioned, this is the chaotic domain where the requirements are completely uncertain. The technology is uncertain. Also the skills that are required are ever evolving at the drop of a hat. What could be an example, all of us have lived that beginning of the year 2020. All of us were in the chaotic domain. With the pandemic when it hit. We did not know what this problem is all about. We did not know what is going to help us solve this problem. And the people who are helping us navigate through this problem the doctors and the nurses, even they to a certain extent we're not skilled enough to address this high level of unknowingness that right there is a chaotic domain where almost nothing is known. We try to bring down the variables and then we try to address the problem. So you are constantly trying to bring that problem down from the chaotic domain to the complex domain. And how is that we had lockdowns people stayed home. There was emphasis on sanitization, sanitize your hands, take your vaccines. All of these are ways of trying to bring the level of complexity the unknown ness of this problem from the chaotic domain to the complex domain and address it there. So Scrum, here's what I'm saying Scrum works best in the complex domain where there is a lot that is unknown. But yes, there are a few knowns as well. So there's, it's not that absolutely everything is unknown. Also, here is what I'm saying. Can we apply scrum in the complicated and the chaotic domain? Yes, we can. However, the benefit of Scrum is the maximum in the complex domain. I hope that answers the question.

Lindsay Velecina: 20:02

Awesome. Thank you. All right, so question about metrics. So in your opinion, what are the most valuable metrics for a team?

Simran Nagrani: 20:13

Okay, just like Scrum is not prescriptive. None of the metrics can be prescribed, right? However, here is a way of thinking about metrics. Right? You want to think about metrics that help you understand is your product working for the customers? Is your product, giving them the value they were looking for? One of those categories. So I'm referring to the evidence based management, which is, which is a set of guidelines, a set of rules of thumb, I would say that scrum.org came up with and I'm sure Lindsay will be able to share more about evidence based management through a link, the evidence based management guide. So the evidence based management guide talks about four separate key value areas. It talks about current value, what is the value you are delivering to the end customer with your product today? Some examples for current value could be what is your net promoter score? What is the Customer Satisfaction Index? What is your employee satisfaction index? What is the current value with your team and your product? The second key value area talks about unrealized value. So there might be things that would be in either your product roadmap, in your product backlog that you think you will add to your product? What value does this offer to your end customers? That's unrealized value. There is a third area. And this is time to market. How quickly can you respond to the changes that are happening in the market? Let's say your competitor comes up with a feature in a product, which is a breakthrough feature. How quickly can you respond to this change? And you all of your customers are moving out from using your product to using the other product? How quickly can you adopt adapt to this change? Time to market? The fourth area we talk about is innovation rate? Is your organization is your team coming up with ideas that have the potential to disrupt the market? That's the innovation. So those are four broad categories. What metric would work in your context is very, very contextual, to your team, to your organization to the kind of product that you're trying to build. But this will give you a guideline on what is the direction you should start thinking towards? One recommendation is you need to understand what is the difference between output and outcome? Your metrics should be designed to help you measure what is the outcome, what is the value that is being delivered and not focused toward output? I hope that answers the question.

Lindsay Velecina: 23:27

Great, thank you. And I did drop a link to a bunch of EBM resources in the chat as well. So this question here, so Can an edge this kind of ties to some of what you were just talking about? Simran. So Can an agile project be on fixed scope, cost and schedule if schedule is impacted due to resource or scope? Is not playing correctly? What would be the best approach to handle that?

Simran Nagrani: 24:01

Okay, thank you for that question. So here is how scrum deals with this situation. First is we need to understand that Scrum is actually designed to make sure that we are able to adapt to the changes that are happening in the market with the competitors with the technology with the requirements. And with that foundation. That question of having a fixed scope kind of initiative itself becomes irrelevant. Right? cost and schedule. Sure we're working in sprints. A sprint is a fixed time box. We know how many people are there on the team. So we can also have a forecast of the of the amount of dollars that we are spending each sprint. So can we have a fixed time frame Next budget, variable scope. Sure. Yeah. So that's the kind of mindset or that's the kind of thinking we want to bring in. And this goes back to the foundation of Scrum of why scrum came into existence. Then Z. Good answers the question. Yes.

Lindsay Velecina: 25:23

That's great. Thank you. Okay, so this question here. So what are some techniques that can be introduced to build transparency within the team?

Simran Nagrani: 25:41

Thank you for that question. Awesome question transparency, one of the three pillars and empiricism on which Scrum is founded. Now, we're creating transparency, to enable effective decision making. Transparency can be created in multiple ways. But before that, let's understand what in Scrum is helping us create this transparency. It's the artifacts, the product backlog, sprint backlog and increment the three artifacts put together is helping us create this transparency. Product Backlog creates transparency about all the work that's not done yet. Sprint Backlog creates transparency about what is being done this sprint. And the increment creates transparency about what is already done. So scrum as a framework has given you this, these tools in order to create that 100% transparency. Now, some teams like to use certain electronic tools in order to create this transparency. Is that okay? Sure. Other teams who are sitting physically together would like to create something like a scrum board, where you have the scrum board at the place where the team is sitting. And that's where you're creating transparency about the product backlog about the sprint backlog? Who is on the team? What's our definition of Done? What were some of the retrospective improvement items that we came up with? If a scrum board is working for your team, keep doing it. If there is some other electronic tool that works for your team, you can do that as well. There are a lot of tools that are available these days, especially post COVID that help you create this transparency. There is Trello, there is Jira, there is rally version one, a number of tools that you can use, as Scrum Masters, we are focusing on making sure that we are using these tools to enable this transparency and not become kind of subordinates to these tools. And we focus our time only on making sure that these this tool is satisfied with the inputs. I get it. Yeah. So that's a little bit about those tools.

Lindsay Velecina: 28:05

Awesome, thank you. So there are some questions that I was able to group together and they are around the the accountability of the scrum master. So I'm going to dive into those. Now we're going to do a few little Scrum Masters section here. So what are some tools and techniques for managing conflict among team members? And if there aren't any, how can a scrum master help resolve team conflicts? Do you have any stories to share their loot?

Simran Nagrani: 28:41

Thank you for that question. So first and foremost, let me share that not all conflict is bad. There are two developers. And those developers are not agreeing on one approach of how we want to address a problem. And they are coming up with their own ideas. They are bringing in their own perspective, their fresh perspective. And then by the end of this discussion, this disagreement, this brainstorming, they come up with the identify the best approach to solve that problem. Is that conflict good conflict? Absolutely. So you can consider this as level one conflict. Let's take an example. Let's say you're a scrum master. And there is a situation in your team. One of the team members is not attending the daily scrum as a scrum master. You there is there is another developer from the same team who reaches out to you and says, Hey, Scrum Master. XYZ is not attending the daily scrum. You ask a few probing questions since when? Since when has this what's been happening? So the other person says, let's say a day or two, as a scrum master, the first question you ask them now is, what have you tried? Now with that, what you have done is you have empowered this person who has reached out to you with this problem, this conflict, this situation, you have empowered this person. And you have told this person that you have all the powers, all the enabling, that you need in order to address this problem yourself. Now, this will trigger thinking of the developer, the developer may reach out to this other developer and say, Why are you not attending the daily scrum? One of the phrases that is used in the scrum guide is developers hold each other accountable. And this is one and demonstration of that. So developer B reached out to developer a and said, Why are you not attending the daily scrum, let's say the developer HSS. Up until now, the daily scrum time was working well for me. But now my situation has changed. I have to first drop my kid to school. And then come to the daily scrum because a pitcher have been missing the daily scrum since the last two days. Is this level one conflict? Absolutely. The developers amongst themselves can design a better time that works for everyone. Is that conflict solved? Yes. Did the scrum master have to jump in? From a standpoint of command and control? No. That's level one. Let's say there is level two. One of the developer hasn't been attending the daily Scrum and it's been a week and continues not to attend even if the other developer asked, why not attending. Now, when you do a little bit of probing, you realize that this developer who's not attending the daily scrum probably doesn't understand what's the significance of this event? Why is the daily scrum important or what is the team losing out on by not by him not attending the daily scrum. In that case, your job as a scrum master is to educate this other person about the importance of the daily Scrum and why he or she should be a part of the daily scrum every day. Now, let's say this is beyond level two. And this person says I not attend the daily scrum at all. Now, it's not about education. It's not about between the developers. Now the focus of the scrum master is this is kind of impacting the team behavior. Other people start thinking of okay, well if he can skip a daily scrum, why can't I and it is impacting the entire team. And in situations like these, the scrum master might have to deal with this person one on one.

Lindsay Velecina: 33:19

Oh, your sound went out for a moment. Simran.

Simran Nagrani: 33:24

Okay, so what was the last part audible? Lindsey the

Lindsay Velecina: 33:27

last part was audible, I think you were just saying thank you for that question. But Okay, sounds good. Sorry about that, folks. Okay, so an other scrum master focused question. I am transitioning from a people management role into a scrum master role. What is the best advice you can give me as a new scrum master?

Simran Nagrani: 33:50

Awesome. First of all, it's awesome to see people start getting excited about Scrum, which is great. So when come to start participating as a scrum master. So let's, let's think about this. Let's say up until now we have been playing a certain game, we start playing a new game, what is the first thing you do? You first starting start educating yourself about this new game? What are the rules of this game? How do we play this game? And then you start understanding why these rules exist. Before you want to introduce scrum to your teams to your organization, you yourself should have a thorough understanding of what the scrum framework is, what are its rules and why are those rules in place. Once you've done that, the fun fact about Scrum is you can start implementing it even as a person for yourself. You don't have to start at only at work. You can start experimenting with some of the elements of Scrum. See how it is trying you how it is helping you as a person and then Maybe start applying it to their teams as well. And look at all of the implementation that you do everything that you do as a scrum master as an experiment. And what is the good thing about an experiment, an experiment, either will succeed, or it will give you a learning. So you're looking at all of your tries as a scrum master as experiments. That answers the question.

Lindsay Velecina: 35:30

Great, thank you. So this is a this is a an interesting question. So what is your opinion on having a product owner and a scrum master be the same person?

Simran Nagrani: 35:45

Again, great question. This is also something that is very, very contextual. A lot of startups actually start like that, where some of the people in that organization are doing doing, taking care of dual accountabilities. Is that a great idea? No, it is not. However, could it be? Could it be done in the beginning? Sure. Over a period of time, this startup may start hiring people you split the accountabilities into separate people. Because understand the way Scrum is designed. Each of these three accountabilities have a healthy tension between them. So there is a healthy tension between the product owner and the developers. There is a healthy tension between the product owner and the scrum master. And then there is of course, the tension between the scrum master and the developers as well. You need all the three accountabilities? Could it be a stop gap? Sure. That answers the question.

Lindsay Velecina: 36:57

Awesome, thank you. So this question from Kingsley, what are the best metrics to measure the Agile maturity of a scrum team as a scrum master?

Simran Nagrani: 37:12

Alright, there are a lot of agile maturity models that are available outside of Scrum. I don't have links to those handy right now. But I'm happy to share those with you. Maybe after the webinar, give me a day or two. And surely we will, we can work on that we can share those resources with you. Okay, great.

Lindsay Velecina: 37:40

So what are some tips to use to help the team understand the daily scrum as more of a collaboration and less of a daily check in collaboration versus a daily status update?

Simran Nagrani: 37:59

So, the reason this question is coming is because up until now, maybe in the traditional way of working, we have been doing one meeting every day and we used to call it daily status. Right? The way Scrum is designed, the way the daily Scrum is designed specific is it is designed for the developers primarily to come together to create a shared understanding about their progress towards the sprint goal. And if there is any adaptation to the plan that is required for the next Monday for us next day. We can discuss that in the daily scrum. Now, one indicator of a daily status is everyone is looking at one person and offering sharing what we have been able to achieve. That's a daily status. What's a daily scrum where everyone is collaborating, there is no one person who's in power. And that's why if you notice in the scrum guide, it says the participants the owners of the daily scrum are the developers. Now, there are different techniques that you could use in a daily scrum in order to one limit your conversation to 15 minutes or less. The scrum master can introduce these facilitation techniques. One of those is parking lot. You can park discussions that don't need to be a part of the Deleasa. Also, the moment you see people talk about what kept them busy for the last 24 hours. You know it is a daily status. What they really should be sharing is what is the progress they have been able to achieve and not share. Here is a hurdle here is a hinderance that I ran into and how I heroically got through all of those hurdles and hindrances and here I am. So that's not a discussion that's happening in the daily scrum.

Lindsay Velecina: 39:58

Great, thank you So, how can you make a scrum team a self organizing or self managing team if members do not share the same skill sets? So for example, front end and back end developers.

Simran Nagrani: 40:17

So, those are two separate concepts, the question talks both of these talks about self management and cross functionality both we require in the scrum team itself. Here is how I would address that question. self management, first, we need to understand what self management means. self management does not mean that we tell the team go do what you like. self management helps us give us give boundaries, borders are enabling constraints that will help the team identify what is their focus area? What are they trying to achieve this sprint? What are the things so for example, the sprint goal, the sprint duration itself, the different accountabilities are all enabling constraints. Within that those constraints how the team works with each other is left up to the team. And that's what we call self management. They're deciding the how we work with each other. They don't need a separate person, they don't need like a manager to tell them how they work with each other. And that's what self management means. And in order to do that, we need a cross functional team, a team which has all the skills to pick work from the product backlog, and bring it to a state where it is useful for the end customer. That's the cross functionality. That's the definition of cross functionality. Now people with different skills come together so that they are able to do this translation. They are able to self manage their work. I hope that answers the question.

Lindsay Velecina: 42:08

Great, thank you. So what if a team is not actively participating in the sprint retrospective? Any tips to encourage it especially in a virtual environment? This is a big challenge. For all for sure.

Simran Nagrani: 42:26

Thank you for that question. Great question for SCRUM masters for sure. Sprint Retrospective is an opportunity for us to reflect on how the last sprint went, and how we can make the next sprint better. Yeah, that's the purpose of the sprint retrospective. Now, I have observed in my practice, very, very commonly two problems that teams face. One is the teams start looking at retrospectives sprint retrospectives as opportunities to point fingers. Rather than talking about what went wrong, how can we make sure it doesn't repeat in the future, they start talking about who went wrong. So my first tip would be make sure that your conversations are focused on objective discussions and not subjective. My second observation about problems with Sprint retrospectives are that the facilitator of the retrospective has been using the same facilitation technique over and over again for multiple sprint retrospectives in a row. Because of which your sprint retrospectives have become boring, and ineffective. In order to address both of these challenges, there are a lot of facilitation techniques that are available that you can experiment with at Sprint retrospectives. So tasty cupcakes.org is one website where you can find many dozens of facilitation techniques that you can start using as Scrum Masters. There is another resource, it's retro mat.org. You can go through that website as well. There's also a book called Agile retrospectives. Very, very rich in content, talks about a lot of facilitation techniques that you can use in sprint retrospectives and make them effective. I hope that answers the question.

Lindsay Velecina: 44:27

Awesome. Thank you. Simran. And what was the name of the second resource that you mentioned?

Simran Nagrani: 44:33

I can play the duck in the in the chat. It's retromer.

Lindsay Velecina: 44:37

Okay, perfect. Thank you. Right. So this question goes back to estimation a little bit. So our sprint backlog items are running over estimated time constantly. Even if we plan using story points. There are unexpected things happening and we spend And for example, three times more than estimated in time. So we end up not completing them on time. What should we do so that items would be completed on time.

Simran Nagrani: 45:13

But my first response to that is, you probably need better sprint, better product backlog, refinement sessions to happen, because that is going to bring in a lot of discussion points, and the developers will be able to better understand the work that they are picking. Right? They have a better guess of what is the amount of complexity that is involved in this specific product backlog item that we are likely to pick up in the future sprints? That's the place where I would start.

Lindsay Velecina: 45:53

Okay, great. Then here's another question. I hope that I interpret this correctly, but it kind of ties to the same topic with estimations and refinement. So we do estimations high level first and refinement, and do another estimate on detail level in the planning session. This doesn't feel right as we halfway start knew the planning sessions take longer than they should. What would your recommendation be?

Simran Nagrani: 46:32

All right. So if your team is using estimation, which is a complimentary practice outside of Scrum, the reason I'm saying that is so that you know that this is optional. This is not mandatory, according to stone. Correct, if your team is doing that, they should be doing it in the product backlog refinement itself. This is the place where we are trying to understand what is the kind of work the product owner is thinking about or the stakeholders are thinking about? What is the level of complexity how much effort is going to be required in order to get this done. All of that discussion happens in the product backlog refinement. The sprint planning has a different purpose. The purpose of the sprint planning is for the developers to start pulling in work from the top of the product backlog. Break it down, create a sprint backlog discuss with the product owner, what is our sprint goal? Come up with a sprint goal, present the sprint backlog back to the product owner and identify ways of how you're going to work together as developers throughout the sprint. Yeah, so the purpose of the sprint planning is really, why are we working together this sprint? What is the word that we are going to focus on? And how are we going to work toward achieving that sprint goal? The discussion is not about understanding the word that's coming in. Also, I would like to emphasize one more fact that estimates sizing is something that the developers offer. Whether it is t shirt sizing or it is planning poker that you're using, it is a developer who come up with these numbers. No one else is going to tell the developer what is the size of this product backlog item? If that's happening in your context, you might want to also stop that from happening. Awesome, thank you.

Lindsay Velecina: 48:38

Write this question if the requirements are not clear, developers have to do research and come up with recommendations and later plan for implementation of Scrum recommended to oh, sorry, I read that wrong. Is scrum recommended to start user stories as a spike? With specified timelines? What is your advice on these types of scenarios?

Simran Nagrani: 49:13

So in Scrum, all the work is happening within the sprint. Right? There is no spine. There is no Sprint Zero there is no hardening sprint, there is none. None of those are concepts that scrum guide talks about Scrum has introduced teams and people have created these terms for continuing to be in the comfort zone.

Lindsay Velecina: 49:38

So if the requirements are not clear, developers have to do research and come up with recommendations and later plans for implementation. Is scrum recommended to start the user story as a spike with specified timelines? What is your advice?

Simran Nagrani: 49:57

Okay, so a few things that are going on here again used Stories is also a complimentary practice, specify timelines, we work in sprints. And that's why those are the timelines we talk about. No other timelines are mentioned in the scrum guide, or we don't talk about those terms with Scrum. Now, you're problem really, the way I understand it, obviously, I'm not in your context, you know, the best. But if, according to the question here is what I see, your problem is that the requirements are not clear. Which is telling me that your product backlog refinement needs to happen more effectively. But let's say you had an effective product backlog refinement, and still, the developers are not clear with the requirements or the product backlog item, or the user story. So you call it can the developers reach out to the product owner for more clarity, either during the sprint planning or during the sprint? Absolutely. And that's why all of these three accountabilities are within the scrum team so that collaboration opportunities like this can continue to happen. So developers reach out to the product owner try to understand more about what is expected. What are we looking for, by getting this product backlog item done. So there is absolute clarity on what is the work that we are looking and we explore, we expand this work as we work through the sprint. Even the product owner knows that we didn't know everything about this product backlog item when we began. And we are identifying that there is more work that this is more work than we had anticipated. So everyone is still on the same page. You're still working as one single unit, the scrum team. I hope that answers the question.

Lindsay Velecina: 51:46

Awesome. Thank you. So this next question, this person seems very, very urgent that we answer this question with lots of exclamation points and question marks. So generally, it's not recommended to change sprint duration. Can you please give some scenarios when we can change the sprint duration? Multiple exclamation points and question marks? Yeah, very excited,

Simran Nagrani: 52:15

which is great. Yeah. Okay. So your question regarding the sprint duration?

Lindsay Velecina: 52:24

Yes, correct Scrum.

Simran Nagrani: 52:26

In Scrum, we adjust the amount of work that the team picks up based on the sprint length. And this is done at the sprint planning. It's not the other way around, we do not adjust the sprint length based on the amount of work we take. And the reason for that is we want to create a rhythmic pattern with that sprint. And we want to learn from the from what happened in the previous sprints. Let's say we began with two week sprints. So we have a two week sprint, another two weeks sprint another two weeks. And let's say the first two weeks from that the developers picked up five items. By the end of the sprint, they were only able to finish three. Our next sprint is again two weeks French. Now they have data to look at. And based on that data, they can make a better decision at the sprint planning about how much work they will pick up for the current sprint. But if you change the sprint duration, you will not have that data, you will not be able to make better decisions, better forecasts. And that's just one example. Having the same duration sprint also puts all scheduling on autopilot. Your stakeholders know when your sprint review is coming. The scrum team knows when is our daily scrum. When is our sprint planning when is our sprint retrospective. So we can plan accordingly. So it reduces the complexity involved in the work. It brings in a certain level of certainty on when are these events happening. And that's why sprint durations should be consistent. And that's the reasoning behind this consistent duration sprint. I hope that answers the question.

Lindsay Velecina: 54:17

That makes a lot of sense. Thank you. So I think we have time for one more question. If we break down product backlog items into small product backlog items, do the small PBIS need to be worked on by one developer? Or is it better worked on by more than one developer? I know it's kind of contextual but maybe you could share some scenarios where you've seen teams work through this

Simran Nagrani: 54:50

so breaking the product backlog item down into smaller product backlog that I thought product backlog items is a great idea. Um What we recommend in Scrum is that at all times, the developers are focusing on the highest value items. Now in some teams, it might be that, let's say there's a team of seven people, seven people are focusing on the top two items from the product backlog that they pulled into the sprint backlog. They bring it to them, and then they pull in the SEC next to product backlog items, which is a great idea. And the reason I'm saying this is because this is a better idea than seven people working on seven separate items. And by the end of the sprint, you're not done with any of those. Right? You're not working in stages, you're trying to move away from that you're trying to focus on the maximum value items, bring them to a state where it is done, and then pull in the next. I hope that helps. However, like Lindsey said, this is very, very contextual, as well. So we will need to understand more from your situation on what's the best approach.

Lindsay Velecina: 56:12

Okay. Thank you. All right. So we are coming up on our time. Thank you so much. Simran. Before I jump into some closing items, what are the best ways for our audience to get in touch with you? And on top of what Simran is doing?

Simran Nagrani: 56:36

Who for you? Okay, I see someone asked for my LinkedIn profile. So here it is, feel free to connect with me. Let's check on who's asking for a LinkedIn.

Lindsay Velecina: 56:47

Okay, you just sent it to hosts and panelists, let me let me copy that and drop that in for everyone. There we go. Okay. There is some rounds, LinkedIn for everybody. And go ahead.

Simran Nagrani: 57:06

No, that's the best way to reach me.

Lindsay Velecina: 57:09

So we have lots of other free resources on our website, as I mentioned earlier, so please check out the learning paths on the scrum.org website. We're also adding lots of new learning series to our website as well, and our recently updated resource center. So please feel free to check that out on the scrum.org website. And please stay in touch with us on social media and we run Aska PST sessions monthly. This This month, we're running a few and some different languages, but we tend to run them on a monthly basis. So keep an eye on the scrum.org community podcast for that. And thank you so much Simran, for spending your time today answering our audience's questions. Or a question that just came in from the audience. Yes, there is a recorded session. And there were a number of questions that were not answered as well. So those questions will be shared with SIM. After the session. There were a lot of questions that came in, we just didn't have time for all of them. So we will figure out a way to get those addressed post session. So thank you, everyone, for your time today. And we will we hope to see you soon. Thank you. So Rob.

Simran Nagrani: 58:27

It was a pleasure to answer your questions. I look forward to connect with you.