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
