June 4, 2025 • 60 mins
In this Ask a PST episode of the Scrum.org Community Podcast, guest host Lindsay Velecina is joined by Professional Scrum Trainer Dominik Maximini to answer listener questions about forecasting and release planning. Dominik shares practical insights on estimation, using burn-down charts, managing dependencies with joint roadmaps, and aligning with stakeholder expectations. He explains why normalizing velocity across teams can be counterproductive and stresses the importance of a clear Definition of Done when planning releases. Tune in for actionable advice rooted in experience, pragmatism, and common sense.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Lindsay Velecina (00:02):
Steve, 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
series where a live audienceasks questions of professional
(00:26):
scrum trainers. We hope youenjoy this episode. Hello,
everyone. Good morning, goodafternoon, good evening,
wherever you're located today,welcome to today's Ask a
professional scrum trainer forthose who are here on the live
session, welcome and those whoare tuning in on the scrum.org
community podcast, welcome. Wehave with us today. Pst, Dominic
(00:51):
Moxa Mini, and he is here toanswer your questions about
forecasting and releaseplanning. So I'm expecting this
to be a very interactive sessionwith lots of questions.
Something that I forgot to do isintroduce myself. I'm Lindsay
here@scrum.org and I will behosting our session today. So
very quickly, about scrum.org sowe are the home of Scrum. We
(01:15):
were founded by Ken Schwaberback in 2009 and our mission is
to help people and teams solvecomplex problems, and we do so
through our training,certification and ongoing
learning. We have a lot of freeongoing learning on our website.
I'm assuming that you all arefamiliar with that, so please
check that out, and I hope thattoday's session plays an
(01:38):
important role in your learningjourney as well. So with all of
that, I'd like to hand it overto Dominic so that he can
introduce himself and then wecan start diving into questions.
Welcome Dominic.
Dominik Maximini (01:52):
Thank you very much. Lindsay, well, I won't
introduce myself for a very longtime because we want to jump
into questions quickly. Just anote, I've been working now in
different scrum roles for morethan 18 years, so I'm coming
here with lots of experience,and hope to share some of that.
(02:12):
I also have been a PST since2011 so I've trained a couple of
classes since that, since then,and my personal goal is to help
people come to work with a smileon their faces, and I hope that
with all the participants today,we will get one or two of them
(02:32):
smiling when they go to worktomorrow.
Lindsay Velecina (02:36):
Awesome.
That's a good goal. All right,so thank you, Dominic. All
right. So you can start enteringyour questions. I'm going to
stop the share here see what wegot. So you could, like I
mentioned before, please utilizethe Q and A button at the bottom
to enter your questions. We canutilize the chat then for any
(02:58):
technical issues. So let me justflip a few settings here. So I
have a question here. Dominic,so why estimate at all if we
work in a complex environmentwith high levels of uncertainty?
Dominik Maximini (03:15):
That's a very, very interesting question.
Imagine you want something fromsomebody, be it something simple
like a new kitchen, or somethinga little bit more complicated,
like new house, or evensomething bigger. One of your
first question will be, how muchdoes it cost, and when will I
(03:38):
have it? And the difference inthe complex environment is that
estimates will change over time,because requirements change and
things happen. You know, lifehappens and stuff, and still,
your stakeholders and yourcustomers will want some sort of
answer, and also you want toknow if you are still on track
(04:02):
or not. So you need some sort ofplan, and you need some sort of
idea when you want to be rare soyou know if you hit your target
or not, and the way to get thereis estimation.
Lindsay Velecina (04:16):
Awesome. Thank you. Do you want to maybe, like,
help set the stage for just whyyou proposed this topic, and
what you've been seeing otherteams do to kind of help spark
some questions from theaudience. Yeah, sure.
Dominik Maximini (04:35):
Probably everybody in the audience is
part of some sort of more orless agile teams. They might be
SCRUM masters, they might bedevelopers, they might be
product owners or somethingentirely different. And all of
them, no matter in what role,will have some sort of
management in their company. Andthe number one top question of
(04:57):
management is always. When willI get it? When will it be done?
And that's true in my project aswell. So very, very often that
question is posed by some sortof management, and they need,
obviously, to know when theirbudget will be running out and
(05:20):
what they can promise theircustomers, and to get into the
interaction with management, youneed to speak the language of
management, and that language ofmanagement is pretty much
estimation. That's why I broughtit here, because it's entirely
possible to estimate and to doit in a simple way and not be
(05:41):
nailed down with a single day onthe calendar wall or something,
and there are ways to do it. Soif you have questions about
that, feel free.
Lindsay Velecina (05:53):
Awesome. Thank you. All right. So question here
that came in, if I have manyteams that make up a release, I
can see the estimates for myfeatures for the release. I know
how much time we have left, buthow do I know it's on track
using a chart? I don't know thatburn down, burn up gives the
(06:13):
full picture,
Dominik Maximini (06:16):
because of the many teams, right?
Lindsay Velecina (06:19):
Seems that way. Yeah,
Dominik Maximini (06:22):
all right. I'm not sure if everybody in this
call is aware of the burndowns.
So let me introduce burndownsfirst. There are different,
let's say tastes, differentflavors of burn down charts out
there. What they all have incommon is that on the x axis
they have plotted time and for aproduct owner or a project
(06:48):
manager or something, that'susually the sprints we have
there, and every burndown charton the y axis has the work
remaining plotted. And let megive you a short example. I'll
share my screen. I kind ofanticipated some sort of
(07:09):
question like that. What you seehere, if you are on the video
call, is a professional BurndownChart, like you would use it in
project. And it actually is froma real project of myself. It was
done in 2015 2016 so quite awhile ago, I'm getting old, by
the way. And what you see hereis, on the very top, there is a
(07:34):
200 that was the estimate forthe project scope. So in this
specific context, the boardsaid, Hey, if you want to do the
project, you have to estimateall of it, so like in a
traditional waterfallenvironment, so we estimated all
of it with story points.
(07:55):
Actually, we didn't have a clue,because it was a new team, new
technology, new product, butstill, we estimated it and get
did our best. And what you thensee here in the column that says
real velocity is we slightlyincreased it. So in the first
sprint, we got a one, then atwo, then a six, then an eight,
then a 10. And now take a noteof the burn down you see in the
(08:21):
chart right now, it's just oneline because we don't have many
data points. So if I put, forexample, a 12 in here, what you
see now is that we have a coneopening up at the bottom. So on
the upper part of the burn down,we see just one line. That's the
past. It already happened, so wedon't have to discuss it here or
(08:46):
or argue or anything ithappened. Yeah, that's reality.
And from that point on, we havean extrapolation for a best
case, a worst case and anaverage case. And you see that
it touches down between Sprint23 and 27 somewhere around that
time. And you also see twovertical lines. These represent
(09:09):
the colored dates on the verytop. These were the prescribed
release dates. And yes, we didhave to release on the 25th of
December. And yes, that wasChristmas. And no, the board was
not there when we did therelease so, but what you easily
see here is, at what height dowe cross the vertical lines? So
(09:35):
at the release date, will wehave everything? Well, in best
case, yes, but in average case,no on inverse Case No. And if we
add more data to it, let's saywe have a slow sprint. Let's say
we only achieve six that sprint.
Then you see the cone opening upgets wider. And when I talk
about estimation and. And doingsome sort of release plan. This
(10:00):
is what I'm talking about. I'musually not giving a single
date. I'm giving a cone. I'mgiving a range from when to end.
And what I usually also do is Itell management, okay, if you
want to increase the likelihoodof hitting the good date. Here's
my list of impediments you canhelp me fix, and that gets some
(10:23):
fruitful conversations going.
Now, with regards to many teams,let's say we have five teams or
20 teams, or something likethat. Obviously every team might
estimate a little bitdifferently, and that's fine. I
mean, you don't want tonormalize velocities. That
(10:43):
doesn't work. It's not costefficient. In that case, you
will have specific burn downcharts for every single team.
But when you try to put them alltogether into one graphics, it
usually will not be a burndownchart. You usually will have
something that's more resemblinga roadmap, or you will have a
(11:05):
quarterly view or something. Andwhenever a single team runs out
of bounds, then you usually putthe whole thing on red, and you
try to fix the underlyingissues. And I'm not talking
about overtime, I'm talkingabout impediments that's keeping
you up at night.
Lindsay Velecina (11:22):
Awesome. Thank you. I hope that helps. All
right, so another question,given that we are getting high
level estimates with multiplelevels of abstraction removed
from the code or feature on theground, what would be the best
way to set the tone withleadership that these are
estimates that are subject tochange, and show the changes and
(11:46):
the impact to timelines andcosts using change management.
Dominik Maximini (11:52):
All right, the first step actually would be to
get a dictionary to managementand show them the difference
between estimate and fact,because in many cases,
management treats estimates aspromises as facts. But that's
not what we are here for. Andwhat I usually do when I'm in
(12:13):
such an environment is I askmanagement, how many projects
have you done within the lastlet's say two years, three
years, five years, some timespan. That's common for them.
And then they name some randomnumber, maybe 30, maybe 50,
maybe 100 and then I asked themhow many of them were in time,
(12:35):
in scope, in budget. And usuallythe answer is none of them, or
only a very small percentage ofthem. And then I go on with
explaining to them. The reasonfor that is that we are in the
complex domain. Many thingschange. So if in the past we
couldn't hit the dates, why doyou think we will hit them this
(12:58):
time? And usually the end ofthat conversation is that
management says, well, they needsome sort of number, date,
whatever, so they have somethingto manage. And the art of change
management, and I'm not talkingabout requirements change, I'm
(13:18):
talking about organizationalchange. The art of change
management now is to shift theconversation away from managing
dates towards managing value. Sowhat is value for the company,
what is value for the user, forthe customer, and how can we
maximize value? And how can wedo that early? And if you are
(13:43):
successful there, you will havea very good relationship with
management, because you arestriving to achieve the same
goal, maximize value for thecompany. So give them something
to manage, which is value, butget away break apart from the
time aspect. It's just anindicator that's not very
(14:07):
valuable.
Lindsay Velecina (14:09):
Okay, thank you. I hope that helps. Several
of you who are here on the livesession are putting your
questions in the chat. If youcould please move them over to
the Q A that would be reallyhelpful so that we can manage
the questions better. So thankyou for that. This question
here, so how do we createrealistic forehead forecasts
(14:31):
when priorities change daily?
Dominik Maximini (14:36):
Good question.
Yeah. The quick answer would be,you can't, because obviously you
can only project something youknow that doesn't change. If
your team changes, if yourrequirements change, if the
world around you changes,obviously whatever you estimated
before will not be met. So Iwould shift away from a. How can
(14:57):
we hit the date if everythingchanges towards how can we
organize ourselves around allthat change and organizing
around it means, first of all,do we have to change? And
obviously, if we realize thatour assumptions were incorrect,
(15:17):
the world is turning around,whatever, of course, then we
have to change direction, andthat also changed the estimate
and our forecast. But sometimeswe realize, actually we don't
have to change. The only onechanging is the CEO every time
he visits a trade fair or readsa new book, and if we have that,
(15:40):
then, as a product owner, Iwould focus on making
transparent. What are ourpersonas? Who are our users,
what is value for the users? AndI would try to get into a
conversation that goes along thelines of, Hey, dear CEO, you're
coming around with new ideasnow, for which stakeholder group
(16:03):
is that relevant? Which value ofthat stakeholder group does it
help? And what other value willwe not be able to achieve if you
follow yours? Because usuallythese people don't, don't
recall, don't don't realize thattheir new wishes have costs with
(16:23):
the old wishes. They alwaysbelieve they can have it all,
and that's not going to happen.
That's the sort of conversationI would try to get them into.
Lindsay Velecina (16:38):
Okay, thank you. Right next one here. What
are the best practices forforecasting and release planning
of topics that haveinterdependencies to other
teams, meaning there are otherteams. Input is a prerequisite
to move on. All right? The otherteam, I assume might have been a
(17:01):
typo, meaning the other team'sinput is a prerequisite to move
on.
Dominik Maximini (17:05):
Yep, got it.
First of all, the question wasfor best practices. Best always
assumes there is nothing better,and it works everywhere. And
since we are in the complexdomain, there is nothing such as
a best practice. Every contextis different. So I would rather
go into something like goodpractices, or with one company,
(17:26):
we called it our current bestapproach, our CBA. And the
second thing is, if I put on mymy scrum cap. So if you're just
listening to it, I'm justputting on a cap that says dogma
cap. We have to understand thatif we are doing pure Scrum,
vanilla Scrum, then we have tohave a cross functional team,
(17:51):
and that means no dependenciesoutside, outside the team. But
then again, I realize that notevery context has the ability to
do that for whatever reasons. Soif we are really dependent on
somebody, we will have to workwith them very, very closely. We
(18:13):
will have to estimate together.
We will have to come up with ajoint roadmap, so not having
roadmap a and roadmap B, andthen hope that it fits somehow.
No, we need to have a jointroadmap, and we need to
visualize dependencies on thatroadmap. Usually we do it with
(18:35):
some straws or tape or whatever.
So we see product backlog item4711, maps to product backlog
item 8080, or something, andthen we see the dependency and
the people responsible for thoseteams. Hopefully it's a single
product owner, but very often itisn't. Very often, it's two
(18:58):
product owners. They have towork together. Now, in the long
term, if you're getting moreagile, you will most likely
figure out that you are betteroff if you actually create new
teams, make them truly crossfunctional, of course, only if
you have recurring dependencies,if it happens once in a while,
(19:20):
nobody cares. But if you haverecurrent dependencies, you're
always dependent on the otherteam, then think about
recreating the teams so they aretruly cross functional.
Lindsay Velecina (19:34):
Awesome. Thank you. I hope that helps. All
right, so here's a questionhere, how can a new team
forecast being a new team? Theywon't have any empirical
velocity performance data, sothey cannot use Monte Carlo
simulation, et cetera. Yes.
Dominik Maximini (19:55):
Well, obviously they can't, no matter
if. You're doing Scrum, or ifyou're doing waterfall or
whatever, if you haveinexperienced people in that
topic, inexperienced people,whatever they estimate, will
just be plainly wrong. And ithas always been like that, and
(20:16):
it will always be like that. Nowthe difference is, how do you
deal with that? And if we are ina complex environment, and if we
are doing Scrum, then we willrevisit the estimate over and
over again. So for example, letthem do an estimate, then work
for three months, then reestimate it, and you will see
the difference. And coming froma practical point of view, what
(20:40):
I usually do with my new teams?
Imagine completely new team.
They have never met before, newtopic. Of course, they are firm
in the technology, but they havenever applied it on the problem.
So technology is always kind ofnew. I usually use them for a
week, and we work with definingwho's the customer, what is
(21:04):
value for them, what's thevision? Of course, most of it is
prepared. But then with thedevelopers together, we forge it
a little bit, and once theyunderstood it, then we look at
the product backlog on a veryhigh level. So in many teams,
that's called epics. So we lookat that, and then the key comes.
(21:27):
I walk over to the team and tellevery single person in the team
to give me three estimates. Theyhave to write it down on paper,
hiding it from each other sothey don't see what the others
are writing. And I ask themwrite down a date. So really a
date in the calendar? Yeah,write down a date. What's the
best case you believe we canfinish this? Second, what's the
(21:51):
worst case you believe we willbe done? And third, what do you
really believe when will we bedone? And then we have three
points estimated by everybody.
We turn it over, we make ittransparent. At the same time,
we put it on the wall, and thenI see two different things. The
first is, how close or how farapart are the clusters inside?
(22:15):
So with every developerestimating a worst case. How far
away are the worst cases? Howfar away are the best cases? And
the second thing I see is, howfar away is the average estimate
of the best case, the worst caseand the average case? And that
gives me some idea of how goodthe estimates are. Obviously the
(22:39):
further apart they are, the thehigher the uncertainty and the
worse the outcome will be. Butquite often, I have the case
that estimates are closetogether, and we actually hit
them more or less because of thetime we spend together during
that week to get familiar withthe matter. So that is something
(23:01):
I can recommend. But again, whatI said in the beginning, do it
again. So use two or three hoursto do that first estimate, but
after a couple of months, aftera couple of sprints, and I
usually say three to foursprints at least, then re
estimate it, and that estimatewill be better.
Lindsay Velecina (23:26):
Okay, thank you. All right. I hope that
helps. So next one here. We'rejust moving right along. Lots of
questions keep them coming. Sowhat is your this kind of ties
into that a little bit. What isyour experience using Monte
Carlo simulation forforecasting, and what are the
(23:47):
crucial things to consider whenimplementing it?
Dominik Maximini (23:52):
All right, Monte Carlo simulation. There
are people out there who loveMonte Carlo simulation. There
are people out there who hateMonte Carlo simulation? I'm in
neither camp. I tried it out acouple of times. My personal
opinion on that is that it canbe a very helpful tool if you
(24:16):
have some sort of stability. Sothe team is always estimating
correctly or incorrectly by thesame amount, but very often you
don't have that. Very oftenalso, the sizes of the stuff
you're doing is very far apart.
Very often during a project,you're changing direction, and
(24:40):
everything is different now. Andwhat I experienced as the
biggest problem is that MonteCarlo simulation gives some
people the idea of certainty,because it's some accepted
model, it's some sort ofcalculation. And I. Put numbers
into a system, and the systemtells me another number, and
(25:02):
then I believe that number, andthis false sense of being right
is something I then have tofight as a product owner. So
honestly, I have used it acouple of years ago, but I no
longer use it. I try to usemethods that convey by the very
method that it's uncertain, andit's a big difference if I tell
(25:26):
management, we estimated this asa t shirt size M, or we
estimated it as a stegosaurus ora yellow gummy bear, rather than
going there and telling them, weput all the numbers into Monte
Carlo simulation, that tells uswe will be done by June. Now,
more or less, of course, I'mexaggerating. I just want to
(25:50):
highlight the the risks of that.
Okay,
Lindsay Velecina (25:59):
thank you. All right, so this one here, it
seems like a burn down chartonly works for a set scope of
work, such as implementing aspecific large feature. Is that
correct? We are adding newfeatures, running our platform
and fixing bugs. Does thatchange anything about the
(26:22):
estimation and burn down chartsand delivery dates?
Dominik Maximini (26:28):
Good question.
First of all, you use a burndownchart to come up with some sort
of forecast. You can onlyforecast something where you
know the scope. Yeah, if youdon't know the scope, you can
never say when you will befinished, obviously. Now, if you
are in an environment where partof your work is development
(26:49):
work, let's say having featuresyou want to implement, or
something like that, and theother part is some recurring
work that you cannot estimatebeforehand, for example, fixing
bugs or having to do maintenancestuff, or some teams even have
to be on the support hotline anddo support calls. Then obviously
(27:11):
you cannot put that into theburndown. However, what you can
do is you can reserve some timefor that. So for example, you
might know that 30% of your timeis used bug fixing or something
like that. And if you know that,then you can create placeholders
(27:35):
for that in your backlog. Now,if you are more in a rebel mood
today, what you could then do isjust ignore it, because it will
reflect in velocity. If onlywhat you manage to develop in
features in the complex world iscounted towards velocity, then
(27:58):
velocity will be smaller,because obviously the chunk
where you did the support partis not in there, and then it
evens out, and your burn down iscorrect again, because bugs are
not in velocity and they are notin scope. But most people I know
try to work with some sort ofplaceholders. So
Lindsay Velecina (28:20):
okay, thank you. Lindsay,
Dominik Maximini (28:25):
if you think I didn't explain something good
enough, please let me know.
Okay, yeah, so
Lindsay Velecina (28:31):
for me, that was good enough. But audience,
if you would like to dig furtherin on any of the answers that
come in, please, please do anyfollow ups in the chat so that I
can utilize those. Okay, right?
So this next question here, inthe case of multiple teams being
(28:57):
involved in a project using asingle backlog to drive
progress. The challenge withstory point sizing is every team
sizes stories differently. Whatare the your recommendations on
aligning sizing so that we canactually convert the estimates
to dates in a way that works forall teams?
Dominik Maximini (29:22):
Yeah, yes, yeah. First of all, whoever
asked that question,congratulations, you have one
backlog for many teams that'salready a big leap ahead. So
congratulations. About theestimation, I would not try to
normalize velocities in any way.
You, of course, can do that, butthat would mean all teams
(29:44):
develop the same stories over aperiod of time, and you already
know in advance that this is acomplete waste of time. So you
don't do that. What you doinstead, in practice, is you.
Draw up some sort of roadmap. Soimagine a big wall in front of
you. You have lanes under eachother, and each lane is one
(30:08):
team, and you have partitionedthese lanes into sprints. And it
can be that sprints have thesame length, which I would
actually recommend if they areworking from the same backlog,
but it can also work if theyhave different sprint lengths,
and you would see that on thewall. So for example, on the
(30:28):
very top, you have first the themonths and weeks, and below
that, you see the sprints, andyou see which weeks are covered
by which sprints. And then havelanes for every team, and no
matter by what system teamsestimate, after they did their
estimate, they should be able toplace product backlog items in
their lane, in the respectivesprints, and that is all you
(30:53):
need. So no matter if one teamestimates in story points, and
another one in T shirt sizes,and the third one doesn't
estimate at all. They just dogut feeling or whatever. You
still can organize every singleteam in that roadmap, and since
it's a joint roadmap, you canalso highlight the dependencies,
(31:16):
if there are some and you can,or you basically have normalized
your estimate in the form ofthat giant roadmap. And I've
done that numerous times, and itworks pretty well. Let me show
you a picture, and let me searchfor it a minute so you see it in
(31:37):
a great context. Yeah, here wego. I'll share my screen in a
minute. So if you're justlistening to it, I'll try to
describe what's on the picture.
In that context, we had 36 teamsworking from the same product
(32:01):
backlog. On this picture, yousee a wall, and on that wall you
see 18 of these teams. Thesewere the software teams. And you
see different columns, like,what's the status, what's the
name of the team, who are theteam members, what is missing.
(32:21):
And then you see stories in thecurrent sprint, stories in the
next sprint, and then you seebacklog, so at some point in
time that's further away thanthis sprint and the next sprint,
and that environment was souncertain that we didn't know
what happens ahead of twosprints. And what we did here is
(32:44):
that every other day, sobasically, two times a week we
were standing in that room,facing that wall. And when I say
we, it's all product owners. Wehad several product owners and
whoever was interested, and sealevel now, so the full sea level
was there, and then we checkedout. Where's the problem? Where
(33:08):
do we need to collaborate? Wheredo we need to have a decision or
something? And since all productowners and sea level was there,
decisions could be made on thespot. And that's it. And as you
can see on that picture, thereare no estimates visualized on
that board because it was justirrelevant, because we knew what
(33:30):
stories are in which sprint.
Lindsay Velecina (33:35):
Thank you. All right, so we're going to switch
gears a little bit. So someonehad asked, Can you speak more on
release plan? On the releaseplanning portion of the topic,
what are some general approachesto planning a release versus
planning a sprint? And someteams release continuously
throughout a sprint, and somewait a few sprints before having
(33:59):
a release? Yes. Their situation,
Dominik Maximini (34:03):
I would almost say that that goes into the
direction of a terminologyquestion. Um, back in the good
old days, when I was young andmy hair was not gray, at least
here, um, it was more or lessnormal for teams to release only
a couple of times per year. So,for example, two times a year,
(34:24):
or every quarter, or somethinglike that. And from these days
comes the term release planning.
So we knew there is a release inthree months. Oh yeah, we are
doing Scrum. So we are having,for example, two week sprint. We
are nearing the release, so it'ssix sprints per release, stuff
like that. And other frameworksor methodologies like safe are
(34:48):
still using some logic that goesinto that direction. But today,
as the person who asked thequestion is stating correctly,
today. Today, some teams arereleasing multiple times a day.
Of course, then you would notsay release plan, and that is
one reason why the last updateof the scrum guide in 2020
(35:11):
introduced the term of productgoal. And you can imagine that
product goal as some sort ofmilestone that could be a
release, but maybe you have 20releases leading up to that
milestone. And since we want toavoid waterfall terminology, we
(35:33):
don't call it milestone. We callit product goal. But this is the
the way I visualize what peoplecall release planning or
reaching that goal, roadmapping, whatever I have a goal
I want to reach it I have maybeseveral teams, maybe just one,
but maybe several, maybe even30, and they all work towards
(35:57):
that single goal, and now I haveto plan work to get there. And
that's what we just discussedwith, for example, with the
picture or with the descriptionof having the lanes for each
team and having the sprintslined up in the timescale.
That's what we want to achieve.
(36:19):
And the difference totraditional project management
is that change is welcomed. Weknow there will be change. We
are in a complex domain, forGod's sake, so there will be
change, and we will manage it asit comes up. While in the
traditional world, change wasalways something evil, something
(36:40):
nasty. You didn't want to have
Lindsay Velecina (36:43):
it. Does that help? Change is always hard,
though
Unknown (36:47):
that's of course it is.
Lindsay Velecina (36:49):
All right.
Thank you. All right. So my teamis fairly new to Agile. Most of
the time we end up extending oursprint. There are stories that
get blocked on a system. Issue,is this a good practice? What?
What can we do differently tohave a release every two weeks?
Every two weeks? All
Dominik Maximini (37:13):
right, first of all, usually you do not
extend sprints. A sprint is atime box. So after the time box
expires, you go back to sprintreview, Sprint Retrospective.
You do a new sprint planning, nomatter if you completed
(37:33):
everything you planned for nomatter if you completed anything
at all, even if you deliverednothing, you still do a review.
You'd still do a retro and youstill do a sprint planning. The
reason being, you want to learn.
And imagine if you always extendyour sprints, you have busy
stakeholders that blocked someportion of their calendars to
(37:56):
come to your sprint review. Ifyou now extend the sprint, they
have to reschedule everythingthat won't be possible, they
will hate you and they will notcome again to your sprint
reviews. So you try to stickwith the consistency. And the
next step actually should be toremove the underlying
(38:17):
impediments that prevent youfrom delivering at all. So if
you have system issues thatprevent you of delivering, for
example, failing test, test datathat's not consistent, some sort
of system that's down, systemsthat are owned by a different
(38:37):
team you don't have access to orstuff like that. These are
traditional impediments. Grabyour scrum master, let them
solve it. You will not be ableto work in any agile way if you
have these dependencies. So fixthem, and afterwards, life will
be all flowers, fluffy, rainbowsand unicorns, and you can
(38:59):
finally have more fun actuallydelivering and working. And then
it's not so important. If youjust release a small user story
or a big feature or something,having the consistency of
delivering over and over againthat creates motivation,
especially for the developers,
Lindsay Velecina (39:21):
right? Thank you. All right, I hope that
helps. So next one here, anyadvice on estimating key results
for a quarterly OKR, typicallyScrum teams might have only two
sprints worth of refined andsized ready backlog. All right,
so
Dominik Maximini (39:40):
we have a situation where the company is
using OKRs and using Scrum atthe same time, which is fine, it
can work. One word of warning,though, most companies I have
seen so far that claim to bedoing OKRs are actually doing
MBO management by objective. Sotop down objectives that are
(40:02):
poured from the top down intothe teams and then telling them,
now you can be agile as much asyou want, as long as you deliver
everything I told you to. Andthat is not how OKRs work, and
it's not how Scrum works. Nowbeing constructive, what I
(40:23):
usually do with OKRs is I takethe key results, I let the team
estimate only, does it fit intoa single sprint, or does it fit
into a let's call it release, orinto a bigger scale, and if they
say it fits into a sprint, thenit can actually be a quite nice
(40:44):
sprint goal. So we can use it asa sprint goal, and if it's
bigger than a sprint, then wecan use it as a product goal.
And that works fine. Justremember, always focus on the
single goal. Do not try tofulfill seven key results at the
same time that does not work.
Focus on a single goal andalways remember, if it's
(41:06):
impossible, well then it'simpossible. So just somebody
wishing for 20 stories in asingle sprint does not make this
happen.
Lindsay Velecina (41:20):
That's great.
Thank you. So what are somefactors that we should consider
to predict estimated releasedates, a ballpark for the
stakeholders? What data from ADOor JIRA can I use to come up
with that? Somebody asked, allright, I asked.
Dominik Maximini (41:43):
All right, I will explain it independent from
the Gyra question, because afool with a tool is still a
fool, and many people rely onsome sort of digital tooling and
defy common sense. And I and theeasiest way to project I always
(42:05):
do it when I enter a team forthe first time or a company for
the first time. The easiestthing you can do is count. So
count the number of, let's callit issues in the gyro language,
or it could be user stories orproduct backlog, item, whatever
you name it, count them persprint. How many were planned,
(42:31):
how many were finished? And byfinished, I mean really, really
done. Not sort of, yeah, we arealmost done, but the testing is
missing or something, yeah,really done, and just count, and
that usually gives you moretransparency than if you run
some fancy reports in some tool.
And what I do then is I use thenumber given, for example, I
(42:56):
could come up with just bycounting. And I fully know that
some things are big and some aresmall. I'm just counting like a
stupid idiot, yeah. And forexample, I could come up with a
number of 40% saying, okay, theyplanned 100 things and they
delivered 40 over a span oftime, 40% now they are planning
the next big thing, for example,a quarter or half a year,
(43:23):
whatever I will tell them, thedevelopers, hey, with the
numbers of the past, I don'tbelieve you. You said you will
now deliver 200 things with thenumbers from the past. I think
you are only going to deliver80. 40% of 200 is 80. And that
gets the conversation going, andvery often it goes into the
(43:46):
direction of Yes, you are right.
We don't believe in thesenumbers anyway, but we fear that
if we raise the real numbers,management will be all over the
place, and we won't be able towork, because we will have to
jump from one task force meetingto the next, and that, again,
gives you some leverage to dealwith management. Now, with
(44:08):
regards to what to consider forthe estimate, it's usually the
amount of uncertainty. So howuncertain are the requirements?
Have we worked with the customerbefore? Have we worked with that
type of product before?
Technology? Have we worked withthat programming language
before? Have we worked with allthe frameworks before? Do we
(44:30):
know technology? How many in ourteam are seniors and how many
are juniors? And is that a goodthing or a bad thing, because
sometimes the juniors are fasterthan seniors, but sometimes it's
the other way around. So I needto develop a feeling there and
then the team itself. Do theyalready know each other? Is
(44:51):
everything new to them? Havethey never met? Are they
dispersed over many differentlocations? Have. They never met
in person. Are they fromdifferent cultural backgrounds,
or are they coming from the samecultural background? Stuff like
that. These are things I wouldconsider, and what I often do,
because I'm the outsider, Idon't have all that information.
(45:15):
What I usually do is I walk upto the stakeholders separately,
and I walk up to the developersseparately, and I ask them in
those three dimensions, sorequirements, technology and
people, and ask them, how big isuncertainty there? What do you
think? And then I get datapoints from everybody. And with
(45:36):
these data points, I get a firstidea of how uncertain that is.
And with that uncertainty, Iusually make that uncertainty
transparent to management when Ipresent the numbers. So I have
counted the past. I have somesort of project archeology where
I dug out the old data, and Ican tell them, hey, you had so
(46:01):
many projects, they were, onaverage, so much later than you
believed. I have the individualdata points from developers and
from stakeholders, and then Icompare them, and what very
often happens is that they arein the same ballpark. So the
other projects where, forexample, 50% late. My team in
(46:23):
the past was 40% late. The dataestimates from individuals might
show they are 55% late. And thisis so close together that I
would walk up to management andsay, Hey, we have an estimate,
but I would assume that we willbe 50% later. So here's my real
estimate. Go for it. Okay, andlet me finish that. Sure, the
(46:49):
more data you have, real lifedata, with the correct product,
the right technology, the rightpeople, the more data you have,
the more precise your forecastwill be, but it will never be
100% precise.
Lindsay Velecina (47:10):
Okay, thank you. All right, so we are trying
to get to as many of thesequestions as possible. Your
answers have been really, reallythorough and really great
Dominic. So thank you. Sowhichever questions we do not
(47:30):
get to, I will be sharing themall with Dominic after the
session. We'll figure out a wayto address them. So don't worry,
we're going as quickly as we canthrough these, but we also want
to give good answers. So this isa bit of a big question, but I
think it's something that peoplecould relate to, so I'm probably
(47:52):
going to paste it into the chatfor everyone if it lets me do
Yes, all right, and I will readit as well. So one of the most
common challenges we have withforecasting is that some
(48:15):
percentage of the team almostalways ends up supporting the
previous batch of work past thestart date of the next chunk of
work. This isn't reflected inthe velocity as misses for from
the previous release get addedin as tracked work, but less of
(48:37):
that velocity is actually beingapplied to the work that
management seed has started andis expecting us to deliver based
on the previous estimates, anyadvice for managing expectations
preventing this or Getting aclear picture of the impact
(48:58):
earlier on I Uh huh.
Dominik Maximini (49:03):
Now I'm not 100% sure that I understood it
correctly, so I will try torephrase it in in simple terms.
We have a team working on somestuff. They are not really,
really done, because when theywork on the next sprint or the
next release, doesn't matter. Sothey they continue with
something else. Then unfinishedwork from the past pops up. They
(49:27):
have to work on that. And that,of course, really reduces
velocity for the new stuff. Andthen management comes around the
corner and says, You're tooslow. You have to be quicker.
That's what I understood. There.
Would you agree there? Lindsay,yes,
Lindsay Velecina (49:41):
I would agree.
All right, good advice there.
Dominik Maximini (49:45):
Good so if we did not understand it correctly,
I'm sorry just to try to diveinto that.
Lindsay Velecina (49:53):
Yeah, and you can always follow up with
Dominic after the session aswell.
Dominik Maximini (49:58):
Of course.
Yeah. Okay, now, what should youdo? The first thing is you have
to address the underlying issuesfor the undone work popping up
again. If you follow Scrum, thenyou would only deliver done
pieces of work. So done productincrements and done means
(50:20):
there's no work remaining, forexample, tests or whatever. Now
if there is work remaining, oneavenue of approach is that you
tighten your definition of doneso you improve quality. And if
you're successful there, theamount of work spilling over
into the next Sprint will willbecome less and less until it
(50:44):
trickles out and is virtuallyzero. The next thing is only
count velocity for things thatare really, really, really done.
So if you have some chunk ofwork and you're like, 98% done.
It's just those two tests thatare still missing. Then in scrum
(51:05):
logic, it's not done. And notdone means zero in velocity. And
then formally, it goes back tothe product backlog. The product
backlog is ordered by theproduct owner, so the product
owner can decide if it should bein the next sprint again. But I
mean, honestly, usually theproduct owner still thinks it's
(51:28):
important, and if it's 98% done,of course, he wants to get the
rest so. But the formal way isthrough the product backlog, and
if it's then done in the sprint,and really, really done and
finished and delivered. Then youearn the velocity points, and
that also helps you withmanagement, because management
(51:49):
understands that velocity isconsistent over time, and you
deliver over time consistently,but you don't deliver garbage.
And many, many managers, not allof them, but many of them, think
it's more important to bereliable than to be fast. So if
you have a reliable output inhigh quality, that's usually
(52:15):
higher valued than beingunreliable in quality and speed,
so they have something again tomeasure and to manage. Let me
think what else could behelpful.
Lindsay Velecina (52:35):
We did get feedback from David that you
understood it perfectly.
Situation. Good
Dominik Maximini (52:41):
luck today.
Yeah, yeah, right. So, David, ifyou're in the chat anyway, um,
does that answer your question?
Just yes or no?
Lindsay Velecina (52:55):
Yes, perfect.
It does. So
Unknown (52:57):
bring it on. Lindsay, next month.
Lindsay Velecina (52:59):
All right, so we have time for a couple more,
I think. So how do you deal withaligning the definition of Done
and forecasting implications,
Dominik Maximini (53:10):
aligning DOD?
Do you mean align? Well, I'm notsure if you can answer that, but
align with the forecast oraligning with another team
Lindsay Velecina (53:22):
I'm thinking aligning with the forecast. All
right? Says, How do you dealwith the aligning definition of
Done and forecastingimplications?
Dominik Maximini (53:33):
All right, from my point of view, that's a
pretty simple question, becauseyou only deliver what fulfills
the definition of done. I mean,the scrum guide reads, as soon
as a product backlog, itemreaches the definition of Done
and increment is born. So that'slyric. What that means is that
(54:01):
every forecast you do includesfulfilling the definition of
done in its entirety foreverything you do. So whatever
forecast you come up withalready includes the full
definition of Done. Now it's alittle bit different if you
tighten the definition of donewhile you work. But then again,
(54:24):
my experience is usually itdoesn't make that a big
difference, because the time younow spend in doing quality work
you spend earlier in fixingboxes. And it really doesn't
matter if you now fix a bug orif you do it right in the first
place. On the contrary, usuallyfixing the bug takes longer than
(54:47):
doing it right in the firstplace, because you have built
stuff on top of that bug, andyou have to work through that
complexity again.
Lindsay Velecina (54:57):
Okay. Do.
Thank you. All right, so, sosomeone asked this question, so
they said, You already mentionedrapidly. But can you please
explain this further? Is Scrumand fixed time boxes still
relevant or not in a DevOps CICDcontext, what is the best work
(55:21):
method to use when delivery issupposed to be continuous?
Dominik Maximini (55:29):
Well, again, I'm not sure what the best way
to work is, right? Lindsay,please pluck your ears for a
minute, because, in reality,even though I'm here as a scrum
trainer. I don't just use Scrumdepending on the context. I also
use Kanban elements, orAbsolutely,
Lindsay Velecina (55:48):
you shouldn't tell me to cover my ears for
that.
Unknown (55:51):
Well, I don't know scrum.org.
Lindsay Velecina (55:54):
We are all about, you know, complimentary
practices and using what worksbest for your team. So
Dominik Maximini (56:01):
there have been instances where it didn't
you scrum at all shocking. Iknow
Lindsay Velecina (56:06):
it happens
Dominik Maximini (56:09):
anyway. Yeah, if we are in such a situation
and somebody is walking up to meand saying, Hey, we work with
continuous development,continuous integration,
continuous deployment. I say,congratulations. That's what we
do in our days. That's today'sway to work, perfect. Now these
(56:31):
arguments usually come from theperspective of the developers,
and from the developersperspective, they are totally
right. Now you also have toconsider the perspective of the
user, the perspective of thestakeholders. For example, your
marketing department and yourmarketing department doesn't
like daily new releases. Whatthey like is being able to tell
(56:57):
to the customer, hey, here'ssomething big coming up. Now you
still can deliver that big chunkof work with small, incremental
releases. That's exactly what wewant to do, but you have to
allow other people, be it yourstakeholders or your users, to
absorb that. And in many cases,the way to absorb it and the way
(57:18):
to communicate it is some sortof roadmap. So even though you
deliver continuously, you mighteven deliver it continuously to
the end user. Still, thecommunication and the management
from your internal stakeholderswill be in some sort of time
chunks. And these time chunkscould be product goals, sprint
(57:38):
goals, releases, so formalreleases that include some sort
of release notes and maybe abottle of champagne for the
customer, even though, on thetechnical side, it was done in
incremental daily releases,
Lindsay Velecina (57:55):
right? Thank you. All right, so we don't
really have time for any morequestions, but I will share we
have 25 remaining questions. Wehad a lot come in, so I will
share those with you after thesession. Are there any pieces of
advice that you want to leavethe audience with? Dominic, this
was a really big topic. Youcovered a lot. Got some great
(58:17):
feedback from the audiencealready. But what are Is there,
like a specific piece of adviceyou want to leave people with
when they're thinking aboutforecasting and release
planning? Yeah,
Dominik Maximini (58:31):
maybe two pieces. The first is, use common
sense. Please don't get hookedup to some method no matter
which one and believe thatmethod will solve all your
problems, use your brain cells,use common sense, and the second
one is always try in adiscussion with whoever. Try to
(58:55):
walk in their shoes, try tounderstand what their need is.
So management is not evil orsomething. They just have
different needs than you mighthave, or other than the
developers might have. And ifyou are successful in walking in
their shoes for a mile, then itwill be far easier for for you
to have the meaningfulconversations with people. So
(59:19):
use common sense and try to viewmatters from their point of
view. Please,
Lindsay Velecina (59:26):
okay that that makes perfect common sense. So
thank you everyone. So much forattending. Like I said, we'll
figure out a way to address theopen questions and Dominic,
thank you so much for yourwisdom and for being here. It's
been really great.
Dominik Maximini (59:47):
It's my pleasure.
Lindsay Velecina (59:48):
Thank you so thank you everybody and Scrum on
and have a great rest of yourday. Take care. Bye, bye. You.
Steve, 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
series where a live audienceasks questions of professional
(00:26):
scrum trainers. We hope youenjoy this episode. Hello,
everyone. Good morning, goodafternoon, good evening,
wherever you're located today,welcome to today's Ask a
professional scrum trainer forthose who are here on the live
session, welcome and those whoare tuning in on the scrum.org
community podcast, welcome. Wehave with us today. Pst, Dominic
(00:51):
Moxa Mini, and he is here toanswer your questions about
forecasting and releaseplanning. So I'm expecting this
to be a very interactive sessionwith lots of questions.
Something that I forgot to do isintroduce myself. I'm Lindsay
here@scrum.org and I will behosting our session today. So
very quickly, about scrum.org sowe are the home of Scrum. We
(01:15):
were founded by Ken Schwaberback in 2009 and our mission is
to help people and teams solvecomplex problems, and we do so
through our training,certification and ongoing
learning. We have a lot of freeongoing learning on our website.
I'm assuming that you all arefamiliar with that, so please
check that out, and I hope thattoday's session plays an
(01:38):
important role in your learningjourney as well. So with all of
that, I'd like to hand it overto Dominic so that he can
introduce himself and then wecan start diving into questions.
Welcome Dominic.
Dominik Maximini (01:52):
Thank you very much. Lindsay, well, I won't
introduce myself for a very longtime because we want to jump
into questions quickly. Just anote, I've been working now in
different scrum roles for morethan 18 years, so I'm coming
here with lots of experience,and hope to share some of that.
(02:12):
I also have been a PST since2011 so I've trained a couple of
classes since that, since then,and my personal goal is to help
people come to work with a smileon their faces, and I hope that
with all the participants today,we will get one or two of them
(02:32):
smiling when they go to worktomorrow.
Lindsay Velecina (02:36):
Awesome.
That's a good goal. All right,so thank you, Dominic. All
right. So you can start enteringyour questions. I'm going to
stop the share here see what wegot. So you could, like I
mentioned before, please utilizethe Q and A button at the bottom
to enter your questions. We canutilize the chat then for any
(02:58):
technical issues. So let me justflip a few settings here. So I
have a question here. Dominic,so why estimate at all if we
work in a complex environmentwith high levels of uncertainty?
Dominik Maximini (03:15):
That's a very, very interesting question.
Imagine you want something fromsomebody, be it something simple
like a new kitchen, or somethinga little bit more complicated,
like new house, or evensomething bigger. One of your
first question will be, how muchdoes it cost, and when will I
(03:38):
have it? And the difference inthe complex environment is that
estimates will change over time,because requirements change and
things happen. You know, lifehappens and stuff, and still,
your stakeholders and yourcustomers will want some sort of
answer, and also you want toknow if you are still on track
(04:02):
or not. So you need some sort ofplan, and you need some sort of
idea when you want to be rare soyou know if you hit your target
or not, and the way to get thereis estimation.
Lindsay Velecina (04:16):
Awesome. Thank you. Do you want to maybe, like,
help set the stage for just whyyou proposed this topic, and
what you've been seeing otherteams do to kind of help spark
some questions from theaudience. Yeah, sure.
Dominik Maximini (04:35):
Probably everybody in the audience is
part of some sort of more orless agile teams. They might be
SCRUM masters, they might bedevelopers, they might be
product owners or somethingentirely different. And all of
them, no matter in what role,will have some sort of
management in their company. Andthe number one top question of
(04:57):
management is always. When willI get it? When will it be done?
And that's true in my project aswell. So very, very often that
question is posed by some sortof management, and they need,
obviously, to know when theirbudget will be running out and
(05:20):
what they can promise theircustomers, and to get into the
interaction with management, youneed to speak the language of
management, and that language ofmanagement is pretty much
estimation. That's why I broughtit here, because it's entirely
possible to estimate and to doit in a simple way and not be
(05:41):
nailed down with a single day onthe calendar wall or something,
and there are ways to do it. Soif you have questions about
that, feel free.
Lindsay Velecina (05:53):
Awesome. Thank you. All right. So question here
that came in, if I have manyteams that make up a release, I
can see the estimates for myfeatures for the release. I know
how much time we have left, buthow do I know it's on track
using a chart? I don't know thatburn down, burn up gives the
(06:13):
full picture,
Dominik Maximini (06:16):
because of the many teams, right?
Lindsay Velecina (06:19):
Seems that way. Yeah,
Dominik Maximini (06:22):
all right. I'm not sure if everybody in this
call is aware of the burndowns.
So let me introduce burndownsfirst. There are different,
let's say tastes, differentflavors of burn down charts out
there. What they all have incommon is that on the x axis
they have plotted time and for aproduct owner or a project
(06:48):
manager or something, that'susually the sprints we have
there, and every burndown charton the y axis has the work
remaining plotted. And let megive you a short example. I'll
share my screen. I kind ofanticipated some sort of
(07:09):
question like that. What you seehere, if you are on the video
call, is a professional BurndownChart, like you would use it in
project. And it actually is froma real project of myself. It was
done in 2015 2016 so quite awhile ago, I'm getting old, by
the way. And what you see hereis, on the very top, there is a
(07:34):
200 that was the estimate forthe project scope. So in this
specific context, the boardsaid, Hey, if you want to do the
project, you have to estimateall of it, so like in a
traditional waterfallenvironment, so we estimated all
of it with story points.
(07:55):
Actually, we didn't have a clue,because it was a new team, new
technology, new product, butstill, we estimated it and get
did our best. And what you thensee here in the column that says
real velocity is we slightlyincreased it. So in the first
sprint, we got a one, then atwo, then a six, then an eight,
then a 10. And now take a noteof the burn down you see in the
(08:21):
chart right now, it's just oneline because we don't have many
data points. So if I put, forexample, a 12 in here, what you
see now is that we have a coneopening up at the bottom. So on
the upper part of the burn down,we see just one line. That's the
past. It already happened, so wedon't have to discuss it here or
(08:46):
or argue or anything ithappened. Yeah, that's reality.
And from that point on, we havean extrapolation for a best
case, a worst case and anaverage case. And you see that
it touches down between Sprint23 and 27 somewhere around that
time. And you also see twovertical lines. These represent
(09:09):
the colored dates on the verytop. These were the prescribed
release dates. And yes, we didhave to release on the 25th of
December. And yes, that wasChristmas. And no, the board was
not there when we did therelease so, but what you easily
see here is, at what height dowe cross the vertical lines? So
(09:35):
at the release date, will wehave everything? Well, in best
case, yes, but in average case,no on inverse Case No. And if we
add more data to it, let's saywe have a slow sprint. Let's say
we only achieve six that sprint.
Then you see the cone opening upgets wider. And when I talk
about estimation and. And doingsome sort of release plan. This
(10:00):
is what I'm talking about. I'musually not giving a single
date. I'm giving a cone. I'mgiving a range from when to end.
And what I usually also do is Itell management, okay, if you
want to increase the likelihoodof hitting the good date. Here's
my list of impediments you canhelp me fix, and that gets some
(10:23):
fruitful conversations going.
Now, with regards to many teams,let's say we have five teams or
20 teams, or something likethat. Obviously every team might
estimate a little bitdifferently, and that's fine. I
mean, you don't want tonormalize velocities. That
(10:43):
doesn't work. It's not costefficient. In that case, you
will have specific burn downcharts for every single team.
But when you try to put them alltogether into one graphics, it
usually will not be a burndownchart. You usually will have
something that's more resemblinga roadmap, or you will have a
(11:05):
quarterly view or something. Andwhenever a single team runs out
of bounds, then you usually putthe whole thing on red, and you
try to fix the underlyingissues. And I'm not talking
about overtime, I'm talkingabout impediments that's keeping
you up at night.
Lindsay Velecina (11:22):
Awesome. Thank you. I hope that helps. All
right, so another question,given that we are getting high
level estimates with multiplelevels of abstraction removed
from the code or feature on theground, what would be the best
way to set the tone withleadership that these are
estimates that are subject tochange, and show the changes and
(11:46):
the impact to timelines andcosts using change management.
Dominik Maximini (11:52):
All right, the first step actually would be to
get a dictionary to managementand show them the difference
between estimate and fact,because in many cases,
management treats estimates aspromises as facts. But that's
not what we are here for. Andwhat I usually do when I'm in
(12:13):
such an environment is I askmanagement, how many projects
have you done within the lastlet's say two years, three
years, five years, some timespan. That's common for them.
And then they name some randomnumber, maybe 30, maybe 50,
maybe 100 and then I asked themhow many of them were in time,
(12:35):
in scope, in budget. And usuallythe answer is none of them, or
only a very small percentage ofthem. And then I go on with
explaining to them. The reasonfor that is that we are in the
complex domain. Many thingschange. So if in the past we
couldn't hit the dates, why doyou think we will hit them this
(12:58):
time? And usually the end ofthat conversation is that
management says, well, they needsome sort of number, date,
whatever, so they have somethingto manage. And the art of change
management, and I'm not talkingabout requirements change, I'm
(13:18):
talking about organizationalchange. The art of change
management now is to shift theconversation away from managing
dates towards managing value. Sowhat is value for the company,
what is value for the user, forthe customer, and how can we
maximize value? And how can wedo that early? And if you are
(13:43):
successful there, you will havea very good relationship with
management, because you arestriving to achieve the same
goal, maximize value for thecompany. So give them something
to manage, which is value, butget away break apart from the
time aspect. It's just anindicator that's not very
(14:07):
valuable.
Lindsay Velecina (14:09):
Okay, thank you. I hope that helps. Several
of you who are here on the livesession are putting your
questions in the chat. If youcould please move them over to
the Q A that would be reallyhelpful so that we can manage
the questions better. So thankyou for that. This question
here, so how do we createrealistic forehead forecasts
(14:31):
when priorities change daily?
Dominik Maximini (14:36):
Good question.
Yeah. The quick answer would be,you can't, because obviously you
can only project something youknow that doesn't change. If
your team changes, if yourrequirements change, if the
world around you changes,obviously whatever you estimated
before will not be met. So Iwould shift away from a. How can
(14:57):
we hit the date if everythingchanges towards how can we
organize ourselves around allthat change and organizing
around it means, first of all,do we have to change? And
obviously, if we realize thatour assumptions were incorrect,
(15:17):
the world is turning around,whatever, of course, then we
have to change direction, andthat also changed the estimate
and our forecast. But sometimeswe realize, actually we don't
have to change. The only onechanging is the CEO every time
he visits a trade fair or readsa new book, and if we have that,
(15:40):
then, as a product owner, Iwould focus on making
transparent. What are ourpersonas? Who are our users,
what is value for the users? AndI would try to get into a
conversation that goes along thelines of, Hey, dear CEO, you're
coming around with new ideasnow, for which stakeholder group
(16:03):
is that relevant? Which value ofthat stakeholder group does it
help? And what other value willwe not be able to achieve if you
follow yours? Because usuallythese people don't, don't
recall, don't don't realize thattheir new wishes have costs with
(16:23):
the old wishes. They alwaysbelieve they can have it all,
and that's not going to happen.
That's the sort of conversationI would try to get them into.
Lindsay Velecina (16:38):
Okay, thank you. Right next one here. What
are the best practices forforecasting and release planning
of topics that haveinterdependencies to other
teams, meaning there are otherteams. Input is a prerequisite
to move on. All right? The otherteam, I assume might have been a
(17:01):
typo, meaning the other team'sinput is a prerequisite to move
on.
Dominik Maximini (17:05):
Yep, got it.
First of all, the question wasfor best practices. Best always
assumes there is nothing better,and it works everywhere. And
since we are in the complexdomain, there is nothing such as
a best practice. Every contextis different. So I would rather
go into something like goodpractices, or with one company,
(17:26):
we called it our current bestapproach, our CBA. And the
second thing is, if I put on mymy scrum cap. So if you're just
listening to it, I'm justputting on a cap that says dogma
cap. We have to understand thatif we are doing pure Scrum,
vanilla Scrum, then we have tohave a cross functional team,
(17:51):
and that means no dependenciesoutside, outside the team. But
then again, I realize that notevery context has the ability to
do that for whatever reasons. Soif we are really dependent on
somebody, we will have to workwith them very, very closely. We
(18:13):
will have to estimate together.
We will have to come up with ajoint roadmap, so not having
roadmap a and roadmap B, andthen hope that it fits somehow.
No, we need to have a jointroadmap, and we need to
visualize dependencies on thatroadmap. Usually we do it with
(18:35):
some straws or tape or whatever.
So we see product backlog item4711, maps to product backlog
item 8080, or something, andthen we see the dependency and
the people responsible for thoseteams. Hopefully it's a single
product owner, but very often itisn't. Very often, it's two
(18:58):
product owners. They have towork together. Now, in the long
term, if you're getting moreagile, you will most likely
figure out that you are betteroff if you actually create new
teams, make them truly crossfunctional, of course, only if
you have recurring dependencies,if it happens once in a while,
(19:20):
nobody cares. But if you haverecurrent dependencies, you're
always dependent on the otherteam, then think about
recreating the teams so they aretruly cross functional.
Lindsay Velecina (19:34):
Awesome. Thank you. I hope that helps. All
right, so here's a questionhere, how can a new team
forecast being a new team? Theywon't have any empirical
velocity performance data, sothey cannot use Monte Carlo
simulation, et cetera. Yes.
Dominik Maximini (19:55):
Well, obviously they can't, no matter
if. You're doing Scrum, or ifyou're doing waterfall or
whatever, if you haveinexperienced people in that
topic, inexperienced people,whatever they estimate, will
just be plainly wrong. And ithas always been like that, and
(20:16):
it will always be like that. Nowthe difference is, how do you
deal with that? And if we are ina complex environment, and if we
are doing Scrum, then we willrevisit the estimate over and
over again. So for example, letthem do an estimate, then work
for three months, then reestimate it, and you will see
the difference. And coming froma practical point of view, what
(20:40):
I usually do with my new teams?
Imagine completely new team.
They have never met before, newtopic. Of course, they are firm
in the technology, but they havenever applied it on the problem.
So technology is always kind ofnew. I usually use them for a
week, and we work with definingwho's the customer, what is
(21:04):
value for them, what's thevision? Of course, most of it is
prepared. But then with thedevelopers together, we forge it
a little bit, and once theyunderstood it, then we look at
the product backlog on a veryhigh level. So in many teams,
that's called epics. So we lookat that, and then the key comes.
(21:27):
I walk over to the team and tellevery single person in the team
to give me three estimates. Theyhave to write it down on paper,
hiding it from each other sothey don't see what the others
are writing. And I ask themwrite down a date. So really a
date in the calendar? Yeah,write down a date. What's the
best case you believe we canfinish this? Second, what's the
(21:51):
worst case you believe we willbe done? And third, what do you
really believe when will we bedone? And then we have three
points estimated by everybody.
We turn it over, we make ittransparent. At the same time,
we put it on the wall, and thenI see two different things. The
first is, how close or how farapart are the clusters inside?
(22:15):
So with every developerestimating a worst case. How far
away are the worst cases? Howfar away are the best cases? And
the second thing I see is, howfar away is the average estimate
of the best case, the worst caseand the average case? And that
gives me some idea of how goodthe estimates are. Obviously the
(22:39):
further apart they are, the thehigher the uncertainty and the
worse the outcome will be. Butquite often, I have the case
that estimates are closetogether, and we actually hit
them more or less because of thetime we spend together during
that week to get familiar withthe matter. So that is something
(23:01):
I can recommend. But again, whatI said in the beginning, do it
again. So use two or three hoursto do that first estimate, but
after a couple of months, aftera couple of sprints, and I
usually say three to foursprints at least, then re
estimate it, and that estimatewill be better.
Lindsay Velecina (23:26):
Okay, thank you. All right. I hope that
helps. So next one here. We'rejust moving right along. Lots of
questions keep them coming. Sowhat is your this kind of ties
into that a little bit. What isyour experience using Monte
Carlo simulation forforecasting, and what are the
(23:47):
crucial things to consider whenimplementing it?
Dominik Maximini (23:52):
All right, Monte Carlo simulation. There
are people out there who loveMonte Carlo simulation. There
are people out there who hateMonte Carlo simulation? I'm in
neither camp. I tried it out acouple of times. My personal
opinion on that is that it canbe a very helpful tool if you
(24:16):
have some sort of stability. Sothe team is always estimating
correctly or incorrectly by thesame amount, but very often you
don't have that. Very oftenalso, the sizes of the stuff
you're doing is very far apart.
Very often during a project,you're changing direction, and
(24:40):
everything is different now. Andwhat I experienced as the
biggest problem is that MonteCarlo simulation gives some
people the idea of certainty,because it's some accepted
model, it's some sort ofcalculation. And I. Put numbers
into a system, and the systemtells me another number, and
(25:02):
then I believe that number, andthis false sense of being right
is something I then have tofight as a product owner. So
honestly, I have used it acouple of years ago, but I no
longer use it. I try to usemethods that convey by the very
method that it's uncertain, andit's a big difference if I tell
(25:26):
management, we estimated this asa t shirt size M, or we
estimated it as a stegosaurus ora yellow gummy bear, rather than
going there and telling them, weput all the numbers into Monte
Carlo simulation, that tells uswe will be done by June. Now,
more or less, of course, I'mexaggerating. I just want to
(25:50):
highlight the the risks of that.
Okay,
Lindsay Velecina (25:59):
thank you. All right, so this one here, it
seems like a burn down chartonly works for a set scope of
work, such as implementing aspecific large feature. Is that
correct? We are adding newfeatures, running our platform
and fixing bugs. Does thatchange anything about the
(26:22):
estimation and burn down chartsand delivery dates?
Dominik Maximini (26:28):
Good question.
First of all, you use a burndownchart to come up with some sort
of forecast. You can onlyforecast something where you
know the scope. Yeah, if youdon't know the scope, you can
never say when you will befinished, obviously. Now, if you
are in an environment where partof your work is development
(26:49):
work, let's say having featuresyou want to implement, or
something like that, and theother part is some recurring
work that you cannot estimatebeforehand, for example, fixing
bugs or having to do maintenancestuff, or some teams even have
to be on the support hotline anddo support calls. Then obviously
(27:11):
you cannot put that into theburndown. However, what you can
do is you can reserve some timefor that. So for example, you
might know that 30% of your timeis used bug fixing or something
like that. And if you know that,then you can create placeholders
(27:35):
for that in your backlog. Now,if you are more in a rebel mood
today, what you could then do isjust ignore it, because it will
reflect in velocity. If onlywhat you manage to develop in
features in the complex world iscounted towards velocity, then
(27:58):
velocity will be smaller,because obviously the chunk
where you did the support partis not in there, and then it
evens out, and your burn down iscorrect again, because bugs are
not in velocity and they are notin scope. But most people I know
try to work with some sort ofplaceholders. So
Lindsay Velecina (28:20):
okay, thank you. Lindsay,
Dominik Maximini (28:25):
if you think I didn't explain something good
enough, please let me know.
Okay, yeah, so
Lindsay Velecina (28:31):
for me, that was good enough. But audience,
if you would like to dig furtherin on any of the answers that
come in, please, please do anyfollow ups in the chat so that I
can utilize those. Okay, right?
So this next question here, inthe case of multiple teams being
(28:57):
involved in a project using asingle backlog to drive
progress. The challenge withstory point sizing is every team
sizes stories differently. Whatare the your recommendations on
aligning sizing so that we canactually convert the estimates
to dates in a way that works forall teams?
Dominik Maximini (29:22):
Yeah, yes, yeah. First of all, whoever
asked that question,congratulations, you have one
backlog for many teams that'salready a big leap ahead. So
congratulations. About theestimation, I would not try to
normalize velocities in any way.
You, of course, can do that, butthat would mean all teams
(29:44):
develop the same stories over aperiod of time, and you already
know in advance that this is acomplete waste of time. So you
don't do that. What you doinstead, in practice, is you.
Draw up some sort of roadmap. Soimagine a big wall in front of
you. You have lanes under eachother, and each lane is one
(30:08):
team, and you have partitionedthese lanes into sprints. And it
can be that sprints have thesame length, which I would
actually recommend if they areworking from the same backlog,
but it can also work if theyhave different sprint lengths,
and you would see that on thewall. So for example, on the
(30:28):
very top, you have first the themonths and weeks, and below
that, you see the sprints, andyou see which weeks are covered
by which sprints. And then havelanes for every team, and no
matter by what system teamsestimate, after they did their
estimate, they should be able toplace product backlog items in
their lane, in the respectivesprints, and that is all you
(30:53):
need. So no matter if one teamestimates in story points, and
another one in T shirt sizes,and the third one doesn't
estimate at all. They just dogut feeling or whatever. You
still can organize every singleteam in that roadmap, and since
it's a joint roadmap, you canalso highlight the dependencies,
(31:16):
if there are some and you can,or you basically have normalized
your estimate in the form ofthat giant roadmap. And I've
done that numerous times, and itworks pretty well. Let me show
you a picture, and let me searchfor it a minute so you see it in
(31:37):
a great context. Yeah, here wego. I'll share my screen in a
minute. So if you're justlistening to it, I'll try to
describe what's on the picture.
In that context, we had 36 teamsworking from the same product
(32:01):
backlog. On this picture, yousee a wall, and on that wall you
see 18 of these teams. Thesewere the software teams. And you
see different columns, like,what's the status, what's the
name of the team, who are theteam members, what is missing.
(32:21):
And then you see stories in thecurrent sprint, stories in the
next sprint, and then you seebacklog, so at some point in
time that's further away thanthis sprint and the next sprint,
and that environment was souncertain that we didn't know
what happens ahead of twosprints. And what we did here is
(32:44):
that every other day, sobasically, two times a week we
were standing in that room,facing that wall. And when I say
we, it's all product owners. Wehad several product owners and
whoever was interested, and sealevel now, so the full sea level
was there, and then we checkedout. Where's the problem? Where
(33:08):
do we need to collaborate? Wheredo we need to have a decision or
something? And since all productowners and sea level was there,
decisions could be made on thespot. And that's it. And as you
can see on that picture, thereare no estimates visualized on
that board because it was justirrelevant, because we knew what
(33:30):
stories are in which sprint.
Lindsay Velecina (33:35):
Thank you. All right, so we're going to switch
gears a little bit. So someonehad asked, Can you speak more on
release plan? On the releaseplanning portion of the topic,
what are some general approachesto planning a release versus
planning a sprint? And someteams release continuously
throughout a sprint, and somewait a few sprints before having
(33:59):
a release? Yes. Their situation,
Dominik Maximini (34:03):
I would almost say that that goes into the
direction of a terminologyquestion. Um, back in the good
old days, when I was young andmy hair was not gray, at least
here, um, it was more or lessnormal for teams to release only
a couple of times per year. So,for example, two times a year,
(34:24):
or every quarter, or somethinglike that. And from these days
comes the term release planning.
So we knew there is a release inthree months. Oh yeah, we are
doing Scrum. So we are having,for example, two week sprint. We
are nearing the release, so it'ssix sprints per release, stuff
like that. And other frameworksor methodologies like safe are
(34:48):
still using some logic that goesinto that direction. But today,
as the person who asked thequestion is stating correctly,
today. Today, some teams arereleasing multiple times a day.
Of course, then you would notsay release plan, and that is
one reason why the last updateof the scrum guide in 2020
(35:11):
introduced the term of productgoal. And you can imagine that
product goal as some sort ofmilestone that could be a
release, but maybe you have 20releases leading up to that
milestone. And since we want toavoid waterfall terminology, we
(35:33):
don't call it milestone. We callit product goal. But this is the
the way I visualize what peoplecall release planning or
reaching that goal, roadmapping, whatever I have a goal
I want to reach it I have maybeseveral teams, maybe just one,
but maybe several, maybe even30, and they all work towards
(35:57):
that single goal, and now I haveto plan work to get there. And
that's what we just discussedwith, for example, with the
picture or with the descriptionof having the lanes for each
team and having the sprintslined up in the timescale.
That's what we want to achieve.
(36:19):
And the difference totraditional project management
is that change is welcomed. Weknow there will be change. We
are in a complex domain, forGod's sake, so there will be
change, and we will manage it asit comes up. While in the
traditional world, change wasalways something evil, something
(36:40):
nasty. You didn't want to have
Lindsay Velecina (36:43):
it. Does that help? Change is always hard,
though
Unknown (36:47):
that's of course it is.
Lindsay Velecina (36:49):
All right.
Thank you. All right. So my teamis fairly new to Agile. Most of
the time we end up extending oursprint. There are stories that
get blocked on a system. Issue,is this a good practice? What?
What can we do differently tohave a release every two weeks?
Every two weeks? All
Dominik Maximini (37:13):
right, first of all, usually you do not
extend sprints. A sprint is atime box. So after the time box
expires, you go back to sprintreview, Sprint Retrospective.
You do a new sprint planning, nomatter if you completed
(37:33):
everything you planned for nomatter if you completed anything
at all, even if you deliverednothing, you still do a review.
You'd still do a retro and youstill do a sprint planning. The
reason being, you want to learn.
And imagine if you always extendyour sprints, you have busy
stakeholders that blocked someportion of their calendars to
(37:56):
come to your sprint review. Ifyou now extend the sprint, they
have to reschedule everythingthat won't be possible, they
will hate you and they will notcome again to your sprint
reviews. So you try to stickwith the consistency. And the
next step actually should be toremove the underlying
(38:17):
impediments that prevent youfrom delivering at all. So if
you have system issues thatprevent you of delivering, for
example, failing test, test datathat's not consistent, some sort
of system that's down, systemsthat are owned by a different
(38:37):
team you don't have access to orstuff like that. These are
traditional impediments. Grabyour scrum master, let them
solve it. You will not be ableto work in any agile way if you
have these dependencies. So fixthem, and afterwards, life will
be all flowers, fluffy, rainbowsand unicorns, and you can
(38:59):
finally have more fun actuallydelivering and working. And then
it's not so important. If youjust release a small user story
or a big feature or something,having the consistency of
delivering over and over againthat creates motivation,
especially for the developers,
Lindsay Velecina (39:21):
right? Thank you. All right, I hope that
helps. So next one here, anyadvice on estimating key results
for a quarterly OKR, typicallyScrum teams might have only two
sprints worth of refined andsized ready backlog. All right,
so
Dominik Maximini (39:40):
we have a situation where the company is
using OKRs and using Scrum atthe same time, which is fine, it
can work. One word of warning,though, most companies I have
seen so far that claim to bedoing OKRs are actually doing
MBO management by objective. Sotop down objectives that are
(40:02):
poured from the top down intothe teams and then telling them,
now you can be agile as much asyou want, as long as you deliver
everything I told you to. Andthat is not how OKRs work, and
it's not how Scrum works. Nowbeing constructive, what I
(40:23):
usually do with OKRs is I takethe key results, I let the team
estimate only, does it fit intoa single sprint, or does it fit
into a let's call it release, orinto a bigger scale, and if they
say it fits into a sprint, thenit can actually be a quite nice
(40:44):
sprint goal. So we can use it asa sprint goal, and if it's
bigger than a sprint, then wecan use it as a product goal.
And that works fine. Justremember, always focus on the
single goal. Do not try tofulfill seven key results at the
same time that does not work.
Focus on a single goal andalways remember, if it's
(41:06):
impossible, well then it'simpossible. So just somebody
wishing for 20 stories in asingle sprint does not make this
happen.
Lindsay Velecina (41:20):
That's great.
Thank you. So what are somefactors that we should consider
to predict estimated releasedates, a ballpark for the
stakeholders? What data from ADOor JIRA can I use to come up
with that? Somebody asked, allright, I asked.
Dominik Maximini (41:43):
All right, I will explain it independent from
the Gyra question, because afool with a tool is still a
fool, and many people rely onsome sort of digital tooling and
defy common sense. And I and theeasiest way to project I always
(42:05):
do it when I enter a team forthe first time or a company for
the first time. The easiestthing you can do is count. So
count the number of, let's callit issues in the gyro language,
or it could be user stories orproduct backlog, item, whatever
you name it, count them persprint. How many were planned,
(42:31):
how many were finished? And byfinished, I mean really, really
done. Not sort of, yeah, we arealmost done, but the testing is
missing or something, yeah,really done, and just count, and
that usually gives you moretransparency than if you run
some fancy reports in some tool.
And what I do then is I use thenumber given, for example, I
(42:56):
could come up with just bycounting. And I fully know that
some things are big and some aresmall. I'm just counting like a
stupid idiot, yeah. And forexample, I could come up with a
number of 40% saying, okay, theyplanned 100 things and they
delivered 40 over a span oftime, 40% now they are planning
the next big thing, for example,a quarter or half a year,
(43:23):
whatever I will tell them, thedevelopers, hey, with the
numbers of the past, I don'tbelieve you. You said you will
now deliver 200 things with thenumbers from the past. I think
you are only going to deliver80. 40% of 200 is 80. And that
gets the conversation going, andvery often it goes into the
(43:46):
direction of Yes, you are right.
We don't believe in thesenumbers anyway, but we fear that
if we raise the real numbers,management will be all over the
place, and we won't be able towork, because we will have to
jump from one task force meetingto the next, and that, again,
gives you some leverage to dealwith management. Now, with
(44:08):
regards to what to consider forthe estimate, it's usually the
amount of uncertainty. So howuncertain are the requirements?
Have we worked with the customerbefore? Have we worked with that
type of product before?
Technology? Have we worked withthat programming language
before? Have we worked with allthe frameworks before? Do we
(44:30):
know technology? How many in ourteam are seniors and how many
are juniors? And is that a goodthing or a bad thing, because
sometimes the juniors are fasterthan seniors, but sometimes it's
the other way around. So I needto develop a feeling there and
then the team itself. Do theyalready know each other? Is
(44:51):
everything new to them? Havethey never met? Are they
dispersed over many differentlocations? Have. They never met
in person. Are they fromdifferent cultural backgrounds,
or are they coming from the samecultural background? Stuff like
that. These are things I wouldconsider, and what I often do,
because I'm the outsider, Idon't have all that information.
(45:15):
What I usually do is I walk upto the stakeholders separately,
and I walk up to the developersseparately, and I ask them in
those three dimensions, sorequirements, technology and
people, and ask them, how big isuncertainty there? What do you
think? And then I get datapoints from everybody. And with
(45:36):
these data points, I get a firstidea of how uncertain that is.
And with that uncertainty, Iusually make that uncertainty
transparent to management when Ipresent the numbers. So I have
counted the past. I have somesort of project archeology where
I dug out the old data, and Ican tell them, hey, you had so
(46:01):
many projects, they were, onaverage, so much later than you
believed. I have the individualdata points from developers and
from stakeholders, and then Icompare them, and what very
often happens is that they arein the same ballpark. So the
other projects where, forexample, 50% late. My team in
(46:23):
the past was 40% late. The dataestimates from individuals might
show they are 55% late. And thisis so close together that I
would walk up to management andsay, Hey, we have an estimate,
but I would assume that we willbe 50% later. So here's my real
estimate. Go for it. Okay, andlet me finish that. Sure, the
(46:49):
more data you have, real lifedata, with the correct product,
the right technology, the rightpeople, the more data you have,
the more precise your forecastwill be, but it will never be
100% precise.
Lindsay Velecina (47:10):
Okay, thank you. All right, so we are trying
to get to as many of thesequestions as possible. Your
answers have been really, reallythorough and really great
Dominic. So thank you. Sowhichever questions we do not
(47:30):
get to, I will be sharing themall with Dominic after the
session. We'll figure out a wayto address them. So don't worry,
we're going as quickly as we canthrough these, but we also want
to give good answers. So this isa bit of a big question, but I
think it's something that peoplecould relate to, so I'm probably
(47:52):
going to paste it into the chatfor everyone if it lets me do
Yes, all right, and I will readit as well. So one of the most
common challenges we have withforecasting is that some
(48:15):
percentage of the team almostalways ends up supporting the
previous batch of work past thestart date of the next chunk of
work. This isn't reflected inthe velocity as misses for from
the previous release get addedin as tracked work, but less of
(48:37):
that velocity is actually beingapplied to the work that
management seed has started andis expecting us to deliver based
on the previous estimates, anyadvice for managing expectations
preventing this or Getting aclear picture of the impact
(48:58):
earlier on I Uh huh.
Dominik Maximini (49:03):
Now I'm not 100% sure that I understood it
correctly, so I will try torephrase it in in simple terms.
We have a team working on somestuff. They are not really,
really done, because when theywork on the next sprint or the
next release, doesn't matter. Sothey they continue with
something else. Then unfinishedwork from the past pops up. They
(49:27):
have to work on that. And that,of course, really reduces
velocity for the new stuff. Andthen management comes around the
corner and says, You're tooslow. You have to be quicker.
That's what I understood. There.
Would you agree there? Lindsay,yes,
Lindsay Velecina (49:41):
I would agree.
All right, good advice there.
Dominik Maximini (49:45):
Good so if we did not understand it correctly,
I'm sorry just to try to diveinto that.
Lindsay Velecina (49:53):
Yeah, and you can always follow up with
Dominic after the session aswell.
Dominik Maximini (49:58):
Of course.
Yeah. Okay, now, what should youdo? The first thing is you have
to address the underlying issuesfor the undone work popping up
again. If you follow Scrum, thenyou would only deliver done
pieces of work. So done productincrements and done means
(50:20):
there's no work remaining, forexample, tests or whatever. Now
if there is work remaining, oneavenue of approach is that you
tighten your definition of doneso you improve quality. And if
you're successful there, theamount of work spilling over
into the next Sprint will willbecome less and less until it
(50:44):
trickles out and is virtuallyzero. The next thing is only
count velocity for things thatare really, really, really done.
So if you have some chunk ofwork and you're like, 98% done.
It's just those two tests thatare still missing. Then in scrum
(51:05):
logic, it's not done. And notdone means zero in velocity. And
then formally, it goes back tothe product backlog. The product
backlog is ordered by theproduct owner, so the product
owner can decide if it should bein the next sprint again. But I
mean, honestly, usually theproduct owner still thinks it's
(51:28):
important, and if it's 98% done,of course, he wants to get the
rest so. But the formal way isthrough the product backlog, and
if it's then done in the sprint,and really, really done and
finished and delivered. Then youearn the velocity points, and
that also helps you withmanagement, because management
(51:49):
understands that velocity isconsistent over time, and you
deliver over time consistently,but you don't deliver garbage.
And many, many managers, not allof them, but many of them, think
it's more important to bereliable than to be fast. So if
you have a reliable output inhigh quality, that's usually
(52:15):
higher valued than beingunreliable in quality and speed,
so they have something again tomeasure and to manage. Let me
think what else could behelpful.
Lindsay Velecina (52:35):
We did get feedback from David that you
understood it perfectly.
Situation. Good
Dominik Maximini (52:41):
luck today.
Yeah, yeah, right. So, David, ifyou're in the chat anyway, um,
does that answer your question?
Just yes or no?
Lindsay Velecina (52:55):
Yes, perfect.
It does. So
Unknown (52:57):
bring it on. Lindsay, next month.
Lindsay Velecina (52:59):
All right, so we have time for a couple more,
I think. So how do you deal withaligning the definition of Done
and forecasting implications,
Dominik Maximini (53:10):
aligning DOD?
Do you mean align? Well, I'm notsure if you can answer that, but
align with the forecast oraligning with another team
Lindsay Velecina (53:22):
I'm thinking aligning with the forecast. All
right? Says, How do you dealwith the aligning definition of
Done and forecastingimplications?
Dominik Maximini (53:33):
All right, from my point of view, that's a
pretty simple question, becauseyou only deliver what fulfills
the definition of done. I mean,the scrum guide reads, as soon
as a product backlog, itemreaches the definition of Done
and increment is born. So that'slyric. What that means is that
(54:01):
every forecast you do includesfulfilling the definition of
done in its entirety foreverything you do. So whatever
forecast you come up withalready includes the full
definition of Done. Now it's alittle bit different if you
tighten the definition of donewhile you work. But then again,
(54:24):
my experience is usually itdoesn't make that a big
difference, because the time younow spend in doing quality work
you spend earlier in fixingboxes. And it really doesn't
matter if you now fix a bug orif you do it right in the first
place. On the contrary, usuallyfixing the bug takes longer than
(54:47):
doing it right in the firstplace, because you have built
stuff on top of that bug, andyou have to work through that
complexity again.
Lindsay Velecina (54:57):
Okay. Do.
Thank you. All right, so, sosomeone asked this question, so
they said, You already mentionedrapidly. But can you please
explain this further? Is Scrumand fixed time boxes still
relevant or not in a DevOps CICDcontext, what is the best work
(55:21):
method to use when delivery issupposed to be continuous?
Dominik Maximini (55:29):
Well, again, I'm not sure what the best way
to work is, right? Lindsay,please pluck your ears for a
minute, because, in reality,even though I'm here as a scrum
trainer. I don't just use Scrumdepending on the context. I also
use Kanban elements, orAbsolutely,
Lindsay Velecina (55:48):
you shouldn't tell me to cover my ears for
that.
Unknown (55:51):
Well, I don't know scrum.org.
Lindsay Velecina (55:54):
We are all about, you know, complimentary
practices and using what worksbest for your team. So
Dominik Maximini (56:01):
there have been instances where it didn't
you scrum at all shocking. Iknow
Lindsay Velecina (56:06):
it happens
Dominik Maximini (56:09):
anyway. Yeah, if we are in such a situation
and somebody is walking up to meand saying, Hey, we work with
continuous development,continuous integration,
continuous deployment. I say,congratulations. That's what we
do in our days. That's today'sway to work, perfect. Now these
(56:31):
arguments usually come from theperspective of the developers,
and from the developersperspective, they are totally
right. Now you also have toconsider the perspective of the
user, the perspective of thestakeholders. For example, your
marketing department and yourmarketing department doesn't
like daily new releases. Whatthey like is being able to tell
(56:57):
to the customer, hey, here'ssomething big coming up. Now you
still can deliver that big chunkof work with small, incremental
releases. That's exactly what wewant to do, but you have to
allow other people, be it yourstakeholders or your users, to
absorb that. And in many cases,the way to absorb it and the way
(57:18):
to communicate it is some sortof roadmap. So even though you
deliver continuously, you mighteven deliver it continuously to
the end user. Still, thecommunication and the management
from your internal stakeholderswill be in some sort of time
chunks. And these time chunkscould be product goals, sprint
(57:38):
goals, releases, so formalreleases that include some sort
of release notes and maybe abottle of champagne for the
customer, even though, on thetechnical side, it was done in
incremental daily releases,
Lindsay Velecina (57:55):
right? Thank you. All right, so we don't
really have time for any morequestions, but I will share we
have 25 remaining questions. Wehad a lot come in, so I will
share those with you after thesession. Are there any pieces of
advice that you want to leavethe audience with? Dominic, this
was a really big topic. Youcovered a lot. Got some great
(58:17):
feedback from the audiencealready. But what are Is there,
like a specific piece of adviceyou want to leave people with
when they're thinking aboutforecasting and release
planning? Yeah,
Dominik Maximini (58:31):
maybe two pieces. The first is, use common
sense. Please don't get hookedup to some method no matter
which one and believe thatmethod will solve all your
problems, use your brain cells,use common sense, and the second
one is always try in adiscussion with whoever. Try to
(58:55):
walk in their shoes, try tounderstand what their need is.
So management is not evil orsomething. They just have
different needs than you mighthave, or other than the
developers might have. And ifyou are successful in walking in
their shoes for a mile, then itwill be far easier for for you
to have the meaningfulconversations with people. So
(59:19):
use common sense and try to viewmatters from their point of
view. Please,
Lindsay Velecina (59:26):
okay that that makes perfect common sense. So
thank you everyone. So much forattending. Like I said, we'll
figure out a way to address theopen questions and Dominic,
thank you so much for yourwisdom and for being here. It's
been really great.
Dominik Maximini (59:47):
It's my pleasure.
Lindsay Velecina (59:48):
Thank you so thank you everybody and Scrum on
and have a great rest of yourday. Take care. Bye, bye. You.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!