 First I would like to thank you all for coming along to my session. My name's Mike King and I've got a bit of a cough. I'm depending on where you work and who you are, and what you do, I can be called a project manager, product manager, a delivery manager or something along those lines. Effectively what I try and do is make sure The end user gets a lovable product. I've been working in the web industries for, well, since about 1995, managing projects and teams since about the year 2000. So I've been doing it for a little while. Wanted to initially establish what an estimate is. There's a little definition for you. It's a rough calculation or judgment regarding the value, number, quantity, or extent of something. Now, what that something is that you're calculating or judging, it depends based on exactly what you're doing. But all in all, it feels a bit brittle. It feels like it's a guess. It feels like something that's not really based on too much science. And in my eyes, that's not great. Can I just do a quick stand-up poll, if everyone's happy standing up, that is, to see who uses estimates and how they're used. Could you all stand up or at least put your hands up? OK, that's good. If you're not happy standing or not able to, just put your hands up. Yeah, OK, good. So now, if everyone can leave their hands up, put your hand down if, sorry, that wasn't an instruction. Put your hand down if you estimate between 0 and 50% of your cards, your features, your tickets, whatever you do. So somewhere between 0 and 50% of the stuff that you complete in your teams or your daily work. Not many hands went down there, OK. OK, so if you have 10 things that you're doing in a day, do you have to estimate all of those things to figure out what you're going to do? Do you estimate none of them? Do you estimate some of them? So I'm asking if you estimate up to five of them out of those 10, then you put your hand down. If you estimate, so less than, between 0 and 50, yeah. So if you estimate more than 50% of your cards, your features, the work that you complete on a daily basis, put your hand down, that's everybody. OK, so what I want to try and figure out is everybody uses estimates, but we need to find out why they don't always work. And in my eyes, they definitely don't work. So they're broken. I'm not the only person who thinks that. Another quote, or a quote for you, estimating tasks will slow you down, don't do it. And that's from someone who people might recognise called Jeff Sutherland. He's the co-creator of Scrum. And if he thinks that estimates are kind of broken and they're not really good for you, then I'm going to listen as well. So the next part of this session will take into account as all good clickbait articles should, a top three or a top five, but I couldn't fit five into the time we've got. So we go with the top three. We go with the top three issues for estimation. They're harmful and personal. And I apologise immediately because I said I was going to have a top three and the first one's got two points. But we'll keep going. Estimates are harmful because they build a bridge back into the non-agile development world. So we know that in an agile situation, we need to make sure that we're working to a fixed budget and a fixed time frame and we flex our scope. Estimating what we can get done in a certain amount of time takes us back to the world prior to agile or prior to projects that we're using in agile, where we're estimating everything. We're saying what will be done in that time and for that budget. That's why they're harmful and they're personal because in my experience, a lot of the time, people are given estimates as a fate to complete as to how long it will take them to do a piece of work. They didn't necessarily estimate how long it would take. And even if they did, they didn't estimate with the right information. I'm sure everyone's been in this situation where they've got, let's say, it's our mythical 10 cards, our 10 features that have gone into a sprint or being planned for a sprint. And you've estimated each of them and you've given them each a single figure to say this is how long it will take and then you add all those figures together and you say this is how long this whole sprint will take or how many things we can get done in this sprint. That's great for estimation. It's really good. But if you look at a single figure estimate per card, you find that it gives you a binary situation. So if you have a feature and you say that there is one point in time up to where it's successful to be completed, if it's a one-day feature and you say, yeah, okay, it's going to take us one day to do this, if you complete it in anything more than one day, it's a failure. If you complete it prior to that, it's successful. It's a binary outcome. It feels very much like flipping a coin. So you have a 50-50 chance whether or not your estimate is going to be achievable. And this issue is compounded when you add all of those together. So your 50-50 chance for flipping a coin completing your estimated item on time is compounded by the number of times that you add those chances together. So it's a bit like instead of having to flip head once to complete your estimate or complete your card within your estimated time, you have to flip your coin 10 times and get heads 10 times in a row. I'm not sure if anyone is mathematically brained enough to figure the odds of that one out, but it's just over 1,000 to one. Does that feel like something that you want to stand by when you're completing a project? You say, yep, we've got a 1,000 to one odds that we will complete this on time? No. In fact, if you said to the person you were giving these numbers to, you give them to you right now, that there's a 50-50 chance that you might not meet the estimate, would they be happy? And estimates, most importantly for me in this one and it's probably the simplest to illustrate, estimates are incomplete. They don't include such things as context switching. Studies indicate that every time we change context from one subject matter to another, let's say for example changing from one feature or working on one card to working on a different one, we lose approximately 25 minutes of quality working time. If you're somebody working in support, and I can see a few out in the audience, you may be context switching three or four times a day. Think of the amount of time that you're losing there and estimates don't include these switches. So if you fill up your sprint, if you fill up your iteration completely with cards or with features, you won't take into account the fact that you're losing time every time you context switch. They don't include waiting time. Okay, I'm gonna work on this card but the person who's working on it prior to me has run over, so I'm waiting. That's lost time, it's dead time, it's not included in the estimates. Debugging time. Do your estimates include some time for debugging, a lot of time for debugging? Do you pad your estimate? If you're padding your estimate, it's no longer an estimate. This didn't understand the problem problems. When you estimated the issue, you were told it one way or you read it one way. When you came to fix the issue or create the new product, you read it a different way. So you didn't understand the problem the first time you looked at it. Holidays. Now holidays are kind of okay in a way because you can see when somebody's got leave booked but there are often times when people need to take emergency leave. That can't be included in estimates and the time that's available in your team. I don't know many teams who don't suffer from this problem who have urgent work that pops up. So they're working away, they have a sprint, all of a sudden a site's down, an app's down, something's gone wrong. They have to go and work on it. That time is lost, it's not included in your estimates. Broken computers, this happens very often. It could be a server, it could be someone's laptop, it could be your development environment, it could be anything, it could be a third party API. If it's broken, it's not included in the estimate. You get the idea, I think, really, technical debt. Something that we can't really judge for because we don't know every line of code and exactly what we're going to want to do with it. Cuing, it's an interesting one that the more items you have waiting to complete, the longer it takes to complete the item you're doing. There's a whole nother session about queuing theory, but the fewer things that you're being asked to do mean that you take less time because of the mental queuing and the mental capacity that you have to store the information about what you have to do. Building a release. I know some people, when they're looking at iterations and looking at sprints, do you have a particular card for building a release? Maybe that's one release per sprint. What if you want to do five or six? What if you were to do 10 a day in continuous integration? You should have cheap releases being built, but is that factored into your estimates? What if one goes wrong? Refacturing along the same lines as technical debt. Solutionaring is one of my favourites. So it's possible that you didn't understand the problem, so now you're going to have to sit down with the team and solution something. You've got to now dig up an idea from nowhere to solve this problem still within a finite amount of time. Sickness is the obvious sister of holidays, but it is completely unpredictable. And there are more, but this is my list. So I say don't estimate, forecast. Let's not give single figures. Let's start talking about ranges of possibilities. If you come to the boff tomorrow, if anyone's interested, we can see that graph working and create your own version of that. So what is a forecast? We'll do the same treatment to this that we did to the word estimate or an estimate the first time round. Already we're seeing the words calculation and prediction based on analysis. It feels more scientific to me, at least. It feels like something that you might rely on. So let's work through our list, our clickbait article, top three, and compare estimates to forecasting. Estimates we saw were harmful and personal. Well, forecasting is agile. Forecasting, as we mentioned or as I mentioned earlier, excludes the fact that you're estimating exactly what needs to be done and when it's going to be done and how long it's going to take. What we're using is evidence based on the past experiences or recent experiences of the team to suggest what might happen. So you can start giving a range to say, yeah, we're sure we can get this amount of work done, but if we change scope or if we change the level of value that we're delivering, we might be able to get more done. And it's evidence based rather than being personal because we're using recent evidence from the team. Estimates for binary and compound, whereas forecasting is based on a probability. It's not a promise. We don't give people a single figure and say, here we go, that's our success or failure point. That's our winning line. We might tell them that there's an 85% chance of an outcome, a bit like a weather forecast. So you could say there's a 23% chance of rain. You don't expect every time for there to be rain, you expect there to be a 23% chance of rain. So in our case, we're saying an 85% chance of successfully completing the cards we have in our sprint. The other good thing about a forecast in this instance is that it's updated every day. So it's updated based on the evidence that we've had over the few days of the sprint as well as the previous days, whereas an estimate wouldn't be updated because it would be too expensive to do so. And I won't go through the list again, but whereas an estimate excluded all of the items on that list previously, forecasting can't help but include them, or at least includes the recent patterns of them. You're still going to fall foul of a stomach bug that brings down your whole team. You're never going to get away from that, and that's not predictable at all, but at least you'll be able to get closer to reality. Whenever I start talking to people about this, one of the things that they say is, well, this sounds perfect. It sounds really, really great, but it won't work for us because we have different size cards. We have big tasks coming through our queue. We have small tasks coming through our queue. So how can you predict these things when we can't even predict the size of the work? And my response normally is that we have to go back to one of the core tenets of Agile, and pretty much one of the first things I ever learnt about Agile, about sizing cards and effectively levelling the flow of the incoming work. It's a lean tenet hijunker, as you can see there. If we make sure that all of the, or as many of the cards as possible are of a similar size, it becomes much more easy to predict and to see the flow happening. So if we level the flow of the work coming in, it'll be more predictable going through the system as well as forecastable. Whenever I go to a session, I love to have a take home, something that I can at least get started with if not used straight away. And I wanted to give everybody here something like that. Who uses Fibonacci numbers in their estimates? Lots of hands, great, good stuff. Fibonacci numbers have built-in uncertainty. So the larger the Fibonacci number, oh, here we go, look, we can see the numbers here, there are a few numbers, the larger the number, the more uncertain you are because the larger the gap between the numbers that you're able to use. So for example, the gaps between those numbers increase. So what you can start doing instead of telling people that, okay, the estimate will take eight days or eight units. I don't know if people use story points or hours or days or whatever, it really doesn't matter. If you estimate eight, you could say to them, but if we'd make some changes, we could do it in five. So you give them a range of possibilities. You can say it could be five between five and eight units, days, hours, weeks, whatever. So that's a simple way to get started with forecasting. If you want a more in-depth way of getting started with forecasting, we've got a boff tomorrow. I've got the details on that in a minute. So tomorrow, 10.45 in gallery 13-14, there are a bunch of open source tools that allow you to start forecasting really, really easily and very quickly. So any previous evidence and you'll be able to get going straight away. Feedback is really important to all the speakers so if you would be so kind as to head to that bitly link, it will take you straight to the session page on Drupal Events and if you could leave feedback, that would be wonderful. And also please attend the Friday Sprints. They're very important to keeping us where we are. There's a bit of a reading list here. These are the things, the books that I've gleaned a lot of this information from. The lean side of things, obviously this is lean, give you a lot more information around that efficiency paradox, how centering and focusing on the flow of work going through your business or your chain is really important and not to focus on people being 100% utilised all the time. Okay, so I should have another slide with questions, but that's it. So if you have any questions, please feel free to step up to the microphone and please make sure you use the microphone for the recording. I must have given you all the information you need. So if you have any more questions or if you want to talk about it in more detail because it's a bit of a different way to look at things then the boff will be the place to do it, but we have one question. Yeah, just a little funny story. I think Dave, before you said that, I went with a taxi and I asked him how long would it take and he said 40 minutes unless there's a traffic jam. I guess that would be a forecast and not an estimate. Yes, so he's given you a forecast range, absolutely. Yeah, that was good. I was happy about that because if he would have missed like the 40 minutes, it would have been more than he would have had the excuse already or he built in the estimate. That's it. So if you look at something like Google Maps, if you try and get a route for a, or if you try and get a timing for a busy route, it might give you between one and four hours because the evidence is that people have taken that long. Yeah. Thank you. It's a really, really good talk. We also struggle with estimates. I really like the idea of the range. Sounds a really good concept. I was just wondering if you had any thoughts or examples on how that's worked with clients, whether they're receptive to that or you give them a range low, medium to high and let's say it comes back at the top end, how they react to that. I suppose it comes back to again that idea of talking to the client every day and updating the forecast all the time. So if you've got evidence from the day previously, you plug it into your forecast generator and you keep that information updated and you keep showing it to the client. So there's no surprises. You'll never get to the end of your sprint and go, well, hang on, we're at the high end because they'll have known that from the day or the second day of the sprint that they'll be able to see how progress is going. It's a bit like velocity in some ways, but it's forecast driven rather than just the immediate evidence. Okay. Both term estimate and the other one? Forecast, yeah. They still have this idea that you have a task and this task takes some time or some cost and this is in the end the cost of the project is the cost of the tasks and then add up. But sometimes there's a cost that is not specific to a task. The refactoring sometimes doesn't belong to a specific task. You could do it in one task or you could do it in another task. So it's like if you sell ice cream and someone could ask you, how much does it cost you to make this one ice cream? And of course it's a stupid question because you also have to pay the shop and everything. Yeah, I think these items are the hidden costs. So you would have to make a percentage on top of each forecast? No, no, absolutely not because these hidden costs are included in your forecast. You're not looking and saying how long did it take me to do the specific card or the work on the card itself. You're saying this one item of work took an amount of time to complete and that includes the fact that you had to build a release and someone was off sick and we had to debug some other bits and pieces. So that's packaged into your forecast. Okay, there's really nothing to do with a task. If you have a short distance to go with a car but you also need to refuel the car which maybe takes a lot more time than just the short distance and it's not really related to this one trip but it's still part of the build or the cost. Yeah, so if we get away from the idea of cards and features then we're actually talking about delivering value. So don't worry about the card, worry about the value. How long did it take to deliver this value? Yeah? Are you sure? I'm not a native English speaker, so differentiating between estimates and forecasting, I don't really see it. All the estimates, all the points you're making there, I would put that into estimates but the thing I'm missing from what you're talking about here is who and what are we doing it for? Is it for before we do the project to sort of size the team we need? Is it for the customer ahead of time so they know roughly? Like have an estimate of how much money to spend on this project? Is it during sprints? And I don't think we can forecast the project ahead of time so we do need estimates. And if I say the project or a customer comes with a project, then I mean sickness and holidays and so on, I mean there are certain things that I can factor in. I think it becomes more conceptual so it takes it away from looking at the particular features of a project. Sorry. And it effectively says, instead of worrying about the detail, instead of worrying about every single item and estimating it, you say on a whole, how long does it take us to do projects? Projects of all sizes, but most businesses work on projects of a similar size because that's where their market is. If they're a small outfit, maybe they're working on smaller projects. Yeah, generally. Yeah, so this is the assumption that we're saying, smaller teams, smaller projects, or if not, it's a longer project. But you're estimating, sorry. We've forecast, yeah, I know you've caught me, sorry. We're forecasting based on very little knowledge, but you can forecast based on prior experiences. So without seeing what the project is, you can still guess how long it will take. You can say with certainty, with a 50%, 70%, 85% certainty, this project will be finished in three, six, nine months. I don't know what the scales are, but just with somebody coming to you, you can say a project will be done in nine months. That's your first forecast. But without calling it, thinking about estimates and forecasting, I think like a seasoned senior project manager would probably say, oh, we've done this a million times. It'll take you six months. I know exactly how this goes. And you land somewhere around like five months and two weeks and six months and two weeks. But for maybe an unexperienced project manager, it's super hard. I can only second what you're saying. Let's all go to the buff and learn about forecasting, especially the ones who are struggling with estimates. Thank you. OK, if there are no further questions, then thank you very much and hopefully see you at the buff tomorrow.