Ask a Professional Scrum Trainer with PSTs Joanna Plaskonka and Magdalena Kucharska - Answering your Burning Scrum Questions

Scrum has been in existence for more than 25 years as a simple framework for effective team collaboration on complex products. While it is lightweight and simple to understand, it can be difficult to apply effectively. The Scrum.org Ask a Professional Scrum Trainer series features Professional Scrum Trainers (PSTs) in a live session, answering your most pressing questions regarding the challenges and situations your Scrum Teams are facing.

In this session of Ask a Professional Scrum Trainer, Joanna Plaskonka and Magdalena Kucharska answered questions focused on the Scrum Master, estimation, user stories, metrics, Scrum events and more!

 

Transcript

 

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. Thank you, all of you for joining us today. Welcome to today's Ask a professional scrum trainer session. I'm Lindsay belshina. With scrum.org I will be your moderator today and today I have two PSTs. With me, I have Joanna Plaskonka and Magdalena Kucharska. So welcome. And both of these ladies are based in Poland. So

just some very quick guidelines here.

Your microphone will be muted throughout the session. However, this is a q&a session, we want you to ask your questions. So please enter your questions into the q&a box. At the bottom right of your screen. That is where you'll enter all of your questions. If you have technical questions, please utilize the chat I ask that you do not use the chat for any of your questions for Magda, and you want to so please utilize that chat window. This session is being recorded. So a recording will be made available via podcast within 24 hours. So please keep an eye out for that you will get an email. And let's let's get started here. So very quickly, who's scrum.org we are the home of Scrum we were founded by Ken swaybar in 2009. Our mission is to help people and team solve complex problems. We offer training, certification, and ongoing learning for professional Scrum. This webinar is just one of those pieces of ongoing learning that we have, feel free to check out all the free resources on our website. And what that I will hand it over to Magda and Jana to introduce themselves and get started.

Magdalena Kucharska  2:15  
Thank you very much, Lindsay. Good morning. Good afternoon to everyone. My name is Magda carska. As Lindsay said, I'm currently based in Poland. I've been a PST for less than a year from now. And previously, I've been working for more than 10 years in different companies, various environments like banking, gambling, it engineering, aviation, so a lot of different backgrounds. That I hope that will come in hand in today's answering your questions.

Joanna Plaskonka  2:46  
Thank you. So my name is Joanna Plaskonka, you probably know that I'm located in Poland too.

And I've been in PST for around two years right now. My background is in engineering, I used to be a software configuration management engineer. And I quickly started in my professional career learning about Scrum agile, how to how to take the best out of it.

So majority of my experience is related to be a scrum master coach, supporter for the whole organization in different industries. So banking,

software houses,

some companies creating software as a service. I even worked in the robotics startup, which fun fact is related to my educational background, because I'm an engineer.

I'm a robotic and control engineering expert.

It's good that you're here with us. So I guess it's high time for your questions. Yes. So thank you both for that quick intro. So for those of you who have just joined, please utilize the q&a at the bottom of your screen. Enter your questions. I'm going to stop sharing.

Lindsay Velecina  4:09  
And let's see here. So all right. So this question here. Can developers remove and replace sprint backlog items themselves during the sprint? You want to want to take this one?

Joanna Plaskonka  4:32  
Yes, sure. That's a that's a very good question. So I guess that when you're using the term item, you mean product backlog items, right? So in general, I believe so. In general sprint backlog is not a commitment in scrum as a whole. It's our forecast. What we are going to do is our plan, let's say short term plan, how to how to create valuable product So if the developers do not change the sprint goal, and they are still contributing to the goal, it's okay to change product backlog items. However, when it comes to transparency, which is, which is one of Scrum pillars, I think it's good to have a conversation with with product owner when it comes to changes on product backlog item level. And I believe that it's a matter of a collaboration with a team. If you show the product owner like this is the best we can do. I strongly believe that they will, they will agree on that.

Magdalena Kucharska  5:41  
Well, they can add is also that usually when you want to add things to the sprint backlog, there's a question of what should I take out of it right, because there are a certain amount of things we are able to do during the sprint. So it's all it's more about conversation regarding the sprint goal.

Lindsay Velecina  5:59  
Okay, and then a follow up question that came in here. So then who decides to release the increment?

Magdalena Kucharska  6:05  
Who decides to release the increment? Well, it's a product owners decision when and when he should release the product or the increment to the customers. As remember, we have to create valuable, usable increment by the end of the sprint. However, as product owners decision, when to release it, sometimes take into account the things that happen on the market. It's a better decision to release it less frequently than once a sprint. And sometimes it's a better decision to release it as soon as possible. So really much depends on many, many factors around the product development.

Lindsay Velecina  6:38  
Thank you for that. All right, so a couple questions coming in here around scrum master. So any recommendations for scrum master who is starting with a new team who's not 100% agile yet and is using the best of both WaterFire water net waterfall and agile?

Magdalena Kucharska  7:01  
Don't go chasing waterfalls.

I remember when I started as a as a scrum master the key learning for me the key teaching point was to observe the team and just look and understand what's about what is the product about they're working on? What are the biggest impediments? How's the conversation flowing? How's the collaboration going? Are they able to deliver an increment? Do they have any dependencies around the product and just observe and try to find those pain points moment when I can actually help as a as a junior scrum master, and spark some more meaningful conversations how to inspect our process? So that's what I did. What did you John did when you started as a junior scrum master?

Joanna Plaskonka  7:52  
Oh, my God quite a long time ago. If I came back to my history, I would say look at the principles because I fully I fully agree that you do not make big changes overnight. Because we continuous learning, I would say for me, it's a part of being agile. However, from principles point of view, every sprint is an opportunity to learn to manage risks. Do you take those opportunities? Is there anything that you can help your team to work on that? So we create create increments, at least we're working useful, usable increments every sprint? So is your team able to do that? If not, what would be the first step that you can encourage your team to do? Other kinds of questions Scrum, one of Scrum principles is that we have a team of professionals, they are self managing and cross functional. So next coming questions. Is your team really cross functional? Do they have all the skills in the team, it might be another great conversational point to help them look for those gaps maybe to start some conversations with some leaders, decision makers in their organization, what you can do to really embrace the self management and helping your team become cross functional.

Magdalena Kucharska  9:19  
And also keep in mind that you have a master in your accountability. It's you're the master of Scrum. So it might be an issue of sometimes discussing the reason behind each of the events, right? You're also there to educate and teach and understand. Why are they doing each of the events? What's the outcome? What's the output of each of the events of the sprint itself? It's also it's it's good to focus on making sure everybody knows what they're working towards on was the sprint goal was this product goal? Does everybody understand that? Is there transparency in your work in your environment? So all of those aspects come in hand but keep in mind also that To change doesn't happen overnight, as Jonah said, some of the improvements that you will see some of the improvements you want to do will take a lot of time. So just make sure you do step by step little inspections, adaptations, and you have the feedback loop. And you work on that because Scrum is all about empiricism. It's all about learning. So making the next sprint better to make our product better with each sprint. So what you can do as a scrum master to do that. That's more of an open question.

Lindsay Velecina  10:35  
It's great. Thank you. All right. So there was another scrum master question where Megan asked, Do you think a scrum master needs to have a technical background?

Joanna Plaskonka  10:48  
I love that question. I was I was a part of that discussion, I can share my answer because I did not change my mind for a few years already. So I believe that this is not obligatory for a scrum master to have a strong technical or domain knowledge. However, for me, one of the principle is continuous learning applies to all of us also to scrum master. So the best SCRUM masters that I had a huge pleasure and honor to work with, they were also learning about products, they were also interested in what our users are saying. So when you have your eyes and ears open, right, when you listen to conversations, when you help facilitate good things happening, and you learn then you are becoming a better scrum master. So maybe you will not realize today that you you have this knowledge. But most likely after a year or two, you may realize, Oh my gosh, now I got more into those technical technical aspects, it does not mean that you start to code or build robots if your product is a robotic station, but you will learn you will become a better person a better scrum team member because you are as a scrum master, a member of the scrum team.

Magdalena Kucharska  12:09  
I'd say both of us are the perfect target for this question. Since John that comes from technical background and I don't, I've actually finished pedagogy. So I'm certified in education. So totally different area. However, I agree 100% of Giovanna as long as you're learning about your product, and your willingness to improve yourself grows over time. And you want to understand deeper what happens you can become a better scrum master. And also like that small sidled if you ask a technical scrum master, does a person needs to be a technical usually the technicals one say yes. And the non technical say yes. Alright, so they need say you don't need to, and then you need to have a technical so really depends on your journey.

Lindsay Velecina  12:57  
That's great. Thank you. That's great advice. And it's awesome to have two different background perspectives as well on that

Magdalena Kucharska  13:05  
it's possible it can be done Look at this.

Lindsay Velecina  13:11  
All right, different stores. So this next question and other scrum master question, and then we can switch gears a little bit. So how do I, as a scrum master start a good relationship with the product owner, while setting the correct boundaries between roles? Now this person did give a little bit of background. So I'll share that too. I am preparing to take over a new team. And I found out from the former scrum master that the team that he and the PIO mixed roles and responsibilities. And to be honest, I don't want to do that. I want to only do the scrum master job I am good at I don't want to mix things, any tips for that difficult conversation? So I guess it's two questions there. So the first one is how do I start a good relationship with the product owner while setting the correct boundaries between roles?

Joanna Plaskonka  14:04  
I may start, I think I can recommend a general conversation auto to start. Oh, thank you, Melissa. Exactly. working agreements. However, don't think about working agreements. They are just, you know, how much do we work with as well. You may add more things to your working agreements. For instance, how do we handle conflicts? How do we handle disagreements? What we can expect from each other when it is okay to say no, and that if we agree on certain things, this is our agreement. Let's do it. So this is the thing that in general, whenever there's a new team or the change in the team is good to either revisit or created from the scratch to make things transparent, you know, to set the right expectations and Another piece of advice, what worked well for me is to having an open conversation with product owner and asking what I can do to help you so that we will work great as a team. So I'm setting expectations that I'm here as a leader that serves from Scrum Masters point of view, and they want to listen to your problems. What is your biggest problem currently? How can I help you? How can I support you? At the same time, I think it's completely okay to tell that I'm not going to the to do the product management, because I don't know about that. I'm a scrum Max, I'm scrum expert, I want to take the best out of my knowledge to support you in that if you feel that you are overwhelmed, maybe this is one of the hypotheses I don't know, then you as a scrum master can help facilitate discussions what we can do as a team. Maybe we have to raise an impediment and ask others for support. Because let's be honest product ownership. It's a lot of work.

Magdalena Kucharska  16:08  
Yes, I think it's really important to understand the why behind the situation. So when the product owner wants to, let's say delegate things that are in his capacity, or his accountability to the scrum master. So the question is why he might be overwhelmed. Or maybe there's not enough knowledge in him on the product ownership, or maybe just maybe had a bad example, from somewhere, maybe he's used to someone else doing that for him. And he never knew he could do it by himself, we look in terms that say this example, product backlog management, it doesn't say that the product owner needs to rearrange the things in JIRA, from top to bottom or right to user stories, right tasks, that's not product backlog management that can be done by anybody from developers. Right. So maybe there's an issue of, of going into too much details, let's say, in this example of product backlog management, maybe he doesn't want to do things that are in the capacity of the developers also. So I remember a situation that we had with a team like that. So what we did, we met on a retrospective, and each of us had a piece of paper divided into two things. One was the things I want to be accountable for at work. And the other one was what people expect of me. So each person right, wrote down what they wanted to be accountable for at work, and they passed it along to other people from the team. So each of us could write what we expect from this particular person or a role or accountability, it depends on the facilitation. And by the end of the retrospective with a whole list. And when then we kind of had a facilitated discussion, what we came up with our understanding as a team from now on, because even though you're just from this context, a new person joined the team, the whole dynamic changes. So it's good to revisit the agreement, the contract, the accountabilities, anything regarding to your scope of your role towards the whole team. That will be that will be working in my case.

Lindsay Velecina  18:12  
That's great. Thank you so much for sharing that. I hope that was helpful. So Me too. I'm sure what. So the next couple of questions are kind of developer focused questions, talking about some methods, tools, estimation, story points, user stories, those types of questions. So this question from Robert, what methods or tools do you use to make Deb's break big PBIS into smaller ones?

Magdalena Kucharska  18:49  
Are you looking for a specific name of the tools or just a general approach? It's really

Lindsay Velecina  18:55  
client, I would share some approaches. And then if there if there are tools that you recommend, that is fine, too, but I'm focused on the approach to facilitate this, I think and, Robert, if I'm off base, please let me know in the chat.

Magdalena Kucharska  19:13  
What I do when I work with developers, splitting the items is a whole scrum team works. I wouldn't just include developers into that because the product owner also knows right, what's the ultimate value at the end we want to deliver. So that's the one thing the regarding the estimation that's like total topics. I'm not gonna touch on that on the moment. So what I do is I talk a lot about values. What's this? We kind of go around the value question, what's the smallest thing that brings value to us that we can complete in the sprint right? And what things that we complete on the previous sprint were that met the definition of done because we know the increment needs to meet the definition of done that we're suitable to bring to our customer to our clients are the name of the tools we have there. hamburger technique, right? For instance, when you place a PBI into different parts of let's say, a hamburger, hamburger, and then you create one to bring at the end. That's one of the techniques and the ways I approach this.

Joanna Plaskonka  20:16  
So I really, I really liked the conversation about value. So I agree with Mark that this is a very powerful question. And I also asked that question for the, for the whole scrum team. So including product owner, what is the smallest possible value, because it helps us narrow into that really, really small things that that we can do during the sprint, and to find out how to split things, I use techniques that maybe your product owner already know on you, or you may or may teach them. So I love creating impact mapping. I love user story mapping. So the things that helped you understand the journey, for instance of your customer creating personas, that was one of the great things that we use, because it helps us to tell different stories, then break down those stories into smaller things that our users are gonna do with our product. And then thanks to that, okay, what is this small path that we can do this sprint, what kind of value will bring, and if you have, if you are talking in this conversation a lot about the user, then you basically can use user stories as a complement complementary tool. So you express your PBIS as a story, what that is going to happen, a value that you expect your users to achieve. And I think it's it plays really, really well

Magdalena Kucharska  21:54  
together. Also, from developers proposal perspective, I remember when I, as a young Scrum Master, I came back with this question to them. What can I do? What kind of techniques do you know to split stories into smaller words to split, not only stories, but just PBIS. And they explained to me there is a technique called Event storming. So I would go back to developers and ask about event storming is it's a, it's splitting the work and from the architecture point of view. Right from the architecture of your system. We're talking about software. So there must be another idea to look for.

Joanna Plaskonka  22:33  
I saw a question about persona. Thank you for that. And whenever we are speaking about some strange things, but you new to new to you, give us please, please give us quick feedback. So when it comes to persona is a it's a some kind of representative of your user. And it helps the team to jump into into the shoes of this potential user we express. Typically, what we do is with my teams that we give a name, we get a picture, right visuals work. And we are we are writing down problems, some pain points, behaviors of that persona. And this helps us better connect our work to a particular user. And it focused us our our work and behavior towards helping this particular person that represents a group of our users to help them solve the problem. It's like, whenever you're writing something, you're in the front of your computer, you have a meeting, you're no longer talking about, we just did the product. Instead, you might think there are people somewhere they are represented by Jessica. And what we do today is super important, because we are trying to make Jessica's life better. So you may also use it as a tool for for motivation, because it's not just a job, right? It's helping someone sitting somewhere in the world having some problems, and they're most likely more of such people. That's why we created persona to represent that group. target group. Yeah. Awesome. Thank

Lindsay Velecina  24:22  
you. So this next question. So this person asked kind of a different questions about estimations. So do estimations have both a QA and a development effort? They're indicating that their teams are not cross functional? So what are your thoughts there? Maybe give some advice on building cross functional team as well. Well,

Magdalena Kucharska  24:53  
generally, for my idea is we if we are estimating anything in our backlog, We estimate everything or nothing. If we just estimate some of the things that we do, and others don't, then we don't have complete data. And if we don't have complete data, we cannot make conscious decisions, or, or forecast our product development. Because because we have incomplete data. So if you are estimating in your team, you estimate all the work, and you estimate with with all of your team, right, so to get the full understanding, it might be difficult at the beginning, because I remember when I was starting, teaching estimation, and the biggest voice was of the tester saying, we don't want to estimate because we don't understand the code. And we had a big conversation to which level they need to understand what's being done to know enough to estimate, right, so it took a while it wasn't one session, it was a couple of sessions, couple of refinements to be honest, to understand to go into deep into our, our PBIS that we had, until we get a shared understanding enough to estimate as a team. So that would be my point, together a validator.

Joanna Plaskonka  26:12  
So I also heard about problem with cross functionality. So my question will be, so if you're your team is not cross functional, how do you create product increment? Maybe this is a good starting point, right? Because if you do not have all needed skills and expertise, how you can make sure that you have this opportunity for learning for gathering feedback, feedback every every sprint, so that might be a change, huge change a game changer actually in your process to do all the possible things to allow your team to make them become first functional team. And the second, the second part, McDonough shared the idea that few estimate, estimate everything. Because yeah, now it seems like you may miss some some some data and how do you want to, to assess what is possible, potentially, and what is not, there is an alternative about that. Don't estimate, use the historical data. And this is pretty consistent with empiricism. So learning by doing and learning from history, making the best possible decisions for the future. So if you use information about for instance, amount of PBIS, you were able to achieve in in previous sprints, on average, for instance, or you will use in general, so called Flow metrics. So Kanban guide for Scrum teams, this might be an inspiration for you, you sometimes you don't have to focus the conversation on the giving actual estimate, for instance, in story points, maybe it's better to ask different questions, what are the risks? What are unknown things? What are the ambiguities here? What is the worst thing that may happen? And have this conversation to assess how to prepare well, during for instance, backlog refinement for the upcoming sprints? And instead, look, look at the history because the good news, what happens in the past, if you have transparency in your backlog is truth. So you will make decisions in that case, based on the data that was real, this is what happened. That was not a prediction of the future. It's about the history.

Magdalena Kucharska  28:40  
So I guess we got into more a bit of a conversation, what data can we use instead of velocity because usually story points lead to velocity at some point burndown chart, which is what we call a vanity metric. That gives us some idea of velocity of the team, but gives us nothing about the product themselves. So as Jana said, there are a lot of other metrics. On other data we can gather. For instance, we can gather Customer Satisfaction Index, we can try to measure Cycle Time lead times the quality of our work, let's say quality code coverage that we can measure that we can measure happiness index in our teams, and then see where we go forward. I guess we just kind of drift drifted with the conversation a bit from the questions?

Lindsay Velecina  29:23  
No worries. Thank you for that. So this next question, I'm going to jump around a little bit more. There are lots of questions coming in. So if your question does not get answered, don't worry, I am going to share these questions with Jana and Magda, and they will figure out a way to address them. So don't worry about that. It just asked you to be patient. So this next question. So Have either of you had experience working with Scrum teams that are not traditional software development based but rather data science, where much effort and work is next Bear meditational and could result in little to no added value at the conclusion of a given sprint. Focusing on delivering added value is difficult in this type of scenario.

Joanna Plaskonka  30:14  
What about changing your perspective of it? Wonderful question. And now you triggered me Because personally, when I'm teaching in my classes about Scrum, I'm not telling that Scrum is a tool to help you with your delivery or product development. What I say instead, it's a tool to maximize learning. And it's a tool that helps us manage risks. So if you in your case, I feel your pain because I had this conversation with one of the leaders that he observed, like, you're doing a lot, right. And it was in robotics, by the way. So it was difficult new algorithm AI involved, right? AI is not new, new thing, trust me. I studied that a long, long time ago. So new algorithm, new AI, hardware included, it was so many possibilities that something may go wrong. And it's good to have a conversation what what we actually did, what kinds of risks that we noticed that we find out and how did we manage them? So for instance, during sprint review, we started talking about what was the value of learning process, and the product delivery, product development came up as the consequence, consequence of that learning and risk management. So I think when it comes to very r&d work, it's good to make such things transparent. have this conversation with stakeholders, and show show what are you are doing when it comes to learning when it comes to, to mitigating managing risks. So that might be a changer that will help you facilitate better discussions?

Lindsay Velecina  32:12  
That's great. Thank you. All right. So this question shifts to remote work. So I work with a remote team. It's a struggle to get the developers to talk during sprint retrospective, and sprint planning any tips on how to build more momentum with this team, I've tried icebreakers raise this concern during retrospectives, and no major progress help.

Magdalena Kucharska  32:38  
Sorry, I'm smiling, I feel your pain, I feel this pain. So usually, I'm gonna go straight to come come up some of the ideas and the solutions that worked for me, maybe jump over them to Joanna to share her experience. So when I feel that people are disengaged, and doesn't mean it's usually online could be offline, they happen before the online time is because they don't see any value in the event. For instance, imagine we have a retrospective, every sprint, we come up with some ideas, some actions, but we do not implement them. During some of the sprints. During like the time is passing, we see that whatever we discuss, nothing gets implemented throughout the work, there is inspection, there is no adaptation. So our work doesn't get any better. So we are not learning actually from what we did before. So this event loses value in itself, because it doesn't doesn't have any output or outcome for us. So what helped with my teams was to ask them, What can we do together to make this event more valuable for you? What needs to happen? Right? Is there a specific thing that needs to happen? What needs to change in this event to make sense, because what I'm kind of feeling but I'm just doing a hypothesis that maybe there's kind of a zombie Scrum. So you're doing the mechanics, you have all the events you have, you may have artifacts, you may have commitments, but however, some of the things are not working. So I'd say going back to the purpose, why each of those events exist? What how do they connect with each other? What happens after them what happens with the output, right? So if you create a planning and do you have a sprint goal? And do you ask and talk about the sprint goal during every day? Do you inspect it as you go along? Right? Do you really have the outcome out of the events? That will be my answer?

Joanna Plaskonka  34:37  
That's a very good question. And thank you Magda for sharing that perspective. That might be one of the scenarios. And I can imagine that sometimes people simply do not like talking in a bigger group. If you ever facilitated a bigger meeting, most likely you realize that only a small group is talking when it's just asking questions. Listen And then great. That's why last year we created we published annual course@scrum.org. And the key word for you is facilitation. So I can recommend, if you look for resources@scrum.org, there are plenty of good stuff, keyword is facilitation. And there are techniques that you can use to maximize engagement. However, maybe they will not talk out loud in this bigger group. But if they create valuable posts, their voice is there, and you can create outcomes from this meeting, here you go. So I think it's also a matter of respect that simply some people do not want to talk in the front of the bigger group. So I would, I would recommend, I would also recommend that direction. And I can also share something that happened to me recently, I had a group of 12 very good students, I have to say, because whenever they were doing some exercises, I've seen fantastic outcomes. But you know, when I was talking to them, all the cameras were off. And it's terrible. It's a terrible thing for the trainer, because basically, you are missing visual cues when you have this collaboration. So what I did, I took the advantage that the training was split over four days. And during the second day, one of the students called in earlier and we started conversation. And I told her that, you know, it's such a pity that I don't see your face, and she said, Okay, I will turn my camera off. And I said, Hey, it's such a great thing that you're here. Why are you not turning your camera on? I told you openly that it may affect my work, and I'm here for you. So she said, Well, I don't want to be the first one. And I told her, and at the same time, you can be leader you can lead by example, she stayed with camera on and till the end, or the whole training all the camera were cameras were on because this is what happened, I convinced her to stay with the camera on and the others decided to change, you know to have also this cameras on. So there are different leaders in your team, right?

Magdalena Kucharska  37:23  
So to paraphrase, find a change agent within your team within your group, to someone on your site and try to do a little step by level make a change.

Joanna Plaskonka  37:35  
I have one more story, I will try to keep it short, there is for a split specifically poor for sprint retrospective, there is such a facilitation technique that we can call it a box technique. So you have a physical or virtual box. Basically, they are putting ideas they want to discuss in one place. And for every item for every question for every every positive facilitator changes, it rotates. So you actually ask your team to be part of both participation and facilitation, maybe that will help you create a bigger ownership during the meetings. And also,

Magdalena Kucharska  38:19  
in regards to retrospective. Just one more thing. There's a common misunderstanding that a scrum master should facilitate retrospective. Everybody is able to do that scrum master just makes sure it's there it happens. It has the effect was supposed to have everybody's engaged. However, you can do it on a rotating basis. So that's a great suggestion, John. Thank you.

Lindsay Velecina  38:44  
Great, thank you. This next question. So do you have any tips for creating sprint goals? And our project these are stories seemed like a long to do list? Do you have simple examples?

Magdalena Kucharska  39:01  
Like an example of a good sprint goal,

Lindsay Velecina  39:03  
yes.

Magdalena Kucharska  39:07  
user how to

Lindsay Velecina  39:08  
create one

Magdalena Kucharska  39:10  
will give you one example of a sprint goal, users are able to log in via Facebook to our website. So it's a short everybody knows what it's all about. It's written from the perspective of the user, and you know how to achieve it. So you are you when looking at the sprint goal, you as a team are able to answer when will it be done? You know what the impact is, you know, what's the preferred output that will come up by the end of the sprint? You know what to look for. And also when creating a sprint backlog, it's understood to everybody is transparent, and you know which items of the PBIS can help you create and deliver the sprint goal. Keep in mind not everything in this sprint backlog needs to adhere to the sprint goal. It could be one ppi, it could be 10, PBIS, doesn't really matter, it could be in the area of PBIS to the sprint goal gives you the goal. So that will be like a short, very short answer from my side.

Joanna Plaskonka  40:16  
And I have a longer one. So when you when someone asks me like, Hey, could you help us create three ENCODE? My typical answer is yes. But you know, what? Could you please tell me? What is your product called? And maybe even earlier? Could you tell me what is your product?

Magdalena Kucharska  40:32  
What you're doing is for?

Joanna Plaskonka  40:35  
Exactly who is your user? So my personal recommendation is to start with those. And I would add one more. So what is the product? Who is your user? What is your product goal? And what is currently additional one? What is the currently maturity of your product? Maybe you have more products, maybe they are on different levels? why I'm asking that, because Scrum is not a universal tool to fix it. All right. It's, it's the not, if you have pure maintenance work, I used to have such work for some time, Scrum did not work perfectly. We were we felt that our work does not need those events. Instead, we focused on Dum Dum Dum Dum flow. So maybe there might be some other tools that will help you find the best possible approach and as a PSD, Scrum is in our names, I will still say it's okay not to Scrum, it may not be the best tool for you. However, what I observed is that one of the reasons why it's difficult to formulate sprint goal, which should be a step, you know, smaller step towards something bigger, something flexible, but as Magda showed us, in our example, something that helps understand why we are doing that. What is the value? Okay, so it has, it could be very easy to understand, by everyone involved. Why, why the scrum team is working on that. So, I would start with asking you, your team, your product owner, those questions, because those questions might lead you to a quite interesting

Magdalena Kucharska  42:28  
conclusions. And also in in Scrum, without this protocol, you probably don't know what you're working towards, for you don't know what to inspect and adapt at the end. Your dailies become just, JIRA opened a new goal, task by task because there's nothing to focus on. So it's really important to have the shared understanding of the sprint goal as a step towards your product goal.

Lindsay Velecina  42:55  
That's great advice. Thank you. So this next question from Craig, gonna dig into your experiences a little bit. So can you discuss some of the best and most challenging interactions that you've had with leadership and stakeholders? Craig is looking for tips or specific techniques that you use with getting stakeholders to see the true impact of implementing Scrum and the agile mindset.

Magdalena Kucharska  43:26  
That's a tough one. worst situation.

Joanna Plaskonka  43:33  
I can start with

Lindsay Velecina  43:34  
some of the best and then go to the worst.

Joanna Plaskonka  43:36  
Yeah, I can start because I feel like from you know, stress and responsibility that I feel from one point of view, every such conversation is challenging, so I can work and I used to work with different leaders, including C level executives. And what I feel there are a few things that you have to be careful. If you are just using we call it in Polish round words. So you're we have to do it because it's good, because it's nice, because everyone is saying Scrum is great for complex problem. Well, this language, this conversation may end up with them. Why you're telling me those things? Why? Don't want to distract me, I have plenty on my table. Right? So good. Good advice. Good approach, from my perspective is what kind of problems do you have? What bothers you? What are the things that you think about when you start work in the morning? So if you want to have a good collaboration with leaders, present yourself as a partner, so for me, what really, really pays off? Was having transparent, respectful conversations about problems? Helping leaders facilitate difficult discussions, one of the most difficult discussions that I had involved CEO, CTO and very valuable developer very experienced one. And there was a conflict, there was internal conflict. Very tough situation everyone is red seems like they are they are very unhappy. And I help them using Scrum values scrum principles to facilitate the discussion into the right direction. So I try to paraphrase what they were saying, for instance, Magda, did you mean that you wanted to emphasize that you care about your work? Yes, yes, this is what I wanted to say. You can imagine that it was a communication problem. And at the same time, it helps us to find the right questions. Okay, what we want to achieve, right, right, right. Now, what is your perspective, you ask one person, what is your perspective? So it helped, it helped, we were able to, to to have this conversation till the very end. And although finally this engineer, this developer decided to leave the company, I felt that we ended up this relationship as good colleagues with a lot of respect. And this is what in my view, Scrum is about about values about trust about respect. Yep. So I hope it helps, you know, do not talk about wonderful ideas, maybe change perspective, how can I help you what kind of problems you have, use the best that you know, we use the best your skills to help them? Because then you build a partnership. And they may ask you questions. So Monica, how can I help you do you do you have also some challenges. And here you go, you have now opening, pouring great conversations with important decision makers in the company.

Magdalena Kucharska  46:54  
So what works also for me is when talking to managers, and leaders, some CEO is asking, why did you want to adopt agile or scrum in the first place? What kind of problems we try and resolve. If your problem was, let's say, time, you want to improve time of deliverance, or whatever you do to your customers, then we need to focus on that and build our goals or product goals or sprint holes around time. But you cannot tackle every problem that you have at once. Because if everything is important, then nothing is important. Right? So go back to the reason why did you want it in the first place. And what really helps also is one of the last lines in the scrum guide is like, although you can use some of the elements of Scrum, if you want to have the full power of the inspection and adaptation and transparency, you need to adopt whole of Scrum. You can have the events, you can have the artifacts and commitments. But if you resigned from each of those, the value you wanted in the first place will not be provided. So if you want to have value, you need to adopt all of it and learn from it. Right? It's empiricism. So what helps is that? And also the other part, let me adapt to that. I often ask. I'm gonna be honest about budget about money, because the company's reason to exist is to bring customers the product they need they want. And the second one is to gain profit. So if you're choosing some kind of behavior, some kind of an action, how is this going to help profit your product, right? If it's called if you wanted to, if, if your actions as a micromanager, let's say if you want to micromanage your people, it takes a lot of your time. Right. So if you pass some things along, you'll have more time to do more valuable things for the company and for the product than micromanage. And maybe if you see some behaviors, like micromanagement, or any other behavior that might disrupt the work of the scrum team. Also try to get into reason behind that. Maybe there's a small step you can do towards there is this tool called delegation poker delegation word. That very roughly, I'm gonna go very quickly explained, there's more than one level of delegation. There are seven levels of delegation and moving from the first level, first of all, it's just telling someone to the next level with a bit of a selling point can be also a big step. So I'll also advise you to look at this tool. The delegation worked in delegation poker as a tool to have a discussion with your manager what thinks that he or she can give up?

Joanna Plaskonka  49:53  
Yeah, and again, we are touching the bases for for one of the bases. Our bedrock is wrong values supported by trust. So you can use delegation poker to talk about trust because this is without trust. I cannot imagine professional scrum helping you flourish.

Lindsay Velecina  50:15  
Thank you both for that. That's great. So this next question here, the leadership team believes the sprint review is taking too long. It is a two hour meeting, and we demo and show progress and address what is next. So there are five teams who review, inspect and adapt. And these two hours, feedback is stopped in literally 30 seconds. So people do not provide feedback. What can we do to improve? So

Magdalena Kucharska  50:50  
I'm gonna try to answer a bit however, I'm missing some context. Are those teams working on the same product or not? That will be like a key question, because I'm gonna assume like both ways, let's say if those teams are working on the same product, they should not represent their own work, each by each team, what they delivered, because they're working on the same product, and the total of what they did their increments, is the increment of the product. So they should present it present is not the perfect word, I'm going to change it, they should discuss it, and gather feedback around one increment that they deliver, not one by one. In the other case, if those five teams are working on something totally different, then probably they have different stakeholders, they have different users different products. So it doesn't really make sense for them together sit together in one meeting, because some of the people just not be interested in that part. And also, other other things like other side note, if stakeholders is saying your event is too long, it comes back to the question of value. Does it give value to them? What do they need? What kind of information they're seeking for? And what kind of feedback are they gathering? Do your stakeholders actually know what this event is for? Right? Maybe there's kind of a conversation between the scrum master product owner before that before the sprint review, what is what is important for them? When we do we have I have like a couple of teams working together. And one of the teams has is building a very broad product. So depending on who uses which kind of service of this particular product, there's a different target audience, what we do with every sprint review, we provide an agenda, saying what exactly what were the exact elements that we worked on during the last sprint, and only the people who are interested in that and can give you not only interest and then give you valuable feedback, because sprint review is a feedback session pretty much. So you can inspect and adapt towards your product. Or I also heard the word demo. Maybe if you're doing a demonstration, instead of collaboration, they do not feel involved or just sitting and looking at your product. If it's a software product, let them click on it. Let them use it. Get them involved. Sorry, that was supposed to be short answer, the longer so Joanna to you.

Joanna Plaskonka  53:21  
You said a lot of good stuff already. Amanda. Thank you. So one of the best sprint reviews I've seen. It was not a demo. Remember, in Scrum, we've never been talking about GMO. It's actually what do we want show working product work together on increment on inspecting increments. So the best sessions I've seen CEO sit down in front of laptop and he was using the product. And I remember that people were amazed, you know, looking at the potential user using the product, you know, so that was a very, very good and indeed, I would call it collaboration and feedback session. And remember, feedback is not only about talking, what I would even say we have some, some research, some people claiming that talking to people is just one side of the coin, what is most important to understand how they actually use your product. That is a really strong feedback part of your sprint review. And I would ask as Magda mentioned, what should be changed your stakeholders so that you will get value out of it? And what I implemented in one of on one of my situations, we had regular feedback service very short. However, we were constantly asking feel free to be invited to make change. We hear your feedback. So every sprint review, we did some small adjustment and you may be shocked how big changes happened when we when you compare first sprint review in They are and the last one, right? Because small changes, you know, regulary introduce inspecting, sometimes it means going back and forth, right. But those small changes made a huge, huge difference. So maybe you have also a product portfolio. And I wouldn't claim that it's not okay to have two hours working session, it might be a matter of how to do it well. So there are also some other techniques for Sprint reviews, when you want to do do such thing. Maybe you can use some breakout rooms, you will have some you know, introduction, what is going to happen in this breakout room, we are working together on this part and the other something else. What my teams also do, they send official information to all stakeholders, hey, we finished our planning, this is our sprint cup. So sprint has just started and the stakeholders are already informed, very straightforward for us in very straightforward way. This is our commitment. This is our sprint goal. So expect value when it comes to that particular goal.

Magdalena Kucharska  56:13  
Remember, when we say stakeholders, we mean also clients, new users, because sometimes in the company stakeholder is just the person within the company, some project manager, some director will never actually use your product. Sprint Review is also to gain feedback from your clients and users. When they work as a medical company. We just took our laptops or went to the reception and asked the patients that registered for visits to click on our new system. And I mean, the faces of the developers was like, don't click there, don't click there. Actually consider patients going to click there because it's intuitive for him. But it's not how our developers designed. This was the best feedback that we had was just asking random patients in a medical facility to click on our product.

Lindsay Velecina  57:03  
Some great discussion here. Thank you both so much. Unfortunately, we are coming up on our time already. This hour really flew by. And there's still a lot of open questions. So like I had mentioned, I am going to share these with Jana and Magda, and I'll work with them on figuring out how we're going to address these open questions. We do run these sessions about once a month. So please keep an eye out for these sessions. Just a reminder, we do have learning paths and lots of free resources on the scrum.org website. So please check those out. And all of our webinars are also listed on the website. And please stay connected with us and with Jana and Magda, and Magda and Jana, if you want to let the audience know how they can best connect with you. That would be great.

Magdalena Kucharska  57:54  
Yes, thank you. Thank you, Lindsay. Thank you, everyone for participating a lot of her questions. I mean, I feel like the session can go on for a day or two days without an end. So the best way to reach me is via LinkedIn. So feel free to just invite me via LinkedIn. I see John are nodding. So probably, that's also the best way to get in touch with us. And in terms of questions, we'll try to put them into a series of blog posts on ScrumOrg. So they're not lost, and you can access them forever and ever. Oh.

Lindsay Velecina  58:26  
Sounds great. Thank you both so much for sharing your experiences today and helping our audience out with their questions. That was greatly appreciated. It's a very fun session. And I hope everybody enjoyed it scrim on,

Joanna Plaskonka  58:41  
I enjoyed it a lot. So it was great experience. Thank you ladies. And most importantly, thank you all for your time, because sometimes it's one of the most precious things that we have our time and you decided to spend this time today with us. I really appreciate that.

Lindsay Velecina  58:59  
Thank you everyone. Take care