How To Estimate Software Development Time

have you ever been part of a conversation like this so we've got a great job for you it's a simple change the hardware is mostly already in place you know all of those old telephone boxes that no one ever uses anymore well we want you to write some software so that instead of a phone call when you dial the number it will teleport you to the box with that number it's a great idea isn't it easy so how long will it take can you have it ready for next wednesday okay so i've exaggerated a tiny bit but that question how long will it take is always a tough one to answer even when you don't need to invent new physics so should we answer it at all and if we do how do we answer it how should we approach software [Music] estimation hi i'm dave farley of continuous delivery welcome to my channel if you haven't already please do hit subscribe and if you enjoy the video click like at the end too let me start by thanking our new channel sponsors harness and equal experts their support is going to help the channel to grow check them out in the description below also check out my new training course get going with continuous delivery pipelines in this episode i want to explore estimation the bane of a software developer's life i should begin by saying that i don't really believe in estimates and neither should you i subscribe to the idea that where possible it's best to avoid them and instead to work as efficiently as possible in small steps so that our software is always releasable after every small change this is one version of something that is sometimes referred to as hashtag no estimates this i think is the most efficient approach for a good team it does rely though on the people who pay the bills trusting the people doing the work relying on them to be focused diligent and working as efficiently as they can on the stuff that really matters and it relies on the people doing the work to stay focused on the stuff that really needs to be done and that really matters avoiding getting sidetracked by things that they'd write they'd like to do versus the things that bring them closer to the organizational goals practically though i'm not entirely sure that you can start from this position let's try to unpick this a little bit the obvious starting point that most organizations ask for is accuracy wouldn't it be great if when you asked me to do something anything i could tell you exactly what i'd need to do to get there and exactly how long it would take it would make planning much easier if it's something as simple as making coffee i can give you a pretty accurate estimate based on the physics of boiling water and importantly my practical experience of making a lot of coffee but even for something as simple as this first we have to agree what when you ask me for a cup of coffee you really mean is it instant filtered or do i need to grind the beans from scratch so that it's perfectly fresh even for something as seemingly this simple it's important that we are clear about what our assumptions are for the target and that clarity is not always an easy thing to establish the more complex the system the less likely it is that we're going to be certain about what the target should be unfortunately as soon as we step outside of something as simple as making coffee predicting the future gets a lot more difficult in previous videos i've said that perfect plans are a perfectly stupid idea and they are so what would a perfect plan mean in this context well first we need to understand the goal rather like our coffee we need to precisely specify what our expectations were and that's probably a rather unrealistic for any seriously complicated system next we need to know all of the steps necessary to achieve that goal breaking down the solution of the problem into all of the activities that are likely to take place again that's kind of unrealistic because software development is an act of discovery and we're going to be exploring as we go and learning new things and adapting to the things that we learn then we have to know how long each step will take and that again pushes us into the realm of uncertainty have we done this kind of thing before have we used these technologies before has this team worked together before do are we depending on some other team for some help all of those sorts of things are going to have an impact on our ability to make this prediction and if our plan is going to be accurate perfectly accurate then we'll also we'd also need to predict all of the interruptions that are likely to affect us along the way the problem is is that we if we are building a software system then we know none of these things and there's a lot more than that that we don't know who's going to work on it how will the tech work out if we are trying something new and so on and so on so when we're asked to estimate something the truth is that estimate is just a fancy word for let's guess about the future if we've done something exactly like this before then why are we doing it again it's software we can reproduce it for free if we are solving a new problem and then we should always by definition be solving a new problem in some kind of context then we don't know what is involved the data on estimation is interesting i first read about this stuff from a great book in the not published in the 1990s called rapid development written by steve mcconnell who was working at microsoft then it doesn't matter how diligent or thorough you are in your approach to estimation the data says that the error bands for the estimate are roughly the same whether you're doing a detailed function point analysis breakdown or a finger in the air guess about your they are about as accurate as each other when you look at the data the point at which any estimate we can tell whether it's accurate or not is the point at which the project is finished so that's not terribly helpful at the start of a project on average the guess that you make at this point is out by a factor of four inevitably we nearly always underestimate so it's nearly four times as big so the obvious solution then is why don't we multiply all of our guesses by four the trouble is that no one will buy or even begin a project when you give that estimate so what many organizations do next is to confuse accuracy with precision these are not the same things as an example i can say that pi is 3 is a more accurate statement than saying that it is 17 and that's correct it is more accurate saying that pi is 3.14 is more precise and more accurate than saying that it's three but saying that pi is 17.630231 is more precise than saying that it is 3.14 but it's less accurate so what many organizations do when faced with the problem of estimation is they focus on trying to increase the precision of the estimation while losing sight of accuracy this gets into what my friend dan north once called the infinite fractal coastline of estimation the more detail with which you examine the problem that you're trying to estimate the more you see and so the bigger the problem looks the other aspect of accuracy versus precision is understanding the level of precision that makes sense in the context of our estimates the error bounds are important and depend very much on the reason for your estimation if you're trying to estimate a big project to sell it to a client maybe or to raise the budget within a large organization that's a very different kind of thing to estimating a few stories for the next sprint if you are looking to estimate something big i recommend that you read the estimation chapter in rapid development it's an old book and some of it's dated but some of the ideas are absolutely pertinent to today here mostly i'm going to continue to straddle the lines a little bit between these two extremes but probably mostly i'm thinking now at the smaller scale the most reliable way to predict the future is to look at the past and then extrapolate and to do that over a small time horizon so prefer lots of estimates of small things over one big estimate for work that will take a very long time reducing the batch size of your work increases the accuracy of your predictions one way that we can extrapolate from the past experience is to look at similar tasks from our past maybe even in previous projects and how long they really took this is better than guessing based on a detailed analysis of some imagine design which will which will likely give us an illusion of precision but with little accuracy so instead of a detailed exploration of the anticipated design while estimating we will discuss it in enough detail to spot similarities with previous pieces of work and use the numbers from our previous experience this feature is a bit like that one that we did last week and that took three days so let's call it three days for this new feature we're very bad in general at guessing how much work there is in a particular task but we are a bit better at guessing where the two pieces of work are similarly complex that gives us a tool that we can use for estimation when starting to work on the estimation bring a few people together people who will be involved or could be involved in doing the work ideally i'd say about four people is perfect you probably don't want too many more than that and fewer than that he's going to you're going to lose a little bit of the variance that that might give you insight so about four people is around the sweet spot when i'm forced to estimate i like to limit the illusion of precision and one of the techniques that i like to use for that is to estimate on the basis basis of t-shirt sizes small medium or large if you get to extra large then the problem's too big and you should go back to the requirements and break it down into smaller steps the better your team is doing the smaller the value of small medium or large ideally as a guide break down work into features that you can finish within a few days you should be able to complete a large feature in at most a week or two the next problem to deal with is the the undue influence of a particular expert or just a louder member of the team for this i like to use a technique that i call throwing estimates you have small medium and large and then we play a game rather like rock paper scissors where everybody at the same time says throws their estimate like this and then we can talk about what we what we made of it if everyone agrees then we just move on we don't carry on discussing the design anymore a rule of thumb that i like to use when estimating is that this is not the time to choose the perfect design our objective here is to imagine one possible design and we'll just assume that that's the one that we're going to go with we're not going to agonize over what the right design is at this point if the range of estimates is close then we just agree on an average and we tend to prefer the higher values to the lower values when computing that average if one of the estimates is a big outlier then we're going to ask the person who came up with the outlier to explain their reasoning they may have seen something important that everybody else missed or maybe they're just panicking about some more complicated solution than other people have seen it's good to have the conversation and get that out talk about it enough to be able to understand why they made their estimate and agree as a group the t-shirt size for the job t-shirt sizing has two advantages it places a limit on precision i am not going to waste time estimating something that's smaller than a small or bigger than a large it also forces us to break work into smaller pieces this is a good thing ideally you work by finding new work and prioritizing it as you go not all at the start of a project when we are estimating on a broader scope a more accurate approach is to track our recent actual performance as the the project proceeds and mathematically extrapolate from that here's a graph that i tend to use if we imagine the actual performance of delivering software over time it's going to be a bit of a random walk of sometimes we'll do a bit better and sometimes we'll do a go a bit slower and then we can draw these lines the top line is going to demonstrate our most optimistic predictions and the bottom line the red line and more pessimistic predictions and as you can see these are based on the reality of past performance now we can start playing with this information and deciding how we're going to use it if we are interested in trying to hit a fixed date this is the range of features that we are likely to be able to fit into that that period of time alternatively if we are aiming at some kind of fixed scope this is the range of time that we is like we are likely to be able to hit that fixed scope within a most optimistic view and the most pessimistic view this represents a clearer picture of our error bands for our estimation and we can use these as a tool now the reason that i don't trust estimates beyond them just being guesses about the future is that i don't know what fixed scope really means i can certainly work in a way where i can hit a date but i can't tell you what you will have by that date and i guess that i can build all of the features that we think should be in the system and so fix the scope but i think that's a really dumb idea software development is an exercise in learning and one of the things that we learn as we proceed with it is what the target is as we learn more if we aren't changing our mind about what we should be building then we're almost certainly doing a bad job so fixing scope seems like a really dumb idea to me i'd much prefer to work until we have something that makes sense and even better keep releasing things to our users and customers and steering the development towards what makes sense for them that ability to release at any time is really the freedom that continuous delivery gives to us thank you very much for watching [Music] you

Channel: Continuous Delivery

Views: 166,213

Keywords: how to estimate software development time, software estimation, estimating software, how to estimate software projects, software estimation without guessing, software project management, software development life cycle, how to manage software development projects, how to manage software projects, devops, Continuous Delivery, software engineering, software development, Dave Farley, software engineer, software developer, scrum, no estimates

Id: v21jg8wb1eU

Length: 16min 47sec (1007 seconds)

Published: Wed Mar 17 2021