Lindsay Velecina: 0:02

Steve, welcome to the scrum.org community podcast, a podcast from the home of Scrum in this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. This episode is a previous recording of our live ask a professional scrum trainer series where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode. Hello, everyone. Good morning, good afternoon, good evening, wherever you're located today, welcome to today's Ask a professional scrum trainer for those who are here on the live session, welcome and those who are tuning in on the scrum.org community podcast, welcome. We have with us today. Pst, Dominic Moxa Mini, and he is here to answer your questions about forecasting and release planning. So I'm expecting this to be a very interactive session with lots of questions. Something that I forgot to do is introduce myself. I'm Lindsay here@scrum.org and I will be hosting our session today. So very quickly, about scrum.org so we are the home of Scrum. We were founded by Ken Schwaber back in 2009 and our mission is to help people and teams solve complex problems, and we do so through our training, certification and ongoing learning. We have a lot of free ongoing learning on our website. I'm assuming that you all are familiar with that, so please check that out, and I hope that today's session plays an important role in your learning journey as well. So with all of that, I'd like to hand it over to Dominic so that he can introduce himself and then we can start diving into questions. Welcome Dominic.

Dominik Maximini: 1:52

Thank you very much. Lindsay, well, I won't introduce myself for a very long time because we want to jump into questions quickly. Just a note, I've been working now in different scrum roles for more than 18 years, so I'm coming here with lots of experience, and hope to share some of that. I also have been a PST since 2011 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 smile on their faces, and I hope that with all the participants today, we will get one or two of them smiling when they go to work tomorrow.

Lindsay Velecina: 2:36

Awesome. That's a good goal. All right, so thank you, Dominic. All right. So you can start entering your questions. I'm going to stop the share here see what we got. So you could, like I mentioned before, please utilize the Q and A button at the bottom to enter your questions. We can utilize the chat then for any technical issues. So let me just flip a few settings here. So I have a question here. Dominic, so why estimate at all if we work in a complex environment with high levels of uncertainty?

Dominik Maximini: 3:15

That's a very, very interesting question. Imagine you want something from somebody, be it something simple like a new kitchen, or something a little bit more complicated, like new house, or even something bigger. One of your first question will be, how much does it cost, and when will I have it? And the difference in the complex environment is that estimates will change over time, because requirements change and things happen. You know, life happens and stuff, and still, your stakeholders and your customers will want some sort of answer, and also you want to know if you are still on track or not. So you need some sort of plan, and you need some sort of idea when you want to be rare so you know if you hit your target or not, and the way to get there is estimation.

Lindsay Velecina: 4:16

Awesome. Thank you. Do you want to maybe, like, help set the stage for just why you proposed this topic, and what you've been seeing other teams do to kind of help spark some questions from the audience. Yeah, sure.

Dominik Maximini: 4:35

Probably everybody in the audience is part of some sort of more or less agile teams. They might be SCRUM masters, they might be developers, they might be product owners or something entirely different. And all of them, no matter in what role, will have some sort of management in their company. And the number one top question of management is always. When will I get it? When will it be done? And that's true in my project as well. So very, very often that question is posed by some sort of management, and they need, obviously, to know when their budget will be running out and what they can promise their customers, and to get into the interaction with management, you need to speak the language of management, and that language of management is pretty much estimation. That's why I brought it here, because it's entirely possible to estimate and to do it in a simple way and not be nailed down with a single day on the calendar wall or something, and there are ways to do it. So if you have questions about that, feel free.

Lindsay Velecina: 5:53

Awesome. Thank you. All right. So question here that came in, if I have many teams that make up a release, I can see the estimates for my features for the release. I know how much time we have left, but how do I know it's on track using a chart? I don't know that burn down, burn up gives the full picture,

Dominik Maximini: 6:16

because of the many teams, right?

Lindsay Velecina: 6:19

Seems that way. Yeah,

Dominik Maximini: 6:22

all right. I'm not sure if everybody in this call is aware of the burndowns. So let me introduce burndowns first. There are different, let's say tastes, different flavors of burn down charts out there. What they all have in common is that on the x axis they have plotted time and for a product owner or a project manager or something, that's usually the sprints we have there, and every burndown chart on the y axis has the work remaining plotted. And let me give you a short example. I'll share my screen. I kind of anticipated some sort of question like that. What you see here, if you are on the video call, is a professional Burndown Chart, like you would use it in project. And it actually is from a real project of myself. It was done in 2015 2016 so quite a while ago, I'm getting old, by the way. And what you see here is, on the very top, there is a 200 that was the estimate for the project scope. So in this specific context, the board said, Hey, if you want to do the project, you have to estimate all of it, so like in a traditional waterfall environment, so we estimated all of it with story points. Actually, we didn't have a clue, because it was a new team, new technology, new product, but still, we estimated it and get did our best. And what you then see here in the column that says real velocity is we slightly increased it. So in the first sprint, we got a one, then a two, then a six, then an eight, then a 10. And now take a note of the burn down you see in the chart right now, it's just one line because we don't have many data points. So if I put, for example, a 12 in here, what you see now is that we have a cone opening 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 we don't have to discuss it here or or argue or anything it happened. Yeah, that's reality. And from that point on, we have an extrapolation for a best case, a worst case and an average case. And you see that it touches down between Sprint 23 and 27 somewhere around that time. And you also see two vertical lines. These represent the colored dates on the very top. These were the prescribed release dates. And yes, we did have to release on the 25th of December. And yes, that was Christmas. And no, the board was not there when we did the release so, but what you easily see here is, at what height do we cross the vertical lines? So at the release date, will we have 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 say we have a slow sprint. Let's say we only achieve six that sprint. Then you see the cone opening up gets wider. And when I talk about estimation and. And doing some sort of release plan. This is what I'm talking about. I'm usually not giving a single date. I'm giving a cone. I'm giving a range from when to end. And what I usually also do is I tell management, okay, if you want to increase the likelihood of hitting the good date. Here's my list of impediments you can help me fix, and that gets some fruitful conversations going. Now, with regards to many teams, let's say we have five teams or 20 teams, or something like that. Obviously every team might estimate a little bit differently, and that's fine. I mean, you don't want to normalize velocities. That doesn't work. It's not cost efficient. In that case, you will have specific burn down charts for every single team. But when you try to put them all together into one graphics, it usually will not be a burndown chart. You usually will have something that's more resembling a roadmap, or you will have a quarterly view or something. And whenever a single team runs out of bounds, then you usually put the whole thing on red, and you try to fix the underlying issues. And I'm not talking about overtime, I'm talking about 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 multiple levels of abstraction removed from the code or feature on the ground, what would be the best way to set the tone with leadership that these are estimates that are subject to change, and show the changes and the impact to timelines and costs using change management.

Dominik Maximini: 11:52

All right, the first step actually would be to get a dictionary to management and show them the difference between estimate and fact, because in many cases, management treats estimates as promises as facts. But that's not what we are here for. And what I usually do when I'm in such an environment is I ask management, how many projects have you done within the last let's say two years, three years, five years, some time span. That's common for them. And then they name some random number, maybe 30, maybe 50, maybe 100 and then I asked them how many of them were in time, in scope, in budget. And usually the answer is none of them, or only a very small percentage of them. And then I go on with explaining to them. The reason for that is that we are in the complex domain. Many things change. So if in the past we couldn't hit the dates, why do you think we will hit them this time? And usually the end of that conversation is that management says, well, they need some sort of number, date, whatever, so they have something to manage. And the art of change management, and I'm not talking about requirements change, I'm talking about organizational change. The art of change management now is to shift the conversation away from managing dates towards managing value. So what is value for the company, what is value for the user, for the customer, and how can we maximize value? And how can we do that early? And if you are successful there, you will have a very good relationship with management, because you are striving to achieve the same goal, maximize value for the company. So give them something to manage, which is value, but get away break apart from the time aspect. It's just an indicator that's not very valuable.

Lindsay Velecina: 14:09

Okay, thank you. I hope that helps. Several of you who are here on the live session are putting your questions in the chat. If you could please move them over to the Q A that would be really helpful so that we can manage the questions better. So thank you for that. This question here, so how do we create realistic forehead forecasts 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 you know that doesn't change. If your team changes, if your requirements change, if the world around you changes, obviously whatever you estimated before will not be met. So I would shift away from a. How can we hit the date if everything changes towards how can we organize ourselves around all that change and organizing around it means, first of all, do we have to change? And obviously, if we realize that our assumptions were incorrect, the world is turning around, whatever, of course, then we have to change direction, and that also changed the estimate and our forecast. But sometimes we realize, actually we don't have to change. The only one changing is the CEO every time he visits a trade fair or reads a new book, and if we have that, then, as a product owner, I would focus on making transparent. What are our personas? Who are our users, what is value for the users? And I would try to get into a conversation that goes along the lines of, Hey, dear CEO, you're coming around with new ideas now, for which stakeholder group is that relevant? Which value of that stakeholder group does it help? And what other value will we not be able to achieve if you follow yours? Because usually these people don't, don't recall, don't don't realize that their new wishes have costs with the old wishes. They always believe they can have it all, and that's not going to happen. That's the sort of conversation I would try to get them into.

Lindsay Velecina: 16:38

Okay, thank you. Right next one here. What are the best practices for forecasting and release planning of topics that have interdependencies to other teams, meaning there are other teams. Input is a prerequisite to move on. All right? The other team, I assume might have been a typo, meaning the other team's input is a prerequisite to move on.

Dominik Maximini: 17:05

Yep, got it. First of all, the question was for best practices. Best always assumes there is nothing better, and it works everywhere. And since we are in the complex domain, there is nothing such as a best practice. Every context is different. So I would rather go into something like good practices, or with one company, we called it our current best approach, our CBA. And the second thing is, if I put on my my scrum cap. So if you're just listening to it, I'm just putting on a cap that says dogma cap. We have to understand that if we are doing pure Scrum, vanilla Scrum, then we have to have a cross functional team, and that means no dependencies outside, outside the team. But then again, I realize that not every context has the ability to do that for whatever reasons. So if we are really dependent on somebody, we will have to work with them very, very closely. We will have to estimate together. We will have to come up with a joint roadmap, so not having roadmap a and roadmap B, and then hope that it fits somehow. No, we need to have a joint roadmap, and we need to visualize dependencies on that roadmap. Usually we do it with some straws or tape or whatever. So we see product backlog item 4711, maps to product backlog item 8080, or something, and then we see the dependency and the people responsible for those teams. Hopefully it's a single product owner, but very often it isn't. Very often, it's two product owners. They have to work together. Now, in the long term, if you're getting more agile, you will most likely figure out that you are better off if you actually create new teams, make them truly cross functional, of course, only if you have recurring dependencies, if it happens once in a while, nobody cares. But if you have recurrent dependencies, you're always dependent on the other team, then think about recreating the teams so they are truly cross functional.

Lindsay Velecina: 19:34

Awesome. Thank you. I hope that helps. All right, so here's a question here, how can a new team forecast being a new team? They won't have any empirical velocity performance data, so they 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 if you're doing waterfall or whatever, if you have inexperienced people in that topic, inexperienced people, whatever they estimate, will just be plainly wrong. And it has always been like that, and it will always be like that. Now the difference is, how do you deal with that? And if we are in a complex environment, and if we are doing Scrum, then we will revisit the estimate over and over again. So for example, let them do an estimate, then work for three months, then re estimate it, and you will see the difference. And coming from a practical point of view, what I usually do with my new teams? Imagine completely new team. They have never met before, new topic. Of course, they are firm in the technology, but they have never applied it on the problem. So technology is always kind of new. I usually use them for a week, and we work with defining who's the customer, what is value for them, what's the vision? Of course, most of it is prepared. But then with the developers together, we forge it a little bit, and once they understood it, then we look at the product backlog on a very high level. So in many teams, that's called epics. So we look at that, and then the key comes. I walk over to the team and tell every single person in the team to give me three estimates. They have to write it down on paper, hiding it from each other so they don't see what the others are writing. And I ask them write down a date. So really a date in the calendar? Yeah, write down a date. What's the best case you believe we can finish this? Second, what's the worst case you believe we will be done? And third, what do you really believe when will we be done? And then we have three points estimated by everybody. We turn it over, we make it transparent. At the same time, we put it on the wall, and then I see two different things. The first is, how close or how far apart are the clusters inside? So with every developer estimating a worst case. How far away are the worst cases? How far away are the best cases? And the second thing I see is, how far away is the average estimate of the best case, the worst case and the average case? And that gives me some idea of how good the estimates are. Obviously the further apart they are, the the higher the uncertainty and the worse the outcome will be. But quite often, I have the case that estimates are close together, and we actually hit them more or less because of the time we spend together during that week to get familiar with the matter. So that is something I can recommend. But again, what I said in the beginning, do it again. So use two or three hours to do that first estimate, but after a couple of months, after a couple of sprints, and I usually say three to four sprints at least, then re estimate it, and that estimate will be better.

Lindsay Velecina: 23:26

Okay, thank you. All right. I hope that helps. So next one here. We're just moving right along. Lots of questions keep them coming. So what is your this kind of ties into that a little bit. What is your experience using Monte Carlo simulation for forecasting, and what are the crucial things to consider when implementing it?

Dominik Maximini: 23:52

All right, Monte Carlo simulation. There are people out there who love Monte Carlo simulation. There are people out there who hate Monte Carlo simulation? I'm in neither camp. I tried it out a couple of times. My personal opinion on that is that it can be a very helpful tool if you have some sort of stability. So the team is always estimating correctly or incorrectly by the same amount, but very often you don't have that. Very often also, the sizes of the stuff you're doing is very far apart. Very often during a project, you're changing direction, and everything is different now. And what I experienced as the biggest problem is that Monte Carlo simulation gives some people the idea of certainty, because it's some accepted model, it's some sort of calculation. And I. Put numbers into a system, and the system tells me another number, and then I believe that number, and this false sense of being right is something I then have to fight as a product owner. So honestly, I have used it a couple of years ago, but I no longer use it. I try to use methods that convey by the very method that it's uncertain, and it's a big difference if I tell management, we estimated this as a t shirt size M, or we estimated it as a stegosaurus or a yellow gummy bear, rather than going there and telling them, we put all the numbers into Monte Carlo simulation, that tells us we will be done by June. Now, more or less, of course, I'm exaggerating. I just want to 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 chart only works for a set scope of work, such as implementing a specific large feature. Is that correct? We are adding new features, running our platform and fixing bugs. Does that change anything about the estimation and burn down charts and delivery dates?

Dominik Maximini: 26:28

Good question. First of all, you use a burndown chart to come up with some sort of forecast. You can only forecast something where you know the scope. Yeah, if you don't know the scope, you can never say when you will be finished, obviously. Now, if you are in an environment where part of your work is development work, let's say having features you want to implement, or something like that, and the other part is some recurring work that you cannot estimate beforehand, for example, fixing bugs or having to do maintenance stuff, or some teams even have to be on the support hotline and do support calls. Then obviously you cannot put that into the burndown. However, what you can do is you can reserve some time for that. So for example, you might know that 30% of your time is used bug fixing or something like that. And if you know that, then you can create placeholders for that in your backlog. Now, if you are more in a rebel mood today, what you could then do is just ignore it, because it will reflect in velocity. If only what you manage to develop in features in the complex world is counted towards velocity, then velocity will be smaller, because obviously the chunk where you did the support part is not in there, and then it evens out, and your burn down is correct again, because bugs are not in velocity and they are not in scope. But most people I know try to work with some sort of placeholders. 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 further in on any of the answers that come in, please, please do any follow ups in the chat so that I can utilize those. Okay, right? So this next question here, in the case of multiple teams being involved in a project using a single backlog to drive progress. The challenge with story point sizing is every team sizes stories differently. What are the your recommendations on aligning sizing so that we can actually convert the estimates to dates in a way that works for all teams?

Dominik Maximini: 29:22

Yeah, yes, yeah. First of all, whoever asked that question, congratulations, you have one backlog for many teams that's already a big leap ahead. So congratulations. About the estimation, I would not try to normalize velocities in any way. You, of course, can do that, but that would mean all teams develop the same stories over a period of time, and you already know in advance that this is a complete waste of time. So you don't do that. What you do instead, in practice, is you. Draw up some sort of roadmap. So imagine a big wall in front of you. You have lanes under each other, and each lane is one team, and you have partitioned these lanes into sprints. And it can be that sprints have the same length, which I would actually recommend if they are working from the same backlog, but it can also work if they have different sprint lengths, and you would see that on the wall. So for example, on the very top, you have first the the months and weeks, and below that, you see the sprints, and you see which weeks are covered by which sprints. And then have lanes for every team, and no matter by what system teams estimate, after they did their estimate, they should be able to place product backlog items in their lane, in the respective sprints, and that is all you need. So no matter if one team estimates in story points, and another one in T shirt sizes, and the third one doesn't estimate at all. They just do gut feeling or whatever. You still can organize every single team in that roadmap, and since it's a joint roadmap, you can also highlight the dependencies, if there are some and you can, or you basically have normalized your estimate in the form of that giant roadmap. And I've done that numerous times, and it works pretty well. Let me show you a picture, and let me search for it a minute so you see it in a great context. Yeah, here we go. I'll share my screen in a minute. So if you're just listening to it, I'll try to describe what's on the picture. In that context, we had 36 teams working from the same product backlog. On this picture, you see a wall, and on that wall you see 18 of these teams. These were the software teams. And you see different columns, like, what's the status, what's the name of the team, who are the team members, what is missing. And then you see stories in the current sprint, stories in the next sprint, and then you see backlog, so at some point in time that's further away than this sprint and the next sprint, and that environment was so uncertain that we didn't know what happens ahead of two sprints. And what we did here is that every other day, so basically, two times a week we were standing in that room, facing that wall. And when I say we, it's all product owners. We had several product owners and whoever was interested, and sea level now, so the full sea level was there, and then we checked out. Where's the problem? Where do we need to collaborate? Where do we need to have a decision or something? And since all product owners and sea level was there, decisions could be made on the spot. And that's it. And as you can see on that picture, there are no estimates visualized on that board because it was just irrelevant, because we knew what stories are in which sprint.

Lindsay Velecina: 33:35

Thank you. All right, so we're going to switch gears a little bit. So someone had asked, Can you speak more on release plan? On the release planning portion of the topic, what are some general approaches to planning a release versus planning a sprint? And some teams release continuously throughout a sprint, and some wait a few sprints before having a release? Yes. Their situation,

Dominik Maximini: 34:03

I would almost say that that goes into the direction of a terminology question. Um, back in the good old days, when I was young and my hair was not gray, at least here, um, it was more or less normal for teams to release only a couple of times per year. So, for example, two times a year, or every quarter, or something like that. And from these days comes the term release planning. So we knew there is a release in three months. Oh yeah, we are doing Scrum. So we are having, for example, two week sprint. We are nearing the release, so it's six sprints per release, stuff like that. And other frameworks or methodologies like safe are still using some logic that goes into that direction. But today, as the person who asked the question is stating correctly, today. Today, some teams are releasing multiple times a day. Of course, then you would not say release plan, and that is one reason why the last update of the scrum guide in 2020 introduced the term of product goal. And you can imagine that product goal as some sort of milestone that could be a release, but maybe you have 20 releases leading up to that milestone. And since we want to avoid waterfall terminology, we don't call it milestone. We call it product goal. But this is the the way I visualize what people call release planning or reaching that goal, road mapping, whatever I have a goal I want to reach it I have maybe several teams, maybe just one, but maybe several, maybe even 30, and they all work towards that single goal, and now I have to plan work to get there. And that's what we just discussed with, for example, with the picture or with the description of having the lanes for each team and having the sprints lined up in the timescale. That's what we want to achieve. And the difference to traditional project management is that change is welcomed. We know there will be change. We are in a complex domain, for God's sake, so there will be change, and we will manage it as it comes up. While in the traditional world, change was always something evil, something 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 team is fairly new to Agile. Most of the time we end up extending our sprint. There are stories that get blocked on a system. Issue, is this a good practice? What? What can we do differently to have 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 a time box. So after the time box expires, you go back to sprint review, Sprint Retrospective. You do a new sprint planning, no matter if you completed everything you planned for no matter if you completed anything at all, even if you delivered nothing, you still do a review. You'd still do a retro and you still do a sprint planning. The reason being, you want to learn. And imagine if you always extend your sprints, you have busy stakeholders that blocked some portion of their calendars to come to your sprint review. If you now extend the sprint, they have to reschedule everything that won't be possible, they will hate you and they will not come again to your sprint reviews. So you try to stick with the consistency. And the next step actually should be to remove the underlying impediments that prevent you from delivering at all. So if you have system issues that prevent you of delivering, for example, failing test, test data that's not consistent, some sort of system that's down, systems that are owned by a different team you don't have access to or stuff like that. These are traditional impediments. Grab your scrum master, let them solve it. You will not be able to work in any agile way if you have these dependencies. So fix them, and afterwards, life will be all flowers, fluffy, rainbows and unicorns, and you can finally have more fun actually delivering and working. And then it's not so important. If you just release a small user story or a big feature or something, having the consistency of delivering over and over again that creates motivation, especially for the developers,

Lindsay Velecina: 39:21

right? Thank you. All right, I hope that helps. So next one here, any advice on estimating key results for a quarterly OKR, typically Scrum teams might have only two sprints worth of refined and sized ready backlog. All right, so

Dominik Maximini: 39:40

we have a situation where the company is using OKRs and using Scrum at the same time, which is fine, it can work. One word of warning, though, most companies I have seen so far that claim to be doing OKRs are actually doing MBO management by objective. So top down objectives that are poured from the top down into the teams and then telling them, now you can be agile as much as you want, as long as you deliver everything I told you to. And that is not how OKRs work, and it's not how Scrum works. Now being constructive, what I usually do with OKRs is I take the key results, I let the team estimate only, does it fit into a single sprint, or does it fit into a let's call it release, or into a bigger scale, and if they say it fits into a sprint, then it can actually be a quite nice sprint goal. So we can use it as a sprint goal, and if it's bigger than a sprint, then we can use it as a product goal. And that works fine. Just remember, always focus on the single goal. Do not try to fulfill seven key results at the same time that does not work. Focus on a single goal and always remember, if it's impossible, well then it's impossible. So just somebody wishing for 20 stories in a single sprint does not make this happen.

Lindsay Velecina: 41:20

That's great. Thank you. So what are some factors that we should consider to predict estimated release dates, a ballpark for the stakeholders? What data from ADO or JIRA can I use to come up with that? Somebody asked, all right, I asked.

Dominik Maximini: 41:43

All right, I will explain it independent from the Gyra question, because a fool with a tool is still a fool, and many people rely on some sort of digital tooling and defy common sense. And I and the easiest way to project I always do it when I enter a team for the first time or a company for the first time. The easiest thing you can do is count. So count the number of, let's call it issues in the gyro language, or it could be user stories or product backlog, item, whatever you name it, count them per sprint. How many were planned, how many were finished? And by finished, I mean really, really done. Not sort of, yeah, we are almost done, but the testing is missing or something, yeah, really done, and just count, and that usually gives you more transparency than if you run some fancy reports in some tool. And what I do then is I use the number given, for example, I could come up with just by counting. And I fully know that some things are big and some are small. I'm just counting like a stupid idiot, yeah. And for example, I could come up with a number of 40% saying, okay, they planned 100 things and they delivered 40 over a span of time, 40% now they are planning the next big thing, for example, a quarter or half a year, whatever I will tell them, the developers, hey, with the numbers of the past, I don't believe you. You said you will now deliver 200 things with the numbers from the past. I think you are only going to deliver 80. 40% of 200 is 80. And that gets the conversation going, and very often it goes into the direction of Yes, you are right. We don't believe in these numbers anyway, but we fear that if we raise the real numbers, management will be all over the place, and we won't be able to work, because we will have to jump from one task force meeting to the next, and that, again, gives you some leverage to deal with management. Now, with regards to what to consider for the estimate, it's usually the amount of uncertainty. So how uncertain are the requirements? Have we worked with the customer before? Have we worked with that type of product before? Technology? Have we worked with that programming language before? Have we worked with all the frameworks before? Do we know technology? How many in our team are seniors and how many are juniors? And is that a good thing or a bad thing, because sometimes the juniors are faster than seniors, but sometimes it's the other way around. So I need to develop a feeling there and then the team itself. Do they already know each other? Is everything new to them? Have they never met? Are they dispersed over many different locations? Have. They never met in person. Are they from different cultural backgrounds, or are they coming from the same cultural background? Stuff like that. These are things I would consider, and what I often do, because I'm the outsider, I don't have all that information. What I usually do is I walk up to the stakeholders separately, and I walk up to the developers separately, and I ask them in those three dimensions, so requirements, technology and people, and ask them, how big is uncertainty there? What do you think? And then I get data points from everybody. And with these data points, I get a first idea of how uncertain that is. And with that uncertainty, I usually make that uncertainty transparent to management when I present the numbers. So I have counted the past. I have some sort of project archeology where I dug out the old data, and I can tell them, hey, you had so many projects, they were, on average, so much later than you believed. I have the individual data points from developers and from stakeholders, and then I compare them, and what very often happens is that they are in the same ballpark. So the other projects where, for example, 50% late. My team in the past was 40% late. The data estimates from individuals might show they are 55% late. And this is so close together that I would walk up to management and say, Hey, we have an estimate, but I would assume that we will be 50% later. So here's my real estimate. Go for it. Okay, and let me finish that. Sure, the more data you have, real life data, with the correct product, the right technology, the right people, the more data you have, the more precise your forecast will 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 these questions as possible. Your answers have been really, really thorough and really great Dominic. So thank you. So whichever questions we do not get to, I will be sharing them all with Dominic after the session. We'll figure out a way to address them. So don't worry, we're going as quickly as we can through these, but we also want to give good answers. So this is a bit of a big question, but I think it's something that people could relate to, so I'm probably going to paste it into the chat for everyone if it lets me do Yes, all right, and I will read it as well. So one of the most common challenges we have with forecasting is that some percentage of the team almost always ends up supporting the previous batch of work past the start date of the next chunk of work. This isn't reflected in the velocity as misses for from the previous release get added in as tracked work, but less of that velocity is actually being applied to the work that management seed has started and is expecting us to deliver based on the previous estimates, any advice for managing expectations preventing this or Getting a clear picture of the impact earlier on I Uh huh.

Dominik Maximini: 49:03

Now I'm not 100% sure that I understood it correctly, so I will try to rephrase it in in simple terms. We have a team working on some stuff. They are not really, really done, because when they work on the next sprint or the next release, doesn't matter. So they they continue with something else. Then unfinished work from the past pops up. They have to work on that. And that, of course, really reduces velocity for the new stuff. And then management comes around the corner and says, You're too slow. 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 dive into that.

Lindsay Velecina: 49:53

Yeah, and you can always follow up with Dominic after the session as well.

Dominik Maximini: 49:58

Of course. Yeah. Okay, now, what should you do? The first thing is you have to address the underlying issues for the undone work popping up again. If you follow Scrum, then you would only deliver done pieces of work. So done product increments and done means there's no work remaining, for example, tests or whatever. Now if there is work remaining, one avenue of approach is that you tighten your definition of done so you improve quality. And if you're successful there, the amount of work spilling over into the next Sprint will will become less and less until it trickles out and is virtually zero. The next thing is only count velocity for things that are really, really, really done. So if you have some chunk of work and you're like, 98% done. It's just those two tests that are still missing. Then in scrum logic, it's not done. And not done means zero in velocity. And then formally, it goes back to the product backlog. The product backlog is ordered by the product owner, so the product owner can decide if it should be in the next sprint again. But I mean, honestly, usually the product owner still thinks it's important, and if it's 98% done, of course, he wants to get the rest so. But the formal way is through the product backlog, and if it's then done in the sprint, and really, really done and finished and delivered. Then you earn the velocity points, and that also helps you with management, because management understands that velocity is consistent over time, and you deliver over time consistently, but you don't deliver garbage. And many, many managers, not all of them, but many of them, think it's more important to be reliable than to be fast. So if you have a reliable output in high quality, that's usually higher valued than being unreliable in quality and speed, so they have something again to measure and to manage. Let me think what else could be helpful.

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, if you'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 with aligning the definition of Done and forecasting implications,

Dominik Maximini: 53:10

aligning DOD? Do you mean align? Well, I'm not sure if you can answer that, but align with the forecast or aligning with another team

Lindsay Velecina: 53:22

I'm thinking aligning with the forecast. All right? Says, How do you deal with the aligning definition of Done and forecasting implications?

Dominik Maximini: 53:33

All right, from my point of view, that's a pretty simple question, because you only deliver what fulfills the definition of done. I mean, the scrum guide reads, as soon as a product backlog, item reaches the definition of Done and increment is born. So that's lyric. What that means is that every forecast you do includes fulfilling the definition of done in its entirety for everything you do. So whatever forecast you come up with already includes the full definition of Done. Now it's a little bit different if you tighten the definition of done while you work. But then again, my experience is usually it doesn't make that a big difference, because the time you now spend in doing quality work you spend earlier in fixing boxes. And it really doesn't matter if you now fix a bug or if you do it right in the first place. On the contrary, usually fixing the bug takes longer than doing it right in the first place, because you have built stuff on top of that bug, and you have to work through that complexity again.

Lindsay Velecina: 54:57

Okay. Do. Thank you. All right, so, so someone asked this question, so they said, You already mentioned rapidly. But can you please explain this further? Is Scrum and fixed time boxes still relevant or not in a DevOps CICD context, what is the best work method to use when delivery is supposed 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 Scrum depending on the context. I also use Kanban elements, or Absolutely,

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 works best for your team. So

Dominik Maximini: 56:01

there have been instances where it didn't you scrum at all shocking. I know

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 me and 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's way to work, perfect. Now these arguments usually come from the perspective of the developers, and from the developers perspective, they are totally right. Now you also have to consider the perspective of the user, the perspective of the stakeholders. For example, your marketing department and your marketing department doesn't like daily new releases. What they like is being able to tell to the customer, hey, here's something big coming up. Now you still can deliver that big chunk of work with small, incremental releases. That's exactly what we want to do, but you have to allow other people, be it your stakeholders or your users, to absorb that. And in many cases, the way to absorb it and the way to communicate it is some sort of roadmap. So even though you deliver continuously, you might even deliver it continuously to the end user. Still, the communication and the management from your internal stakeholders will be in some sort of time chunks. And these time chunks could be product goals, sprint goals, releases, so formal releases that include some sort of release notes and maybe a bottle of champagne for the customer, even though, on the technical 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 more questions, but I will share we have 25 remaining questions. We had a lot come in, so I will share those with you after the session. Are there any pieces of advice that you want to leave the audience with? Dominic, this was a really big topic. You covered a lot. Got some great feedback from the audience already. But what are Is there, like a specific piece of advice you want to leave people with when they're thinking about forecasting and release planning? Yeah,

Dominik Maximini: 58:31

maybe two pieces. The first is, use common sense. Please don't get hooked up to some method no matter which one and believe that method will solve all your problems, use your brain cells, use common sense, and the second one is always try in a discussion with whoever. Try to walk in their shoes, try to understand what their need is. So management is not evil or something. They just have different needs than you might have, or other than the developers might have. And if you are successful in walking in their shoes for a mile, then it will be far easier for for you to have the meaningful conversations with people. So use common sense and try to view matters from their point of view. Please,

Lindsay Velecina: 59:26

okay that that makes perfect common sense. So thank you everyone. So much for attending. Like I said, we'll figure out a way to address the open questions and Dominic, thank you so much for your wisdom 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 your day. Take care. Bye, bye. You.