Ask a PST - Product Backlog Management with Stas Pavlov and Simon Flossmann - Scrum.org Community Podcast

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Lindsay Velecina (00:02):
Music. Welcome to the scrum.org community
podcast, a podcast from the homeof Scrum. In this podcast, we
feature professional scrumtrainers and other scrum
practitioners sharing theirstories and experiences to help
learn from the experience ofothers. This episode is a
previous recording of our liveask a professional scrum trainer

(00:22):
series where a live audienceasks questions of professional
scrum trainers. We hope youenjoy this episode.

Patricia Kong (00:30):
Hello, good morning. Good afternoon, good
evening. Welcome to Ask a PST,product backlog management. Oh,
we have Simon flossman and SASPavlov with us today. So we'll
be taking your questions aboutthis topic. I'm very interested

(00:50):
to see what type of questionseveryone has, and also what type
of experiences and advice Simonand Sass will be sharing. So my
name is Patricia Kong. I'll beyour moderated moderator today.
Just some quick guidelines, yourmicrophones will be muted
throughout the session. Isrecorded, the recording and

(01:12):
slides, our colleague, Lindsay,will get them up, usually within
24 hours. And so please use theQ amp a icon and submit your
questions. I'll be keeping aneye out for them. I forgot to
say hello. Hello, Simon. We'vebeen chatting for like 20
minutes already before this. Iforgot a little bit. Excuse me.

(01:34):
All right. So who is scrum.org?
We're founded by Ken scrumor,the CO creator of Scrum, and he
is our chairman, and we have amission@scrum.org that
originates from him in helpingpeople and teams solve complex
problems. The company itself isfocused on training, education,
community. SAS and Simon arevery intertwined in that, as are

(01:55):
all the PSTs and myself andmaking sure that we can get our
ideas and learnings from you andwith you outside in the
community. So before I hand itoff to the PSCs to introduce
themselves quickly, I just wantto say that this is a really
interesting topic, and one ofthe reasons I'm moderating is

(02:16):
because last year, when I waslooking at our scrum.org data,
there was a lot of people comingto the scrum.org website because
they were researching aboutproduct backlog and product
backlog management, and so Iwanted to make sure that we were
capturing the type of resourcesand content that might be
needed, facilitating theconversations that we can have.

(02:36):
So we're hoping to do more ofthose where we'll take a look at
the data and see what topics arehelpful to EU with that. Then
Simon, may I ask you tointroduce yourself.

Simon Flossmann (02:51):
Hello, everyone. My name is Simon. I
started my career actually as aproduct owner at a big German
company where we built homeappliances basically later, I
joined consulting mostly as ascrum master, but my main focus
was to help product ownerimprove. And over the years, I

(03:12):
think I have seen a lot ofproduct backlogs from small ones
with just a couple of goals toreally large ones, so maybe more
on the specification site, andin the last year, I tried to
pass on my knowledge and all mymistakes I made over the years
so that you don't have to makethem again. I think it's much
more fun to learn from mistakeswithout doing them. That's all

(03:37):
from me.

And where are you? Based? Simon, Germany.
Okay, could you

Stas Pavlov (03:46):
introduce yourself, please? I can. So my name is
stas Pavlov. I'm a PST based inthe Netherlands, in The Hague
area. I call myself a productleadership consultant. That's
not, that's a made up job, bythe way. It's something that
helps me to summarize what I do.
What I do is talk about productmanagement and agility a lot,
and mostly by either advisingpeople or by trading people. I

(04:08):
enjoy both. I'm firmly rooted inmy experience in the product
product management world, done alot of products ownership as
well. Made a lot of mistakes.
Managing my own product backloghelped a lot of people fixing
some of their mistakes and notrepeating my mistakes. And I'm

(04:32):
currently working at aconsultancy firm in the
Netherlands called cowanas,where I get to do all of these
fun things, aside from alsobeing a professional scrum
trainer with Scrum dork, andlast December, I started a
YouTube channel together with myfriend and fellow PSD Bart,

(04:53):
having a lot of fun doing thatas well. And yeah, talking about
products and agility more overthere as well. Yeah. Looking
forward to this one. Trish,

great. So for people who just joined on, we're
doing an Ask a PST, so pleasesubmit your questions. We're
starting to get some in. As westart to get those in, I wanted
to ask you, Simon first, what isthe biggest challenge that
you've seen as like a commonthread with your customers in

(05:26):
terms of managing productbacklog.

Okay, we can tackle it with an interesting
story. So I think I don't know.
A couple of weeks ago, I stayedat a hotel, and after checking
in the hotel and going to myroom, I discovered there is no
Wi Fi, and I actually had to payfor the access path for one
night. I think it was around sixor seven euros, which was kind

(05:53):
of interesting experience. So myquestion to you, does is having
a Wi Fi, a feature of a hotel,and what kind of feature Do you
think it is?

I don't feel it is a feature, to be honest. I feel
it's something that you expectto be there. It's a I would
almost call this rude, but maybejust because I'm Dutch, yeah, I
would expect this to beincluded, not having it feels
like you might have stepped intoa time machine. Yeah,

exactly like insulting consulting to ask me
to pay for that, yeah?

Maybe like in an airplane, I don't, I understand
it, but in a hotel, no,

yes, and I was, I was thinking a little bit
about different features of ahotel room, so I would be a
little bit embarrassed if thebathroom or so would be outside
of the room, or something likethat. So you, you used to have
Wi Fi, you used to have abathroom, a a bed and so on. And
we are, I'm not used to have ahot tub or something like that

(07:10):
on the floor. And that's aninteresting observation I made,
which has been done very acouple of years ago. I think
it's from the 80s, where one, Ithink it was a Japanese
researcher, asked the question,do more feature make the
customers more happy? So theperformance of a feature, if

(07:34):
it's increased, does it providemore value to our customer? And
it turns out, no, there were alot of studies done, and his
research is based on it. It'snot about the amount of feature
you have to improve your productwhich makes your customer more
happy. It's about the emotionalreaction on to a feature. So

(07:55):
what does it mean? So forsimplicity, we can divide
features, or something like thatinto three categories, which are
the must haves. These are the WiFi for your hotel room. Then we
have some kind of performancefeature, which means the more
feature or the more quality ofthe feature you have, the better
the experience for the user, themore value you could create. And

(08:17):
there are some features whichyou do not expect. Kano, the
founder of this model calledthis one, I think, delight us.
And why is this an interestingstory? In terms of product
backlog management, I thinkthat's one of the most common
problems. And what I experiencedover the years to understand

(08:40):
that not everything has the samevalue, and not more finished
product backlog items mean morevalue for our customer. And the
question is, what do you work onand what not? So what do you
prioritize on top of yourproduct backlog and whatnot? And
I think that's the most criticalpart, because of the end of the
day, resources are constrained,so maybe stas you can add

(09:03):
something to it from yourexperience,

yeah, I love the topic of product backlog
management. It's one where Istruggled with a lot when I
started out as a product owner,initially I focused on really
trying to create these perfectPBIS like I was reading books on
user stories, stuff like that,reading a bunch about how to

(09:29):
actually write requirements. Andat some point I was really good
at writing, like perfect userstories, really good
requirements, only to find itdidn't help me at all. I was
able to perhaps better confusemy team and my stakeholders,
because I kind of forgot thatit's really important to do this

(09:50):
in collaboration and to also putit into the context of having a
product vision, a strategy, andreally setting goals like, why
is this thing valuable? I. Andwhat I find interesting about
prior backlog management, it's atopic that's both over
emphasized and under emphasizedin importance. What I mean with

(10:11):
over emphasize is like we reallyjust spend a lot of time writing
things in a specific format,which really there's no reason
why you should. It might behelpful, but there's people who
claim that we need to followthese strict formats. You really
don't. But also we tend tooverestimate the importance of
the stuff that's actually on aproduct backlog. Because people

(10:34):
talk about, well, these thingsare valuable, and that's not
true. Everything on your backloghas zero value. It's potential
value, but whether or not it'svaluable requires an actual
release and an actualconsumption by a customer. So
perhaps it's better to spend aslittle time as possible and then
get it out to a customer, shipit, see what it does.

All right. Well, then on that note, thank you for
sharing those stories. Thinkthat conversation station
started a little bit in the chataround MVP and all those things,
which is really interesting,right? Because, oh, we could go
down a rat hole, and I want tojump in, and I'm trying to
resist, but I'd like to get toeveryone's question. So most
valuable payer, right? I'm gonnastart with these thoughts, and

(11:20):
I'm going to try to just justread these as these are, to make
sure I'm getting the thequestions correctly. So first
question, I am the scrum masterfor the only Kanban team in our
department. The Businessstruggles to track the value we
deliver because our backlog andthroughput are measured at the

(11:41):
story level, rather than thefeature or epic level. What tips
can we use to meet the businessneed for a three month roadmap
while still maintaining a kanbanapproach?

There's a lot to unpack here, to be honest, not
so much the Kanban stuff, butthe business need for a
treatment roadmap approach wasstill maintaining a common
roadmap was still maintaining acommon approach. I think you
can, for me, it seems that youmight just need to have a bit

(12:16):
more admin rights in I'm notsure if it's JIRA or Azure
DevOps, it's either one ofthese, these ticketing tools
that could help. But for me,this is really more of a symptom
of a organization that reallywants to understand when stuff
will be delivered, which is afair question to ask, like, if

(12:37):
something's on the backlog,there's an expectation of
delivery and the people notbeing able to report on when
that will be in a reliablemanner, that could be it. In
that case, adding more stuffinto a ticketing system is
probably not going to help. It'sprobably better to instead have

(12:57):
a conversation with the peoplerequesting these things and
really trying to understand, whyis it that you need this
information, and how can weprovide this information to you
in a clear and concise manner?
Because, let's face it, if thisis a bunch of slides, nobody's
going to read all of that stuff.
We don't, simply don't have thetime for it. Have a conversation

(13:18):
with the people who are askingfor this stuff and really trying
to understand, what is it thatyou need to

know? Sounds like the story. Story done, 123, like
it's interesting

to see. It's an it's a focus on output rather
than on outcomes. So you shouldbe having a conversation about
value. But maybe before you can,you really need to see, look
into the predictability aspect.

Anything to add?
Simon,

yeah, I would tackle the idea from stas or the
question from the same idea asdoes. So if going from story to
Epic to theme just makes thisthe requirement bigger and
bigger. That's one direction youcan take to derive to a roadmap.
There's also another direction.
It starts hinted at it. And youcan also start at the story

(14:09):
level and ask yourself, Okay,with a story, you want to
produce something, and who doesit benefit? And what's what's
benefit, which is typically thenotion of an outcome for your
users and customer, dependingmaybe you have internal
customer, external customer.
This doesn't really matter, butwhat behavior change you want to

(14:33):
see on their side, with benefitsthem and on the long run the
organization. And you can comeup with a road map and try to
specify these behaviors you'relooking for. It's a different
approach. It's more like a goalsetting roadmap. And I did this
a couple of times, and thentypically you get pushback,

(14:55):
because if you don't know whatto build, how can we forecast?
That's. Fine, but you can try tocombine both. So you can try to
make goals which a little bitmore outcome driven, which try
to specify specific customeruser behavior you want to see
one hand, and then your productbacklog items could be bets onto

(15:17):
it, but leave a little bit room.
Maybe something will change. Youwill learn some stuff, and the
behavioral change is not so herewhat you're looking for, then
you can add stuff to it whichcombines both sides. You can
provide a little bit morepredictability on the outcome
for your stakeholder, but youhave a little bit room to add
new ideas to it. That's one wayyou can try. It's totally

(15:41):
different as what stuff said Isaid at the beginning, and it
doesn't matter if it's Kanban orScrum, I think so. Yeah,

there sounds like there's some fundamental things
to think about there, and somegood techniques. So Simon,
staying with you, this is a goodquestion. My product owner is
new to his role and needs me toadvise him on different
techniques for prioritizing aproduct backlog. He's the
product owner of one team withinan agile release train. Any

(16:15):
ideas for me to help him withchoo choo?

Okay? A couple of ideas. So it depends a little
bit on this situation. So Ithink the first thing you should
help them is to learn about thestakeholders. I know
stakeholders are very broad termhere, so we can look at actually
users, customer or, to behonest, sometimes it's more
likely internal stakeholder youwant to satisfy. I would say

(16:42):
that's the first idea, toconnect them. There are
different techniques, likemapping techniques to know your
stakeholder, who are yourstakeholder. You can look at
processes, where does the workcome from? Who are you
interacting with, and these kindof things to get a sense. I
think that's the first step. Andthen at the end of the day, you
need to talk to them, what's ontheir radar, what they want to

(17:06):
achieve. That could be onesource for prioritization. It
doesn't have to be the ultimatesource, but it could be a
starting point. Maybe stas youcan add some more. Yeah,

anything?
Anything to add there in termsof other tips, because I'm going
to get you on stakeholders next.
Yeah,

I love this question, by the way, because we
need to understand that. So I'llbriefly take you to my most used
priority prioritization methods,which is number one, my opinion
usually based on insights aboutmy product and talking to

(17:47):
people, maybe just not opinion,but usually there's a story
attached to it second, andthat's a shared second place.
There's it's either the opinionof my team or the key
stakeholder I know could be theCEO, or whoever is paying the
biggest part of your budget, andthe rest number three will be

(18:10):
other stakeholders opinion. Andthe thing that I will do is I
will sometimes use tricks, ifyou will, to translate that
opinion to I know some kind ofnumber like I will give them a
bunch of Monopoly money thatwhich they can then divide on
which features they might wantto invest in the most. But the

(18:33):
reason why I call that a trickis because it's not true. We are
trying to quantify opinions, andthe benefit of these methods is
that it allows you to have aconversation about, why are
certain things more importantthan other things? And it could
be a bunch of factors, right?
But you need to have thatconversation. Maybe some kind of
formalized process helps thereas well. You could use stuff

(18:55):
like value poker, both forefforts and for for business,
you can use methods like ice orjust an opinion, because the
thing is, you don't know whetherit's true unless you start
releasing it, and there's a verylow correlation between your
assumption and the actualoutcome.

So can we pull on that a little bit more? There's
the next question. So you'vegiven some examples, some
techniques, and I'm sure you'vebeen in this situation. I have
myself. How do you handlesituations where different
stakeholders have extremelyconflicting requests to Yvonne,

(19:41):
I'm actually giving a webinar.
I'm doing a webinar next week onthe art of negotiation and
product management. So thatmight be something you want to
catch on to, but But you have anexample and maybe how you
handled something where therewere very conflicting requests
as a product owner. It.

There's always very conflicting requests. It's gonna
depend. And I'll start with itdepends, because I'm gonna use a
lot of words to make that samepoint. Usually it's a sign of
maybe there's a lack of cohesionor a lack of understanding
between in your stakeholdergroup on what is it that's

(20:23):
actually important here, orwhat, what is our actually,
actual product? I find itinteresting that we tend to have
a different definition of theidea of a product inside an
organization and outside of anorganization, and we are able to
hold these two conflictingdefinitions without even knowing
it inside an organization, wesometimes qualify just a random

(20:46):
system as a product, becausesomebody needs to own it, and
that's fine. Sometimes that'spart of a bigger product.
Sometimes that's maybe a bitmore of an internal product or a
shared service, in which caseyou might not have that many
ways to actually steer thedirection of the product,

(21:07):
because you're part of a biggerthing. If that's unclear, then
everybody will just have anopinion on what the product is,
and then they will steer in thedirection that's most beneficial
to them. In that case, fix yourstakeholder management, if you
will.

Thank you on that note, let's just No, I'm
kidding, Simon, this is for youtwo part question. I'm going to
combine two of them. What areconcerns with the backlog that
only grows at a much faster ratethan delivery happens. On top of
that, how do you man, how do yourecommend handling defects in a

(21:47):
backlog? So one is, what do youdo with a backlog that just
keeps growing you don't see thedelivery happen? And what do you
think about handling defects inthe backlog? I don't know if
this person is maybe tryinglike, oh, let's pull them off,
let's put them on.

That's an interesting one, so maybe let's
start with, why do we have abacklog in Scrum? And Scrum is
all about creating transparencyso that we can inspect and adapt
and do this as informed aspossible. So we should make as
good as possible, try to makegood decision as possible. Now

(22:28):
we have three artifacts in scrumto provide us transparency. So
we have to increment thissomehow represents the past. So
that's the stuff we already did,and we have to sprint backlog
what we are working currentlyon, and then we have some ideas
for the future. So we think thefuture might look like this.
That's the product backlog. Andthe moment we can make all three

(22:50):
artifacts transparent. So wehave a product increment or a
product we have sprint backlog,and then a product backlog, we
somehow make the whole timeframe transparent. So that's the
thing here. Now, what has it todo with product backlog
management? In order to make aproduct backlog transparent,
there are a couple oftechniques, but to be honest,

(23:12):
the number one technique for meto make it transparent, it
should be short. The larger itgets, the less transparent it
gets, it's you cannot. I don'tknow how many items you can keep
up in your head. When I thinkback on my time as a product
owner, the first position I had,we started with one team. At the

(23:33):
beginning, for a couple ofsprints, I would say we had 5200
items, and one day we had 100and something, and it was
unmanageable for me. And then wescaled up to three teams over
six months, it was a completemess. Nobody knew what to work
on. I had no clue what are theitems anymore. So I don't want

(23:54):
to say you should have a fixedamount of numbers, so no more
items than 20. This makes nosense, but the moment the
product owner does not knowwhat's in the product backlog,
you should think about deletingstuff, combining stuff, make it
a little bit more abstract tohave a better overview, and you

(24:16):
need to re refine the stuff ifit comes More closer to
implementation. So that's onething here, and I wasn't sure,
was the question that there isno release at the end of the
sprint. It's

basically that it's growing and they're growing
faster than delivery. The secondpart was handling defects in the
background. Okay,

so thumbs up.
If you're able to release,that's a good thing. Then you
learn, and then you know what todo next. But from a transparency
point of view, try to limit itsomehow. And I think we have a
cool new tool for that, and itwas introduced to scrum in 2020
that's the product goal. Nowlet's think about a time

(25:01):
horizon, for instance, of threemonths for a product code just
to say something. I think thenthe amount of product backlog
items in the next three monthsshould be the product backlog,
and not much more. So the scrumguide is pretty clear on that.
So the product backlog shouldderive from the product goal.
Everything else maybe should notbe part of the product backlog.

(25:26):
At the moment, it's a little bitdistracting. That's one thing
you can think of it. And interms of box, I have an opinion
on it, I would put it to thebacklog. Otherwise you don't get
transparency. But I know it'spretty hard for product owner to
decide, should we invest in anew feature? Should we invest
and maintain? Should we investin box? Therefore it should be

(25:47):
on one list. And I think that'sa good starting point. If you
have two backlogs, thentransparency is reduced again.
Thus,

what is your opinion,

don't have two backlogs. I didn't really don't
know defects. Yeah, definitelyput them on there, make it
transparent. But I think maybe,to add to what you just said,
Simon, I think it's important tounderstand what we actually mean
with transparency, like it's notjust visible, it's visibility is

(26:24):
a really tiny part of theconcept of transparency.
Transparency is much more aboutdo we understand what's going
on? And that's the entirepurpose of a product backlog, is
to make transparent what theplan is to maximize value. So a
really good way to test thetransparency of your product
backlog is show it to astakeholder, and if that will

(26:47):
then trigger a conversation thatdoesn't start with huh, but
actually talks about the productbacklog, that's a really good
indication that your stakeholderis able to see your Product
Backlog, understand what's onit, and have a conversation on
on one of the things that's onthere, and really have a
conversation about the details,perhaps as well. That doesn't

(27:11):
come just by having perfectPBIS. You need to do a lot of
collaboration together with yourstakeholders, together with your
team. Specifically refinementsis much, much, much more than
just sitting in a room talkingabout how many story points
something is. I think that's themost boring and perhaps the

(27:34):
least productive part of productbacklog refinement. Involve your
stakeholders. If there'sdefects, definitely put them on
there, make them transparent toyour stakeholders. These things
are problematic, fix them.

Would that be how? There's another question
that's relevant in here, aboutin terms of the prioritization,
because just because there's abug doesn't mean you address it,
right? So how do you know whatto do?

Yeah, absolutely a certain bugs you need to fix
immediately. Other ones. If theyhappen once a month, you might
be fine. Maybe you're in arelease freeze. If you're an E
commerce, usually during theholidays, end of the year, you
might not want to do a release,because that's where you make
80% of your money. I've been inthat situation. You will have to

(28:20):
live with that book.

All right, so I have just changing speed a
little bit. This is a greatquestion for both of you. I'll
just start with you. Stan, so asa product owner, I will
probably, probably say, I ownthe product. I own the backlog,
Extreme Ownership, etc. Iordered the items. I tag them, I
label them, I categorize them, Iquestion them, I close them,
right? They're they're doingeverything the question, I'm

(28:46):
afraid this could result ineveryone else saying so the
team, the stakeholders, goahead. It's yours, your
responsibility. We see that.
Thank you. We're not you are notto blame if anything is wrong.
So now it starts to feel like aone man show. I'm a
perfectionist, which makes ithard to share responsibility.
What is some advice for thisperson on how to overcome this?
Or is that even necessary? Love

the question. And by the way, thanks Eric for
sending this question. Actually,Eric was in one of my classes
yesterday for the products,professional products and
discovery class was a lot offun, but great question. This is
exactly the thing that I raninto when I started out with
product ownership. I was doingit all by myself, and what we

(29:34):
need to remember is that productmanagement is really a team
effort. It's a team sport. It'snot just you, it's your team.
It's also your stakeholders. Ioften say that a good product
owner, a good product manager,is a lazy one, and I don't mean
that you need to be actuallylazy, although I am, but what I

(29:56):
mean with that is don't just doeverything yourself. To give
some work to your team, but alsogive some work to your
stakeholders. Collaborate withthem if you want to really
improve the quality of yourproduct backlog and the
transparency, perhaps, do someco writing on product backlog

(30:16):
items, not just you writingeverything and then explaining
to the team what it is that youwere trying to bring across
here, and what I really like forthis specific topic is a really
old, old concept, actuallysomething that was start off in
the 90s, when the initial ideaof a user story was created, and

(30:38):
that's the 3c concept, card,conversation, confirmation, and
I kind of compare that toeverything on your backlog
should be kind of a pause buttonfor a conversation. And you
might have a conversation withyour stakeholder on some need or
some problem that they have, andthen at some point you need to
continue with today and themeeting is over, you just want

(31:02):
to summarize whatever that wastalked about in a few
statements, maybe a couple ofwords, perhaps on a piece of
paper, and put it on yourproduct backlog so that when
needed, you can immediately goback into that conversation,
almost like it's a pause and aplay button for that
conversation, collaborate withyour team, with your

(31:22):
stakeholder. And to be honest, Isometimes pretend like I don't
know how to write productbacklog items when I'm dealing
with a new team, just so I cansee how they actually go about
it. And then I kind of stay inthat groove. We do this thing
together, and we have aconversation, and then you get
really concise product, buteverybody knows where we need to

(31:44):
build and why, which is thewhole point? I hope that answers
it.

I think that was great. Lots of techniques I'd be
interested in. Simon, if youhave some suggestions on a
little bit of the deeper levelof or different level of this
notion of this person is tryingto share that responsibility,
and they feel like this is soimportant. So that person, you
know, Eric's going to go and doeverything that staff says, but

(32:10):
still feels like, wow, I need todo all these things. How do you
start to move this from thatlittle bit of responsibility to
this notion of accountabilityand having that group dynamic
where everybody feels someshared ownership.

That's a That's a good one. I think it's a
misconception. Also, with thenotion of roles,
accountabilities,responsibilities gets a little
bit mixed up. And I think theaccountability in Scrum is more
like a safety net. So how doesagility at the end of the day

(32:45):
work? It's about speed, speed ofdelivery and speed of learning.
And how you enable speed is bymaking decision. So if you don't
make a decision, nothing willhappen, nothing will deliver,
nothing will be learned. So inorder to become that type, or
that agile, you need to makedecision, and that's the safety

(33:07):
net, net of a product owner. Sowhen we are unable to decide,
somebody decides not that she isright or wrong, but that we
start learning. So we deliver,get some results, and then we
can learn. So that I thinkthat's from a bigger
perspective, and I try to thinkof it as a captain of a ship. So

(33:30):
every ship has one captain, andthe job of the captain is
completely different dependingon the size of a ship. So if you
have a very small ship just oneperson, then the captain does
everything. He's responsible andaccountable for everything. So
if you look at a bigger ship,like a tanker or a cruise liner,
there is still one captain. Butdoes he do the same jobs as a

(33:54):
one person ship? Hell no. Ithink the only thing what he is
still knows what to which harborwe are going from where are we
coming? That's it. He does notsteer anything or so. He's just
in charge of the whole ship, andit's a safety net. If something
goes wrong, he can give directorders what to do to resolve the

(34:15):
situation. I think that shouldbe more the notion of a product
owner to have more free time tothink, also more on the
strategic level, and be acaptain of a real big ship. I
think that's the notion here.
But I'm not sure if this ishelpful. It's not very
practical.

I mean, it's an it's an exercise in developing
as product general. So exactly,and

I think it takes a little bit time at the
beginning, it's all aboutcreating backlogs. But the more
experienced you are, the biggerthe picture you see, the more
you become a captain of a biggership.

I think, I mean, you pulled me in. So this notion
of the captain is interesting,because you're staring right?
But Eric, I think that was Eric.
Eric, who said that Eric is aperfectionist, so if you want to
be agile, you have to make adecision. You have to be ready
to fail. You have to be ready tosay yes, which means you're
saying no to something else. Sothose are interesting things,
and that's the only way you canCaptain a ship, Simon. We're

(35:13):
going to keep on going with you.
And we have lots of questions.
This one we've talked about thisis for Fami. So one of the
issues in my PO experience isthat stakeholders always give
very tight deadlines due datesfor features migration. Because
of this, my PO has problems.

(35:35):
There's problems in terms ofbalancing between features that
the stakeholders want now andfeatures that actually improve
the system. And then, because ofthat, our tech debt is
increasing as life goes on. Whatis some, you know, one or two
pieces of advice that you havefor Fami,

we can tackle it from a more general
perspective, what is value?
There are different areas, Iwould say. And of course,
there's a time component to it.
I think does mention it. If youhave an E commerce site, then in
the holiday, the holiday season,before Christmas, there is a

(36:15):
timely component. If you deliversomething, then it will improve
the revenue much more than ifyou deliver on the summertime.
So there's a timely component toit. But that's not everything.
Value is also more on thecustomer and user sides, how
they perceive value, what theyare able to do, which problems
they can solve in their lives.
That's the next component, whichwe can think of. And last but

(36:37):
not least, there is also anotion of becoming better. How
good are we to deliver newcapabilities and stuff? And the
more technical debt you have,you either get slower or you are
less good at developing newstuff. And I think the critical
part is to balance those areas.

(36:58):
And I think the if anorganization is very much
focused or used to project likethinking, and that's the scope
needs to be delivered on thattime in that budget. Otherwise,
everybody is mad. That's a hardthing, but I think you should
look at value, at the moreholistic view, and also to be at

(37:19):
the end of the day, it'sstakeholder management to
educate them a little bit. Whatactually is value for your
organization? How does it tieback to revenue at the end of
the day? And I think there is atimely component, but not
everything. It's on thatcomponent. Now

the key value areas and evidence based
management would be a nice placeto look at the data, right? So
what's what's holding you down,what's your time to market?
What's actually contributing tovalue the future things we might
work on? So looking at in thathorizon lands, lens, lens,
lenses. Looking at through thoselenses may, may help. So take a

(37:58):
look at the key value areas,Fauci and next question for you,

maybe to add to that, because I do want to add,
we can get to that. You can makeme uncomfortable with that
question. But three things,because something about the
deadlines we need to do, we needto fix predictability seriously.

(38:23):
That's why we do Scrum. Don'tuse velocity. Velocity is trash.
Doesn't do anything forpredictability. Use something
sensible, like throughput. Justcount the number of stuff that
you finished. Use that data andactually try to do something
with predictability to yourstakeholders that will kind of
get them out of your hair.
Secondly, with regards to thetechnical depth feature

(38:45):
thingies, I have a trick thatworks for me. I'm not, I'm not
going to say that that it willwork for you, but I know maybe
it's how I sell it. Instead ofcalling them features, I because
stakeholders are kind of likemagpies, right? They want more
features, like more features,more stakeholder happy, for some
reason. So instead of callingthis thing also a feature, I

(39:09):
call it an enabler. And I knowmaybe because it's also English,
it sounds kind of cool. Andusually the story is somehow
kind of like, well, if we dothis thing, it will enable us to
do much more of these otherthings that you like like one
enabler gives you more features.
You like features, right? I knowI'm oversimplifying it, but I'm

(39:31):
trying to kind of sell it in adifferent way, and really trying
to explain what will this Howwill this actually benefit us?

Framing, yeah, no, I want to add something. Do
you want

to answer about Jared?

No, go for it. No, no, I'm fine with Go ahead.
Simon,

go ahead. Simon, what do you want to add? I think
one

key responsibility so if you're
scrum master or so, to make theimpact of technical debt
transparent. In terms of money,because the only the common
denominator for the stakeholder,what they're looking for, it's
cost or revenue or somethinglike that. It's all about money.
And I think a lot of softwareteams, at least the ones I work

(40:14):
with, are doing a really poorjob and converting their
internal work, what's neededthat the software is
maintainable and still functionswell to financial outcomes. And
if you can do that, if youcompare it to what you will

(40:35):
likely gain from implementinganother feature or something,
then the this conversation is areally different one, and that's
something you can also try. Youcan start with costs, of course,
development costs. So you can atleast add a number here. I think
that's a beginning, but maybeit's a little bit of cool
metric. But the more you diveinto it, the more you actually

(40:57):
see the financial impact ondelivery speed and ability to
invade and I think this onechanges the conversation by at
the end of the day, money iswhat drives businesses. So maybe
that's but now you can ask usabout JIRA.

That's really those are all great, great
points. Okay, sass. Are youfamiliar with JIRA product
discovery, how are new productslike this impacting backlog
refinement or management, and ingeneral, what are your favorite
tools for product backlogmanagement?

Cool, yeah, love the question. I'm not familiar
with JIRA product discovery.
I'll probably suffer from it atsome point in the future. Use So
regarding tooling, use the toolsyou have, because often you are
restricted by whatever theorganization gives you. Use
those, but try to keep itsimple. But in terms of product

(41:54):
backlog refund, it's productbacklog refund is one of my
favorite things, but becauseit's much because it's much more
than just sizing and talkingabout requirements, for me,
product backlog refinement isall about and trying to answer
the question, what is it thatwe're trying to build, and why?
Kind of like product discovery,which is also about, what are we

(42:18):
trying to build and why? Soduring refinements, that's the
place where we do productdiscovery, which I really enjoy,
because that's where we come upwith new stuff and do
prototyping. So I use a bunch oftechniques for product backup
refinements. It's really goodway to put those darn business
analysts to work, because youalways get this question, well,

(42:44):
what should I do during thisprint Well, work in product
backlog. Same for architects,same for UX people. It's all
called product backlogrefinement, easy, but you can do
prototyping, customer infused,digital prototyping, all that
jazz, right? However, a lot ofteams overlook the importance of

(43:04):
developing actual slicingskills, and it's a skill. It's
not just sitting in a roomstaring at a screen or
pretending you're staring at ascreen, screen, because the
scrum master is sharing hisscreen on the big screen. It's
really trying to understand, howcan we actually create

(43:27):
functional slices? AlistairCoburn, one of the Agile
Manifesto writers, did fantasticwork on this topic. We all know
the concept of elephantcarpaccio. It's one of these
legendary things in the world ofAgile. If you really try to

(43:47):
understand how that techniqueactually works and how you can
do something like that with yourdevelopers, there's a lot of
value there. Another version ofthat is called hamburger
slicing. It's really developingthe skills, and how do you
create functional slices, andhow do you actually have that
conversation with your team? Forme, most effective ways of doing

(44:08):
that is not using a laptop,close your laptop, either use
whiteboards, flip over, or ifyou're in a distributed
environment, use tools likeMiro. I like, I really love
tools like Miro or Miro, or evenwhiteboard, if you're unlucky,
like Microsoft whiteboard,because they allow you to make

(44:31):
these things visual and reallycollaborate with each other and
have a conversation in thatmatter. But you need to engage
people. You need to develop thisthese skills as a team. Doesn't
really matter if you developthese skills by yourself, like
it's helpful, but you need toguide your team in actually
developing these skills usingthe tools that you have. My role

(44:52):
is great. I use a lot ofgenerative ai, ai, atom. Moment,
which is great. It doesn'treplace the conversation. All
the output that you will getfrom Ai tooling is fantastic. If
you have a effectiveconversation around it, it

(45:14):
doesn't replace theconversation. That's why it's
individuals and interactionsover processes and tools. These
tools are there to support yourinteractions, and that's how you
should use them.

All right, thank you. Staff. On that one, that
was a really good speech. Wehave 15 minutes left. No, I
really actually, there was,there was, there's a there are a
lot of important reminders therethat are beyond just, you know,
tell me the tool. So we have 14minutes now, and we have lots of
questions on our backlog. Sothis one's for you. Simon next,

(45:53):
how can I as a scrum master,handle when the items in the
backlog are suggested solutionsrather than user needs for the
team to solve. I think you gavea suggestion before, if you want
to, just reiterate it quickly,and then I have another question
for you.

If the solution is done, what would be different
for our user, customer and soon? That's the question I would
ask, and that's the thing youshould aim for, that's the thing
you should write down. And let'sjust switch from output to
outcome, and it has a differentconversation, because now there
maybe is a different output aswell which creates the same user

(46:35):
behavior

you want to see.
Let's just use anything likeimpact mapping or anything like
that.

Yeah, that's some more advanced technique,
but the idea is the same, ifyou're doing this, which what
should be different for ourusers and customer? What can we
observe that's typicallyoutcome? And then you can think
of impacts as well. And

maybe to add to that, sometimes it's fine, if
it's just a solution, if that'severybody understands what it
is, keep it simple,

yeah, just know why you're doing that. Yeah. All
right, Simon, what are yourexperiences and best practices
for getting an estimated backlogquickly at the start of a
project? My goal is to be ableto create a forecast as soon as
possible. I'm assuming it willbe on a higher level feature or
epic, but how exactly, and howdo you go about getting a more

(47:24):
accurate estimate later in timeat the PBI level, so that the
possible incorrect assumptionscan be made transparent as early
as possible. This is fromanonymous.

Yeah, the thing is accurate in estimate does not
go a long way. So there are abunch of techniques I want to
share. One thing which saved me,um, my job as a product owner, I
would say, oh, story time. Sowhen we start, we were starting
out. We had a tight deadline bythe end of the year to deliver,

(47:57):
I think it was the seconditeration of the product I was
in charge. The first one was notreally good, to be honest. And I
think we had around 122 productbacklog items. And I was pretty
comfortable, the more the teamand knows each other, the more
likely, the more faster theywill develop and everything will

(48:18):
work out fine. So I was prettyconfident that 122 items with a
velocity of five, which totallydoable in 10 sprints, something
like that. And then the scrummaster took all the developers
into a room, and I was not ableto join. It wasn't allowed to
join. And then they did atechnique that I learned the

(48:38):
first time called Magicestimation, where they really
quickly estimated all theproduct backlogs in a relative
scale. So they developed one asa baseline, and then they
compared all the other 22 itemswith them, if they're bigger or
smaller. And then they came backand they told me on a rough
estimate, so it will take moretime, Simon, we will finish next

(49:01):
summer with all the stuff youhave currently in your backlog,
the one to 122 items, I thinkthey estimated for around 90
minutes, or something, to 122items, and they used some crazy
techniques. They were notallowed to talk, and these kind
of things to make it reallyfast. And what's the benefit
here? It's not about preciseestimation, because I think

(49:25):
that's a waste of time, but youneed to have a rough idea if
it's feasible or not. So that I,as a product owner, can course
correct end of the day. I thinkwe delivered by the end of the
year, maybe 28 items orsomething like that. So he he
showed me, I should focus on themost important one, because the
other stuff will not be built.
This will not happen. And theestimation effort was around 90

(49:49):
minutes. So I'm not sure if I'manswered your question, maybe
stuss can add some more cooltechniques. Oh

yeah, for sure. So interesting question. And yeah,
like Simon said, estimation andaccuracy, there's no such thing
because we're dealing withcomplex work. However, if you
want to improve the accuracy ofyour forecasting, which will
never be 100% focus ondeveloping these slicing skills
that I talked about. They reallyhelp you. Also stop using

(50:20):
philosophy. It's rubbish. Andthe reason why it's rubbish
because if you look at the data,and I've done so like a lot of
times, I know this is acontroversial topic somehow, but
the data really shows us we suckat estimating. Just think about
the amount of times that peopletold you Just five more minutes,
and those five more minutesturned into 10 or 15. That

(50:41):
should give you a goodindication on how good we are at
estimating. But this is also thereason why we don't talk about
estimations anymore in the scrumguide, we talk about sizing.
Improve your sizing. You willimprove your accuracy of your
forecast. However, if you wouldjust want to have something be

(51:03):
done faster. Just move it up inyour product backlog. That's the
easiest way, like if you wantedto get this done now put it on
the top of your backlog.
Downside is you will have toexplain to other stakeholders
why. They will have to then waitfor a longer time. Tip, have
stakeholders in your sprintreview. That's why they're
there, and then have thoseconversations there. So it's not
you trying to having to explainthese things, it's them having a

(51:26):
conversation about these things.
But use throughput, use cycletime, use work item aging. Those
type of metrics are actuallyhelpful because they are real
data, rather than an estimate,which is something that you've
made up. And then use stuff likea code of uncertainty, which is
a really easy way a burn up,release burn up, to use the data

(51:48):
to visualize when things mightbe done. Best case scenario,
worst case scenario, not themost accurate, but the most easy
one, because you just need tocount a bunch of data that you
have plotted in a graph, but ifyou want to improve it, look
into stuff like Monte Carlosimulations. Those are much more
helpful. But again, there's noguarantees here, and the more

(52:13):
variation or variability in yourproduct backlog items, the less
accuracy you're gonna have as aresult in your forecasting. It's
called the kingman's law. Butyeah, there's a bunch of stuff
that you can do. The only thingthat you can't do is guarantee.

Plus, there's another dimension we could
mention, not only the variety onthe product backlog items, but
also, if you look about team andtechnical practices. So if you
change the team every sprint, noestimate will ever work. And if
you do not invest in moderndevelopment practices, you will

(52:52):
get slower, slower as well overtime. So these are two very
important factor where, forinstance, a scrum master can
work in the background toguarantee a little bit more, I
would say I could, I don't wantto say the word velocity, but a
more stable development velocitythat I think that's a critical

(53:14):
part nobody talks about. That'sthe value of Scrum Master. Also
provides having good

coding. And maybe to add to that, whenever you say
something to a stakeholder abouta timeline, always use the
caveat. Based on what we knownow, based on the current state
of the product backlog, andbased on the past performance of
our team, our forecasts for thisspecific item will be best case
scenario then, and worst casescenario then. But that's all

(53:45):
premise on what we know rightnow things will change.

All right. So I have two more questions that I'd
like to get to that are on alittle bit of different topic.
There's such good questions, wejust aren't able to get them
through, through them all. SoI'm actually going to move to
the bottom of the list, and it'sa question from Mary as a PO

(54:14):
assigned to tech debt features,how do I have a productive
refinement session when myunderstanding of technical
requirements is a bit limited,and I'd like to expand that in
general to even, you know, whenI'm a product owner, I'm not
that technical. How do I helpwith refinement? Simon, you're
nodding. So can you take thatand give us one minute.

I think stuff's already decided. You don't need
to be a technical expert. Youneed to be a you need to fall in
love the problem you try tosolve, not with the solution,
and guiding developers withquestions and don't give up
easy. There's always a way tomake it smaller in these kind of
things. And I think stas hasmentioned a couple of things.

(54:56):
There is some how is it calledsplitting sheet with different.
Yep, years. Who did develop thisone? It's an Australian

fella. I forgot his name. He's done some fantastic
work on slicing, but I was moreover splitting tactics. We can
include it into the show notesaftercare package, whatever we
call it,

something so get comfortable with, do not
know the solution, but theproblem, and then start asking
questions. Yeah,

that's powerful, right? Because, and then there
you're talking also about,there's sometimes some sort of,
I don't want to say powerdynamic, but something when,
like, she doesn't know whatshe's talking about, so they're
just gonna, they're gonna dancearound you, right? All right.
That

being said, I think it's really helpful if you
invest in understanding thetechnique of it, like you need
to understand how your productactually works. That doesn't
mean you need to be a, be acoder, but that really helps you
to build a rapport with yourdevelopers, sit next to them,
just have them explain to youwhat is that they're doing, and

(56:04):
then really to explain thearchitecture, and spend some
time actually understanding thetechnique

and interested, yes, staff, this is for you from
Wayne. How do you incorporateITIL, change management, review,
evaluation, approvals, into theproduct backlog, I'll say
refinement process evidence isrequired for regulated
industries like banking. Youwork with a lot of clients like
this. What would your suggestionbe? I do. I

just really not an expert on ITIL at all. I would
say a whenever I need tounderstand it, I acquire that
knowledge in the moment, andthen I forget it immediately. So
let me read the question. Sofrom my limited understanding of

(56:53):
ITIL, if certain things have acertain priority and you need to
do it in a certain way, thatcould either be part of your
definition of Done, or ifsomething is deemed extremely
important, just do it.
Obviously, that's how you needto set it up. But maybe this
also adds additional steps inyour development process, and

(57:16):
add those steps as a column inyour workflow. That's why we
have these JIRA or COVID orscrum boards, whatever we call
them out in the wild. Don't justhave a To Do, doing done. That's
the most immature workflow thatyou can have. Have a
representation of the actualsteps that you need to undertake

(57:36):
in order to get something out toproduction or out to whatever
the next stage in yourdevelopment cycle is, in your
organization, which is notalways done, we want it to be
done. Sometimes it's anotherstep. And even if you're done,
you're not done. But visualizethose steps as part of your
process. That could help butmaybe. Simon, if you are more

(57:59):
knowledgeable on ITIL, and Iapologize waiting and it would
need to brush up on myknowledge. There, maybe you have
some additions.

I think, I think for me into what you suggested,
what I found really interesting,this is to looking at it from a
different perspective. Isactually assigning how long it
takes for each one of thosesteps to get done. Because
sometimes we think thatsomething else in this type, in
those types of industries,insurance, banking, is that we
need some other things. But it'sactually this process, that

(58:30):
approval process, that takes along time. I think, breaking it
down, putting that time on it tosee what, what might be an
impediment, and how to speed upthat process is

interesting, and that's again, where we try we
track work item cycle time,right? So we have this data

all right. So thank you very much, both of
you. Thank you everyone forattending, listening all your
questions we have the rest ofthem, Stass and Simon can
address them all in their afterpackage. I'm just kidding. We'll
find a way to make sure thatthose questions get answered.
And if you liked something likethis, let us know, put it in the
chat. Maybe we can do anotherpodcast episode or something

(59:09):
like this, where we talk aboutthe rest of the questions. Okay,
this has been really fun. Thankyou again. And have a great day
everyone. Actually, how can theyget in contact with you? Steph
and Simon,

thank you. That's really good question. So either
you can, if you're Dutch, Iwould say, because right now
it's just in Dutch, subscribe tomy youtube channel at your BS
link is in the chat right now.
Or you can connect with me onLinkedIn. I tend to be pretty
loud and obnoxious there aswell. Some people enjoy it. I
don't shy away fromcontroversial opinions based on

(59:47):
facts, like why philosophy istrash. So yeah, both are in in
the chat right now. Or youmight. TV on local events
meetups, or perhaps scrummyEurope in the summer.

Simon Flossmann (01:00:08):
Thank you, Simon. I think the easiest way
is via LinkedIn.

Patricia Kong (01:00:13):
Okay. Simon Fauci, all the hard questions on
LinkedIn to you, and again, I'llbe doing a lot of your questions
were relevant to this the art ofnegotiation for Product
Management. I'll be doing thatnext week with PST Magdalena
furloughed, so we have somecontent for there for you too,
and we're also working on someethics pieces in product

(01:00:35):
management, which is exciting.
All right. Thank you. Have agreat day, everyone. You doing
Cheers, bye, bye, bye.

All Episodes

Ask a PST - Product Backlog Management with Stas Pavlov and Simon Flossmann

Episode Transcript

Popular Podcasts

On Purpose with Jay Shetty

Crime Junkie

Ridiculous History

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Ask a PST - Product Backlog Management with Stas Pavlov and Simon Flossmann