“When will we be done?” is the business equivalent of “Are we there yet?” And unlike “Are we there yet?” it is a much harder question to answer. All too often the answer is either “We don’t know” or “We must ship by August 7th, even if we’re not done.”
Recorded June 15, 2023, watch this webinar for an engaging webinar where we examine two ways to be able to answer this important business question. Joel Bancroft-Connors will give you a quick and simple technique to start with today and then our guest, Troy Magennis, will show us a way to answer this question with hard data, solid math, and years of success.
About Troy Magennis
Troy Magennis is an IT professional and executive, who has helped deliver valuable software to customers at scale since 1994. In 2011 he founded Focused Objective, the leader and trusted brand for Agile metrics and probabilistic forecasting. He regularly keynotes at conferences, eager to share his passion for using data in better ways to improve business outcomes. Previous clients include Walmart, Microsoft, Skype, Sabre Airline Solutions, Siemens Healthcare. Troy currently consults and trains organizations wanting to improve decision-making for IT through Agile and Lean thinking and tools, applying Scrum and Lean techniques appropriately, and where they are going to make this most significant benefit through quantitative rigor.
Want more Agile Webinars? Check some out below
Agile Metrics with Joel Bancroft-Connors and Laura Caldie
Agile Metrics: What Actually Matters with Joel Bancroft-Connors
Measuring Yourself as an Agile Coach with Joel Bancroft-Connors and Bob Galen
If you want more check them out | Here!
Transcript
* Transcribed Using AI. Please excuse spelling and grammar mistakes
Laura Caldie
Hi, there Joel. Hi there Troy Thank you for being here today.
Joel BC
Absolute Pleasure
Troy Magennis
Pleasure
Laura Caldie
It’s a topic I like to talk about as well but I promise I’m going to let Joel and Troy do all the talking, and I’m going to be looking at Questions and Q&A and all that kind of stuff. Before we get started talking about Agile Estimation and Capacity Planning. My name is Laura Caldie, I run sales and marketing here at Applied Frameworks, and I’m excited to be hosting this topic. Obviously, we will be recording this webinar and will post the link after. The other nice thing that we do is post unanswered questions in the follow-up email, so it’s never a waste of time to ask a question. So that’s kind of the rules of the game here and I’m happy to turn it over to the team. One more thing, We have a bunch of webinars that are related to this topic that is available on the Applied Frameworks website. So if you go to the Blog section you will find blogs about this and also past webinars. You will also find things about profitable software content. For now, we shout get going on the Estimation and Capacity Planning stuff
Joel BC
Hi, I’m Joel Bancroft-Connors, the Gorilla Coach. I am a certified Coach. You can follow me on LinkedIn and a Youtube account, where I post quick and easy tips about Scrum. For example, I have a 90-second video about why to hire a Scrum Master. Troy, can you please introduce yourself?
Troy Magennis
I’m Troy. I do boring math for people. I come out of the software industry, actually, I come out of the hardware industry moving into the software industry in the 90s. I worked well out to the level of incompetence as a VP for Travelocity and Lastminute.com, which some of you might know and use. And there I was the only executive who seemed to care or understand that developing software might be a little bit hard, might take a little bit of time, and is a little bit uncertain. So when I moved on from there, I decided to teach other executives to better understand Software development from a forecasting and development perspective
Joel BC
I am really thrilled to be able to do this with Troy. I originally met Troy at the original lean coffee conference, in Seattle Washington. Troy and I are actually both broadcasting from Washington State today. I am a self-professed failed art major. Math is not my strong point, even when Troy showed me this stuff, I don’t fully get it but it’s just so awesome and makes so much sense. And I always lean on when people say they want to go deeper and learn better I say, Well do you know Troy? So I am looking forward to talking about this. We are going to talk a little bit about how to do estimating and a better way to do estimating, then I’m gonna talk to you a little about the quick and dirty for Capacity planning. And We’re gonna turn it over to Troy interested to get some demonstrations of the tools and the techniques that he’s built up over the last decade and a half or more right
Troy Magennis 00:24
yeah, you ain’t shaming me now. But yes.
Joel BC 00:28
Look when you said the 80s I was kind of yeah okay I work with are better than I used to.
Troy Magennis 00:34
Yeah, so I mean, this things have evolved over many years. Maybe every time you do a new engagement, you learn something new and I tend to roll that in and so they’re, they’re my, they’re my other children. Alright,
Joel BC 00:48
and this just goes with my metrics and estimation. Presentations. Always remember if you can’t measure it, you can’t improve it. I think that’s a really important thing to remember. A lot of people think metrics is an evil thing. It’s like no, using metrics badly is evil. If you don’t have them, then you don’t know if you’re speeding on the freeway because a speedometer is a metric. All right, So we’ve got the mentee, but I’m going to kind of move beyond that right now. We’re still getting people coming in and such but I want everybody think about this, like, why do you estimate? And actually, if anybody wants to go and do this mentee, that’s great. I’m gonna ask you, Troy. I mean, again, you’ve got lots of experience in working with this kind of stuff. Why do you what do you what do you hear? As the number one reasons people want to estimate?
Troy Magennis 01:46
Sounds great question. And there is no one single answer, which is why we often get wrapped around the axle in the software world because the way the people who are going to code it, hear the word estimate, and the way that people will try to work out what they’re going to invest in. Either word estimate can often be in conflict. And we often jump to the conclusion that it’s got to be down to the day. So I mean, we obviously estimate at the leading end of software to try and work out out of all the ways we could spend our money in cash and devote our resources towards something which is the best way of doing it. And to understand that sometimes we want to know it’s going to take one week, one month or one year to do and so part of estimation is around that decision making process about what we’re going to do or what we from a pool of things that we could do. And then from the team side of it, we often sort of think about well, so now we’ve got to do this big chunk of work. How much of it? Can we get done in this small period of time, maybe called a sprint, or maybe called a quarter, or maybe called a month? And we sort of did go down and estimate in that level of detail to try and make sure that we’re not pulling too much in and swapping the team with too much work for a shorter period of time. So they sacrifice quality or they sacrifice value or something important like that. So we use estimation and capacity planning on the dev side to make sure that we continue to do the develop quality software, not just develop as much as we can and burn out and leave and go and work on Twitter or something like that.
Joel BC 03:29
All right. Thanks, Troy. So if we take the next question is okay, how do we estimate and I mean, I think we all hear the the go to when people think about estimating, usually it’s planning poker, and planning poker has been something that’s been used for a long time. I think playing poker is definitely a lot better than any other kind of estimation that Troy and I were doing back in the 90s. I mean, I remember estimations in the 90s. Like you’d ask a developer, how long is it gonna take Oh, it’s gonna take me two weeks and the manager goes on. I know that I know better. It’s gonna take at least at least a month. And then he goes and he asked his other developers and then he goes to the project, and it’s okay. It’s going to take us three months and the project manager says out and I know better, it’s going to take us at least six months, and then the entire project which was originally only like three weeks worth of effort takes 18 months. Planning poker is a lot better than those kinds of stuff. And honestly, I think it’s served this time and it’s no longer where we want to go. I kind of think of planning poker as more group Solitaire. You’ve got people and they’re literally they’re sitting there holding cards to put a story out on the table. It’s like okay, how big this is, the entire conversation how it happens in every single person’s head. And there is no conversation until after people have already put cards down. And once you’ve put a card down, you’re invested in that car, you’re invested in, in what what you think, and one of two things tends to happen either people anchor on that card, or chocolates down it puts down a three and I’m a junior developer, I put down a CERT team. When then we go okay, well, what’s the reasons and triggers? Oh, smart. So next round. I’m going to put down a three because that’s what Troy forget. And so you get expert bias. So the reason the reasons why planning poker don’t work. The Top Reasons are hostellers law. hostellers law basically says that you’re always going to underestimate the amount of work that it’s going to take even when you take hostellers law into account. optimism bias is all come on. It can’t be that hard. planning fallacy is, oh, we’ve done this before in the past. We’ve got this we’ve figured this out. And then finally, basically as human beings we don’t do time Well, we do not do time. Well, anything over about four hours and we’re not good at estimating. He asked me how long it’s going to take me to clean my bathroom which is up over there. I’m gonna say maybe about 30 minutes, but I’ve got a garage over here. It is a four car garage. There are no cars in it. You asked me how long it’s going to take to clean that I have no idea. These are reasons why planning poker doesn’t work well. So the question is, there’s gotta be a better way right? There is it’s actually been around for a long time. I listened to an interview just last week from one of the signers of the Agile Manifesto, who was the founder of XP, and I’m blanking on his name. And he was talking about doing early versions of this in the early 2000s. The idea is based around a principle that Luke Hohmann wrote about in his book innovation games, and it’s called 2020 vision. And 2020 vision uses the principle of going to the eye doctor, when you go to an eye doctor, they don’t go Okay. Here’s 20 lenses, which lens is the easiest one to see through. They go here’s a lens, is this lens more or less clear than this lens? And so it’s you’re always doing binary judgments against a baseline reference when I want to do I’m gonna change my share screen. We’re gonna go over the mirror. I’m going to show you really quickly the principle of how this works. And of course, I changed my share screen and I immediately lose my Zoom screen. We all got moved behind the q&a now. So with 2020 again, you start with that reference, you got your right eye and now you’re comparing the left eye against against the right eye. So we’re gonna start with a piece of fruit on Apple, and the question is how long does it prepare does it take to prepare this apple so that you can serve it and then you’re going to be comparing so we now have a plan up when we go okay, is a pineapple more or less effort than an apple? And this one’s pretty easy. We go Yeah, that’s definitely more effort. Then we’ve got a cherry and it goes a cherry more or less effort. That one’s pretty easy. Then we start to get a little bit of room. Okay, we’ve got a peach, and this is where then you may start to have conversations and a really good quiet conversations. Okay, well, here’s the customer. Well, in this case, the customer our preschool students, and this is for snack time. Oh, okay. Well, preschool students, you can’t just hand them an apple and say Here eat the apple. You got to cut the apple up. You got to you got to take the seeds out and then you serve it. Whereas a peach you can basically just slow your parsley, slice the peach twist it and you got to how’d you can hand it to two kids. So a cherry is easier to prepare and consume. That to prepare for consumption than an apple. Now we get to an orange. Okay, in orange. Again, preschool students, not only do you have to peel the orange, you’ve got to segment and you got to take out all that white stuff because if you don’t guarantee they’re going to start throwing it across the table. So we go okay on Orange is is more effort than an apple and so as you can see, it’s a really quick round robin conversation with your with the team. They have quickly gone from easiest to prepare to most complicated to prepare. The cool thing about this technique is you can also use this for value. You can go Okay, great. We could use the same 2020 technique to say what’s most valuable. Now, the interesting thing is if you’re dealing with preschoolers, there’s your value chain. The cherry is the most valuable kids love cherries and pineapples. You know, they’re weird they look funny. They’re not so sure about it. And only after you do this, you do something like assigning this only after you’ve gotten it from least effort to most effort to do something like assigning points but okay, we agree the cherry is is the smallest we’re going to arbitrarily call it one point. There’s no time associated with it. It’s just it is the smallest therefore it’s one point. When we go we know what the peach is two point however we started to think about it, an apple and a peach are almost the same amount of effort. There’s not much more effort between slicing a peach and slicing up an apple so both of these are to the oranges a little bit more complicated. And then we go you know what, not only is a pineapple, more effort than an orange, it’s a lot more effort. So it’s an eight point and we have no five point stories right now. Again, you can do the same thing with value and go pineapple is the least valuable thing here. Oranges, though, are a lot less valuable. Apples are a little bit more value. Kids really like peaches because they’re sweet and of course, kids really really like like cherries, in fact, wow. Not only do they like cherry, they like cherries so much that it’s it’s a 13 And so you can see a cherry is obviously one of the first things we want to build. It’s got a it’s got an effort, effort of one and a value of 13 kind of no brainer there. So this is simple relative estimation, which you can use both for sizing and for valuing. Try any thoughts on this as I switch back to the slider?
Troy Magennis 11:12
No, I think this this covers at all and it’s sometimes you may not have a full complete vision of the data like you may never have cut a pineapple up before. So hence you still have 10 fingers. But you know, this sort of accounts for that because you can know that even though we haven’t done it. It’s it’s got some particular challenges. To cutting it that other fruit doesn’t have. So and it’s low value so maybe we won’t do it now because it’s risky and hard and no no. So a different things that we’re estimating. They don’t all you don’t have to have complete information to make this work you can you will guess better using a 2020 technique than you will get in having to quantify a number.
Joel BC 12:02
Yeah, absolutely. And one of the things I’m going to do on every one and this will be put included in the slide deck. As I’m putting we can chat. This is actually from a mirror template that I’ve created and is available in the mirror versa. You can download this and share it share with your teams. I’m a super big fan of Miro. No I’m not sponsored by Miro. So this is an example of doing this exercise that I teach. I teach my classes all the time. And as you can see here we go from grape to durian and again three and it’s like people don’t even know what durian is. So it’s it’s way out there there in the complexity. And as you can see, basically, as you go through then you start to say, Oh, well you know what, the orange apple and a peach they’re all roughly the same amount of effort from pineapple and coconut or roughly the same amount of effort. So you can use this technique to really quickly go okay, great, how much effort is there in this and again, you can also use this technique, the 2020 technique for deciding value. Bring your stakeholders in, have a conversation when you have multiple stakeholders going on. And on and on. This is my thing, this is my thing. Get them all in a room and go okay, great. Hash it out, have a conversation. And you kind of find that by them getting together and having a conversation, they actually will quite often recognize, oh, you know what Troy’s thing is actually a little bit more important than my thing. So let’s go ahead and give his more value. All right. That said, no matter how good your estimates are, it will all get done. I mean, Troy, I mean, you’ve worked in enough projects over the years. Did you ever get to the point where there was nothing left to do?
Troy Magennis 13:44
No. No, and I mean, it’s sort of it was my sort of planning based on averages. They were always planning intentionally for half of it to not get done. And that sort of pretty much was what what bears out in most, most planning sessions most most sort of industry sort of estimation and forecasting use about half of what you thought you could get, you get that?
Joel BC 14:11
Yeah. And even if your product owners are practicing the, the number one rule that 100 Newberg gives about being a good product owner, practicing, you know, you’re still always going to have more work than anything. And so you have to start making good conversations about Okay, great. Well, what work are we gonna get done? This whole idea of well, if all those are all prior or zero, they all have to get done. It’s like, okay, that’s great. The math says, We can’t get it all done. And even if you add more people, you’re not, you’re not going to get it all done. So what is it that we’re going What are we going to do first? To forecast and capacity planning, basically, to be able to go How much can you do a lot of times you’ve got to also be able to forecast. So there always is going to be more work. Prioritizing does help because then you know that you’re working on the most important things first, the date will almost never change. This is something I’m a huge, huge passionate about. And it’s one of those kinds of mindset shifts that some people in Agile have problems with is the dates never going to change. Agile doesn’t change that if you have to ship in time to be able to make the make the the the shipping date to get product on the loading dock for Best Buy. You can’t go oh well we need two more Sprint’s the dates never going to change. Quality is never going should never change should never change. Therefore the only lever you have left is what are you going to build. And so Okay, great. We have to be done by Keith no matter what. You have to start going up there. What can we have done by June 18. And let’s prioritize the things that are most important. So being able to answer how much can we do is vital.
Let me pop back over to the mural board and I want to show you a technique that I have been using the idea is a story reference for fear the most important thing is do you have work that you’ve already done. If you don’t have work that you’ve already done the work that you have estimated. So maybe use the relative estimation technique and you’ve estimated 10 or 12 big items. Notice I call this reference work over here. The idea here is quite often you’re going to be using this capacity planning out larger pieces of work features or epics depending on what kind of implement implementation of agile you’re using. The idea here is imagine that this reference board the reference work is stuff we’ve already done. We have we have prepared cherries many times we know down pat that at one point, we have prepared durians and jackfruits and we know they’re a heck of a lot of effort. And even though we’ve gotten better at them, they’re just there’s a certain point of diminishing return and we’re never going to get more effective during and the idea here is okay, great. We know how much work we’ve done. How much how much effort this past work we’ve done is in here. I really recommend it actually go don’t just look at past work. Go back and look at it again. Go back and say hey, three months ago, we built this feature. We said it was a five point feature then do we still think it was a five point or was it more or less effort and so you’re gonna read maybe re estimate stuff. And then it allows you to easily go here’s a new piece of work. And you literally just start at the left and you go is a persimmon misspell Yes, the persimmons misspell. Is a persimmon roughly the same amount of effort as a cherry and a great now I’ve gotten no banana maybe because you can kind of just kill it and eat it. But again, preschool students so we need to cut it off. So we’re going to put it about here. Pomegranate. While pomegranate is a whole lot of effort and it’s really messy. There’s a lot of risk involved in serving pomegranates to preschoolers, a papaya you know what? A pie is pretty simple here. Maybe we’ll put it about a banana and then a mangosteen if you don’t know what a mangosteen is, look it up but pretty hard to prepare and probably not something you want to serve because if we look at value, there’s not going to be a high value for it. As you can see, though, it allows you to really quickly estimate new work based off of past work. Now the secret here is then you look back at your past releases and said imagine and I’m just imagine that these reference works. We’re going to call these arbitrarily we’re going to call these feature points instead of story points to feature points. And imagine these are all large chunks of work. We’re going to build a new calendaring app. We’re going to build a new mapping app and the we estimated these and feature points then we go back and we look at our last preferably at least our last three historical feature releases. These are not necessarily going to be Sprint’s like, if you were using unsafe let’s look at our last three PIs and let’s look at how many feature points we delivered in each PII. And so maybe you delivered 25 feature points and then you delivered 30 feature points and then you had a really bad pie and you deliver 15 feature points. And then if we take we go okay, that’s over the last three releases in sec 25 plus 3015. Yes, I’m using a calculator. I did say I was an art major. So we end up with on average, we can deliver 23 feature points per release. We’ve got the stuff as created here we can go Okay, great. 23 feature points. This is 13 plus eight, that’s 21. That’s 24 that’s 28. So we’re only going to be able to deliver two or three of these items based on our current capacity. So that’s using historical reference, a story reference board, and then looking also at your historical velocity in a good way to go. How much effort do we think we can do? That’s on this technique, Troy.
Troy Magennis 20:51
I think I think He covered it well, I mean, the important message on factor that came out of this was that you’re not going to get one of them. It’s the first thing you’re not going to get which is the valuable thing to understand because from knowing that you’re not going to get that the consequences of that can be assessed and you can might be able to trim the other features down to not to get a bit of all four rather than just missing one completely. So it’s, you know, often I find that forecasting estimations about what can get done. I think if you reverse the question around and sort of saying what is the first thing we’re unlikely to get? You tend to be able to work with the business on alternative approaches to get a little bit more of what you want. So I look at this for a most interesting thing to learn is the first thing you’re not going to get not the free things you aren’t going to get
Joel BC 21:42
you know i i love that mindset. I don’t think I’ve ever really thought of it quite that way of the let’s start with what you’re not going to get in Are you okay with that? And if if not, what are we going to do about that?
Troy Magennis 21:53
Well, that’s eventually what happens anyway. Right. And then as you get closer to near the end of it, the discussions turned to OMG we’re not going to get sort of that new song from Brittany. Like, like, I don’t know, sort of what there is there and what the cool kids would say as a metaphor. But there’s the the fact is, is that the way software tends to work in constraints, and especially the tension between development and business, is that why didn’t you tell me earlier that I wasn’t gonna get this and what forecasting capacity planning gets you even if it doesn’t get you a perfectly accurate result? It gets you an earlier conversation when you’re not under the stress of failure.
Joel BC 22:36
So again, I used this technique a few years ago when I worked on pre COVID. I worked on for the BMW connected car group in Chicago. And it actually did lead to whole conversations which included the look this this is just not good enough. We need to be able to deliver more in a quarter. What do we need to do? And then that got went into a whole whole series of math. So just how many teams do we have to add to be able to actually radically improve our capacity in the next two months? And there we stepped into whole mythical man month lala land and the fact that they had two teams and a whole nother podcast for another day is they realized that they would have to add six more teams to the two teams they had in order to increase their capacity by by 50% because of the fact that it would take so long for teams to come up to speed and all of that. All right. One thing I will promise everybody is what I just did that the capacity stuff and talking about the feature points on the mural board, I will make sure to drop that slide in here. I forgot to put a an example of that slide here on the deck so you’ll have it for reference when we send out the deck. At this point though. Well, I really love doing this for a reference boards and it’s really easy to do. It is still being ultimately it is still based on the human gut and the human brain and such and we’re fallible. I mean, just like we’re not good at estimating time. We’re not good at doing doing doing hard math problems. And some of us even with a calculator. And so what I want to do at this point is literally I want to I want to invite Troy to come forward. And I want to invite Troy to come forward. I’m going to stop sharing. Troy doesn’t have slides. He’s actually just going to show you the tools that he he’s developed that he’s using with people today to help them to do better estimation to get help them to answer that question, how much can we do in X amount of time? So let me stop sharing. And I think Troy, you you should be able to share no problem. And you’re on mute again.
Troy Magennis 24:49
That was intentional. was like if you believe that you believe in anything. So that’s why the consultants wrote I can make an excuse for anything. I got a couple of I got a top drawer of tools and articles and stuff I’ve written over over many sort of MIDI sort of years. And the links will be put in the chat window and but they come about because I find myself constantly having to introduce people to just how hard this stuff may well be to get accurate right because I mean if you think of how long it’s gonna take you to get to the airport. You know the distance and you know, roughly sort of when your flight takes off, but you’re actually forecasting not when the flight takes off, you’re forecasting when you need to leave home. And that is the true value of of sort of forecasting and estimating. It’s about knowing when to start something not knowing when something’s finished, because you can get anything finished by any date you want. If you start early enough, so we don’t have a forecasting the finishing date problem. We have a forecasting the start date problem, and we tend to where do we spend all of our time we spend all of our time estimating the done date. Well, you know, I think that every other field that is managed to delve into forecasting of uncertainty works out when you need to be somewhere when you need to arrive somewhere and then works backwards about whether you’re likely to make that or not. So if you’re looking at Google Maps, for instance, you know, as you’re driving, it’s constantly updating the time you go into arrive. But you can also set a it’ll tell you if you if it I mean Google being sort of Bay as a private data, they know your inbox, sort of when your flights gonna take off so it says you ever left home yet you loser, you should leave. And that’s what they’ve done is and I find that from executive sort of world when we try to try and put pressure onto teams and people to finish something by a certain date. We don’t equally put pressure on ourselves for making sure we allow teams to start at a certain date. So there’s one aspect of it. Secondly, is I’m going to introduce the left side is word Monte Carlo forecasting. So I have an article for that here which has a bit of a bit of a guide. It even looks geeky. Now, this isn’t my back period. I’ve grown up since then. But you know, traditionally what we do in Agile is we just do these burndown charts right? We work out that we need 25 points of work done. And we roughly deliver, you know, maybe four points on average this as my team’s not Joel’s notice he’s in the 10s either befores right. It’s a strange sort of division operator of the total amount of work so if the total amount of work goes up, so does how many Sprint’s it takes to deliver that work? And this is all perfectly well and good and fine and logical, as long as 35 is an exact number, and five is the exact number. So we need perfect estimates for the total work we want to do and the pace that we normally deliver that work. He can’t that’s not logical, right? We know that there’s variability that points are going to be added and taken away as we sort of refined scope and we know that the team’s velocity isn’t exactly five. So we throw in this thing called an average. And the moment we do that, remember at an average, roughly half of the things sprints get more than that, and half of the Sprint’s get less than that. So the probability of delivering in seven sprints using the typical burndown charts is 50%. You had a coin toss chance of your work being late or being on time. And in many fields, some of the medical, that’s not a good enough margin of error. You got a 50% chance of surviving surgery isn’t something that sort of fills you with competence in theory you probably would be a bit more nervous than you need to be asked to we should when we’re making multimillion dollar investments in software projects. So all we do is we give ourselves the ability to do mathematics with uncertain numbers. So rather than the fixed 25 points, we say between 20 and 30 points, rather than delivery pace between one and five points, we were being exactly sort of one or five points, or three points. We can sort of say delivery pays very somewhere between one and five points or stories per sprint, do the math that you want. And then we hypothetically do a burndown starting off at a random number between the total work range, then decrement and every hypothetical sprint by a random number between one and five and once you do and remember, this is what invented weapons of mass destruction in nuclear weapons. They needed to find a way to understand uncertainty during that sort of period of Manhattan Project to understand how much lead shielding was necessary to not sort of make the nuclear weapons safe to transport. There’s no fixed number of the way sort of Uranium decays, it has a rate that varies and the same thing about sort of resulted in different materials. And what they did there is the same thing as we’re doing here rather than hypothetical burn downs or software projects. They sort of did the amount of protons and electrons, neutrons that actually did sort of a lead shielding, but the point is, all this whole big convoluted term called Monte Carlo forecasting or probabilistic forecasting is, is a way of exploring and doing mathematics on ranges of numbers. So this all this is solving is 20 to 30 divided by one to five. Nothing more complex than that. It’s it’s if you say it doesn’t work, it’s like saying the addition operator or the division operator don’t work. It’s just a mathematical process. But what it gives us is unfortunately, it gives us or fortunately whichever way you look at it sort of says the value could be you could be finished it in five sprints, or you could be finished it in 15 sprints. Great way to get fired because little people love nothing more than to sort of say sometime in 2023 or 2020 Settled we don’t know which yet. And so, although what Monte Carlo analysis to do is explore the possibilities of what could happen given uncertainty in our world. It leaves us unsatisfied with the understanding of what we’ve got, but this is a goldmine. Because what we can do is we can turn that into a number remember I said the typical Bernanke has a 15% chance of forecasting, so it might be above nine weeks, or it might be below nine weeks with a 50 50% chance. What we can do now that we have a set of results is we can drag the probability slider up and sort of say 95% certain that will be finished in 12. weeks on this. So by incorporating uncertainty into the mathematical operation, what it allows us to do is delve into the probabilities that something’s going to happen all before a certain date. And if you’re one of those pointy haired boss executives, which once again a bit more certainty in understanding when things are going to be done, this is a useful tool. But yeah, if you go and pick up jobs calculator right now, it doesn’t have a one to five divided by that so 25 to 35 divided by one to five, it does add that button, and it seems like my head’s exploding. So part of what I sort of did there in the early days there was I created a couple of spreadsheets which just do this for you. And there’s no code in these spreadsheets. They’re plain old. They’re plain old spreadsheets. Yep. And you know, it does the same thing. 20 to 25. Estimate. Well, roughly between we’re gonna get between one and 10 things done per sprint, most likely three, edit will convert that into a how many, how many weeks or how many Sprint’s that you want to, you’re likely to deliver in and you can read off the off the likely with you at five cents 30 cents a page spreads. So you give yourself extra margin of error by
Troy Magennis 34:17
accurately portraying the uncertainty that exists in your project and your product. And that’s sort of what this does, but you can go one step further, rather than just estimating the pace that you’re doing. You can come in here and you can put actual historical velocities or samples, as Joel said, the last three or four sort of spreads. You can put those in instead of your estimates. And then you can sort of drop down here and just sort of say go and use the historical data or is that what the historical data shows is that we’re moving a bit slower than what we originally estimated we were going to be moving. Very valuable to know while you can still do something about it, and that’s the point I want to make that these forecasts are best done early and continuously, not just done early, come up with a date, and then sort of say a few, they got that stuff. But I don’t want you to use this spreadsheet. So this this sort of mimics the way we’re currently working. I want you to think about forecasting in the way that sort of Joel sort of was saying there before is that, pick a target date. Come up with a set of features particularly focus on the weather, we really understand this work or we don’t understand his work. And then discuss the first feature that you’re not going to get with your business owners. So focus on what you’re not going to get and then what they might sort of say, well well feature three is going to miss OMG. We need feature three, and then you sort of say well, which feature would you like to sacrifice? feature one, feature two, because we can start feature three and make sure you absolutely get that but we can’t do that and get all three. So what you’ve done now you’ve guaranteed that you get feature three, but you put feature one and two at risk. And then you might say, do we need all feature three? And they sort of say Well, no, not really. We just need the first sort of five and eight stories or points in that. Well that changes the picture dramatically. So what we’re trying to do in forecasting is never say no, we’re trying to provide options to getting more yeses earlier before it becomes a tragedy. And yeah, with that, I guess if you had to pick if I had to give you leave you with one takeaway of what blows up forecasts, it’s not the story point estimates. It’s never the story point estimates. It’s that the team doesn’t get the focus on this work. They only 50% of this work that changes the what you’re not going to get quite dramatically at this start date is something that we invented on paper. Any start date is the beginning of a month or a quarter is BS by default, because you do not know that the team immediately rolls off a prior piece of work onto this new piece of work exactly on that start date. So start date and the team focus on the work of the two things I think you need to you need to pay attention to more than your estimates of size of points. Because what you will find and you can do your own experiments on this a 10% change in or even if it wasn’t changing these points, does not have the same impact as a 50 cent change on the team focus or the work or the start date. They have a much less impact. But we were making up all of spending time where it’s not well spent. Alright. So with that, I know where we’re happy to take questions and hand it back over to you.
Joel BC 38:09
Yeah, thanks, Troy. So I think a couple of things I want to point out how I call out from what Troy shared first off he is on Troy’s little thing about the percentage of the team capacity. You’ll notice it didn’t have anything above 100%. I talked about I talked I made a post about this recently on LinkedIn. It’s a bad dad dad’s drug I have it’s the what do you call a team that’s out? 100 What do you call a freeway that’s at 100% capacity? Los Angeles, a parking lot. Yes, Los Angeles. What do you call a freeway that is at 150% capacity? A traffic accident. You can’t you can’t say oh, the team’s gonna work at 120% No, you can’t. There is no 120% that doesn’t exist. The one other question I had free choice just so we talked about the historical data as I understand it, if they want to go and move their historical data up even another notch, move beyond estimates and introduce and then look, instead of looking at historical cycle time, what is the cycle time that it took to complete past stories? Correct. And that’ll get them even more accuracy?
Troy Magennis 39:34
Or more accuracy that it answers a slightly different question. I mean, the idea of cyclotron really is is that if you haven’t started by a certain period of time, historically, things have taken longer than this to do. So it’s again the out of the matter of time to travel to the airport or you commute to work when we used to do such things. You roughly knew, depending on the first meeting you had when you left home to give yourself sort of some extra leeway of getting through traffic and getting through weather disruptions and accidents and so forth. But you can’t avoid all accidents. Sometimes they happen and there’s nothing you can do about it. Sometimes they close bridges, sometimes they close freeway. So you know what cycle time gives you is the ability to sort of say this piece of work. I need to start all over for what Monte Carlo forecasting gives you the ability to sort of say, out of all these things I’ve got to do. I could get many of these, but I don’t know which ones yet. So cyclotide gets you down to an item level and forecasting gets you keeps you at that aggregate level of this is the size back and I can deliver in this period of time. Choose wisely grasshopper and we need to keep the two perspectives in mind. So not more accurate, just more granular.
Joel BC 40:50
All right, good. Good. Good clarification. So folks, do you have any questions for myself? Or Troy about estimation forecasting capacity planning keep an eye on the q&a. How can people find out more about what to do? I know you put some stuff into into chat Troy but I know you teach you teach workshops on this on a regular basis right.
Troy Magennis 41:18
Yeah, I mean there there’s some public workshops you can do this stuff tends to be a bit more of it get called in when there’s a crisis to be honest, when I get caught and I you know, we were terrible at estimating and forecasting and it turns out that, you know, of course, they’re they were set up to bell before they begin. So I tend to do a lot of internal workshops on on forecasting, but it turns out never to be the teams that always turns out to be the types of questions that they’re being asked or unreasonable, because it varies, right I mean, if all this historical data is well and good, as long as you’ve done similar work before, if you change developer frameworks, or you say Elon Musk takes over your company, it doesn’t matter what your prior velocity was when people say to your staff has gone bye bye. It doesn’t matter how many people you could do on their, their chat system or their their live system, when the team that would use to deliver that is now God, right? So we need to understand when we throw data away, and when we destroy the system’s ability to be able to be forecasted. So I tend to help organizations understand why it doesn’t matter what history says they could do, they can no longer do that more system approach to to understanding probability.
Laura Caldie 42:46
All right, no, I do have one comment. I was hoping to make that I just appreciate both of you kind of bringing this to light is incorporating the conversation around value and what won’t be done, as well as what can be done and what the team can deliver. And I think you know, when you’re thinking about estimation there, it sounds like it’s a one dimensional conversation, but it’s not it’s multi dimensional, and time and value and market needs and stakeholder requirements and the fact that things change, right means that when you’re when you’re looking at it from a multi dimensional conversation with more actors involved, you end up getting a better result at the end, which ultimately, what we all want to do is deliver high quality solutions that have a lot of value to our customers. So I appreciate what you’re getting at which is it’s a it’s a multi dimensional effort, and there’s a lot of benefit that comes out of it from doing it. Well.
Troy Magennis 43:51
We like to we like to make out of this as if there’s a simple answer to these problems and there’s just not right I mean, these these are so complex though, that uh, how many icons you put on a zero diagram in your framework. It’s, it’s a complex world we need to live in. So stop looking for simple answers to these problems.
Joel BC 44:11
So thank you try. So if you’re if you’re, again, if you’re deep into this, and you’re trying to figure out how to figure out where are you going, how long is it gonna take you to get there in everything called culture, right? That’s what he does, especially if you’re trying to set stuff up to get going from the beginning for success. One of the things I would like to recommend is consider coming to one of my certified scrum master or certified product owner workshops. One of the things that I really pride myself on it, let’s start with why why does this stuff work so that you can set it up the right place? If people just say go do a daily Scrum and you don’t know why you’re going to get into the problems that are going to make it to the you have to call Troy? Six months from now. Come to one of my classes hopefully you can avoid having to call call Troy in a panic instead called Troy because you just want to get better. Laura, can you really quickly connect this also then up to software profit streams and why should we care about software products?
Laura Caldie 45:06
But I think what people are thinking about again, building high quality solutions for customers is a multi dimensional multidisciplinary effort. And so I think what you’re talking about is a very collaborative approach to building and quality and building and value. And one of the things that we’re adding to the conversation from applied frameworks is how do we build in profitability? So thinking about the value stream as a profit stream makes a lot of sense for companies that are building software enabled solutions that end up in the hands of customers who pay money for them. So thinking about designing and profitability, again, is a systems thinking exercise. Because it impacts architecture, it impacts pricing and licensing and customer ROI and solution ROI. And so applied frameworks has added into the conversation, a book called Software profit streams, written by Jason Tanner and Luke Hohmann. And we find that people who love this Certified Scrum profit as Certified Scrum Product Owner course will evolve into wanting to think about what’s the Profit System that I’m building in my solution. And so we have training courses and blog posts and webinars that talk about profit streams. So hopefully that wasn’t too long of an explanation. But I think it it gets at what we all care deeply about, which is let’s understand the system that we’re impacting. There are no black and white simple kind of answers to things when we’re building systems for customers. And if we keep that in mind and use the tools that help us reason about what we’re building, and I think we end up delivering higher quality solutions to our customers.
Joel BC 46:49
So absolutely, what I want to do is I want to leave you with three quotes. To tie this all together. The first is from Simon Sinek, the author of start with why and several other great books, people don’t buy what you do they buy why you do it. The next is from a TIF and I’m realizing that I posted this I can miss miss his last name. I think it’s a TIF Rafiq is the author of a book called decision sprint, multiple Chief Digital Officer multiple times chief digital officer, and he talks about the days of Blink check innovation are over. You can’t just build for innovation sake. And then lastly, Luke Hohmann, author of software profit streams, it’s no longer enough to deliver value you have to deliver profit. So thank you very much. I’m Joel Benko Connors the gorilla coach Troy thank you so very much and Laura thank you to play framework for hosting us such a wonderful webinar.
Laura Caldie 47:37
Appreciate you both and thanks everyone for joining Thank you
Don’t Miss this great webinar!
Are you interested in learning more? Please contact us to learn more about how our consultants can help your organization align around profit.
