Estimation and the Cone of Uncertainty - Are there chili peppers hidden in your project?

October 31, 2018

Joshua and Kellen discuss estimation techniques and how to improve your ability to estimate how long tasks will take, whether it’s you doing them or your team.

• 00:18 Joshua

  Howdy. So today I wanted to talk about estimation and I have brought in Mr Piffner to uh.. He loves it when I call him Mr Piffner... To help me describe how we estimate software projects and to give some tips and pointers and maybe tell a couple stories of stupid things we've done in the past. So you can not do them in the future.

• 00:39 Kellen

  No, I don't really like it when you called me Mr Piffner. That's all right.

• 00:43 Kellen

  Sure. I guess we should probably pick um, I guess how do we want to approach to explaining estimations to people? So you would do estimations. You're doing it for yg clients. Yeah, they want to know how long it's going to take you to do a project. So let's start there.

• 00:56 Joshua

  They want to know how much it's gonna cost to do the project usually.

• 00:59 Kellen

  Exactly. Which means they have a light, like a much tighter. Uh, it has to be a lot more specific there. You have to be a lot more accurate in your estimations and they have kind of a monetary problem if you're wrong.

• 01:12 Joshua

  Yeah, really it is two-fold for clients or any projects, you've got this concept of cost, which always counts for a lot, but there's also just the expedience of things and how quickly they need to have it done. Uh, quite often we do have clients that it's not necessarily a matter of cost.

• 01:31 Joshua

  In fact, we just had one recently. I kept telling her, you're spending a lot of money with us, are you really sure you want us to do this? And when it came down to it, she didn't mind spending the money because she had the money. What she didn't have was time. So being able to accurately estimate for her how long it was going to take it, in that case, it wasn't about how much it was going to cost. It was about whether or not she could get it done in time for a press release she had coming up, which was critical. She needed to have it done before she started to go tell everybody, "hey, it's done now," and it was wildly embarrassed when it wasn't. So estimation is really important. Either way, whether it's money or not,

• 02:07 Kellen

  I find the ones that are like that where you actually have a set deadline, like a real REAL deadline that you can point to and explain to people actually makes. I don't know if estimation gets easier, but actually getting it done on a schedule somehow it gets easier because everyone can kind of feel the pressure, assuming it's not kind of a fake pressure or a constant pressure, but you know that that crunch time people respond to pretty well and it can kind of throw off estimations actually because then you have a sprint that went really, really fast and no one really knows why.

• 02:37 Joshua

  Mmm. And actually the no one really knows why is probably the thing I would start with first because I was talking to a developer the other day trying to explain how I work with estimation. In fact, exactly this conversation I was trying to have with an individual explaining how I start my process of estimation and what he could do to come up with better estimates because at the time his work completely wildly off constantly.

• 03:05 Kellen

  That sounds like a really good topic.

• 03:07 Joshua

  Yeah.

• 03:07 Joshua

  Either they were either way over the top or just grossly underestimating the complexity of what he was doing and I started to explain this and he basically shot it down. He said that he thought estimation was basically just smoke and mirrors and we were all just guessing.

• 03:22 Joshua

  And I.... my immediate reaction, I was a little bit grumpy with them, but the reality is he's not the only one who thinks that a lot of people think that estimation is just finger in the air. Eh, it's about a week or the week. Or that we just always say the same thing every single time.

• 03:39 Kellen

  It's not entirely wrong that it's a finger in the air estimate, you know, it's a guess, but it's a... it's an accurate guess and again, I guess that gets even more accurate. The more you practice it.

• 03:50 Joshua

  Absolutely.

• 03:51 Kellen

  That's kind of an important thing to keep in mind.

• 03:54 Joshua

  And it's not just the more you practice it, but it's the further you get into your project and the more details you have a, they called the "cone of uncertainty," which to me just sounds like something that you so forced to wear on your head when you're stupid or something like that. I'm uncertain....

• 04:10 Kellen

  That's the Cone of Silence, the Cone of Silence from Get Smart.

• 04:13 Joshua

  Oh, the Cone of Silence... All sounds the same. To me. It's a cone. You put it on your head. You've been bad.

• 04:19 Kellen

  That's probably not wrong...

• 04:20 Joshua

  The cone of uncertainty.... The concept behind it is basically at the beginning of the project, you are using your previous experience which is where a lot of this falls awry for, particularly new people, and your previous experience of other similar projects or similar scopes and you're trying to estimate or ballpark how much it's going to take based on that.

• 04:42 Joshua

  You don't have a lot of details, so the uncertainty or the risk is very, very high and as you get into your project, the amount of risk in your estimate starts to slowly decline because you start to have more information, you know, more of the variables that help you be much more accurate with your estimates.

• 05:02 Kellen

  Absolutely. That's something that happens. Uh, an agile that, you know, obviously I draw has the whole concept of estimations and they have points and then they have t shirt sizes and they have all these various complicated ways of going about that. But it's the same concept.

• 05:13 Kellen

  It's you're... you're supposed to be comparing and measuring against previously completed uh, you know, stories or tickets or whatever, but you're, that's what you're trying to measure against. It's like, is this bigger or smaller than the last time we did something of roughly sorta kinda like that.

• 05:30 Kellen

  And the more you do that, the more you practice it, the more accurate your guesses get overtime. And of course, the larger it is, the more uh, to gets just by that, just by the fact that it's like, oh, that's about a week. Well, there was a lot of things that can go wrong in a week.

• 05:44 Joshua

  That's another point that I like to point out to new people in particular, but actually to anybody who's managing a project, if your estimation is a week, that's not good enough.

• 05:55 Kellen

  Right.

• 05:56 Joshua

  You need break it down. And in fact I've heard people say anything more than two hours, you need to break down. I don't go quite that far. I'm not quite that crazy. But I think about half a day is a good area that... Maybe up to a day for some things. But in general, half day pieces is about the right size that I feel fairly confident I can estimate that half day within a fair margin of error.

• 06:21 Joshua

  Whereas estimating something's going to be about a week. That's a lot of room for things to go wrong. And a week generally is going to contain a lot of smaller components. There's no reason not to break those down. Maybe not on your first ballpark estimate, but once you've gotten past the ballpark and you need to start to get a little bit more detail, breaking those pieces down one by one into smaller chunks that do fit into half day chunks or less, preferably less, but anything up to half a day would be reasonably okay, gives you a better idea of what those individual pieces are.

• 06:52 Joshua

  And the next thing I do with those is then I assign a level of risk to them.

• 06:57 Joshua

  Each of those individual chunks. If it's something I know I've done before, if it's "create a login page," I've created hundreds of login pages. I know roughly how long that's going to take and my estimates are going to be fairly accurate on that. So I would assign that a low risk and if I say it's going to be two hours, it's probably going to be two hours.

• 07:15 Kellen

  So when you do the risk, are you, are you actually recording the risk on like a sheet or something? Like how do you actually write that down?

• 07:23 Joshua

  It will depend. If it's a bigger project, I will. I'll write it down if it's an excel or wherever it is, I will write down what risk I have assigned to that particular item. So it's us... I tried to keep it simple. It's either high risk or normal or low risk.

• 07:42 Joshua

  And early on in my career I had somebody give me some really great advice and he said, "alright, so when you told me this was going to take a day, do you really mean a day or just do you think it's going to be a day?"

• 07:54 Joshua

  And I said, "well I think it's gonna be a day."

• 07:56 Joshua

  "Okay, we'll write down two days."

• 07:59 Joshua

  "But I thought it was gonna be a day."

• 08:00 Joshua

  "No, no. If you think is going to be a day. You told me two days and I'll tell my boss four days."

• 08:07 Kellen

  A lot of nerds learned that lesson from uhhh Scotty in Star Trek. You know, whatever your guesses. Just double it in powers of two because then, you know, you're the miracle worker, but it really is kind of good advice because you're, especially when you're new, you drastically underestimat how wrong things can go. Y

• 08:23 Joshua

  ep. And I correlate my risks to those low risk. I tend not to pad because I put it in low because I'm reasonably certain that's what it's going to be normal risk I devil and high risk. I multiply by four.

• 08:37 Kellen

  So give an example of a high risk risks. I mean we've heard a low risk or the login page you've done a million times. So it would be like an example of a high risk.

• 08:45 Joshua

  So high risk will be things that I have never seen before. So if a client has asked me specifically to work with new technology.

• 08:55 Joshua

  We've actually got a fashion client who has been asking me to look into artificial intelligence and machine learning pieces and I know... I've had some involvement with it. Just looking into some things but I've never actually built and machine learning platform. So I know that's going to be high risk for me and all the little components inside. There might be a few pieces in there that I have done close enough things that I would move down to normal. But most of the things in that are going to be high risk because they're going to be a lot of uncertainties that are giving unknowns in there because I've never worked with it before.

• 09:23 Kellen

  New services, new technologies, even just having to read blog posts and find out, "oh it can't do that." That specific use case you have is a really hard problem. And computer science still.

• 09:34 Joshua

  Absolutely. And that's actually a very valid point. And I've had this argument with people before. When I tell them to double the numbers or quadruple the numbers, they look at me. They say, well, you're just adding in patents. No, I'm not adding in padding.

• 09:47 Joshua

  I estimated that these low risk items are going to be two hours because that's the amount of work I know is involved.

• 09:54 Joshua

  The high risk items. I'm saying I'm going to be four times that because I know I need to go do research, I need to read some blog posts. I need to develop an understanding of what I'm working with. And those things take time and it's very easy to forget to put time in for those things. And just put in the two hours that is probably going to take to do the real job.

• 10:14 Joshua

  And by padding it you're actually allowing for learning, testing, failing... Because you're doing new things. There's things that are going to go wrong, you're going to fail, you're gonna have to backtrack. You're going to have to do all these things that add up time very quickly and the more high risk it is, the more of those things you have to do well.

• 10:33 Kellen

  And it sounds like this is kind of a actually a good metric for somebody who is kind of new coming into this. So let's say you haven't made that kind of estimate before. Well then it's high risk. Even if somebody else with a who who sells a similar thing might estimate lower because they've done it a million times, you kind of have to estimate higher because you haven't. And I mean that seems like a kind of a reasonable, a reasonable starting point. It even shows you where you need to grow. If you want to be better at estimating that particular type of project, you're gonna have to practice it more until you actually know how long it takes you.

• 11:04 Joshua

  Absolutely, and certainly early on I doubled every damn number because I didn't know what I was doing so I had to pad it and I had to be aware of areas that I needed to backtrack or learn or whatever it may be and as I've gotten further into my career I have to do much less of that obviously, but it's a process of gradually getting to the point that I'm more able to more accurately estimate and that I have a greater knowledge base that I can work from.

• 11:35 Kellen

  And now I mean a lot of people try to compare a estimating software projects to, like, how'd they do a like construction, you know, construction has these big gantt charts and the processes and all these uncertainties because there's so many things that can go wrong. But I feel like the comparison isn't quite quite fair.

• 11:54 Joshua

  There are some parallels and certainly any project management is going to have parallels with others even in different fields, but there are certain things that are absolutes in building a house that won't necessarily be in software because software and technology is moving on so quickly and while, to be fair, the building industry is actually moving on very quickly and there are new technologies. It's not quite as fast paced, so there's a difference in there.

• 12:22 Kellen

  And there is a difference on, on the types of risk as well as like, um, I don't know because a lot of the biggest risks tend to be third party problems. Um, and those are usually where the over overflow comes from. Is the third party estimated wrong. They passed that estimation up to whoever's running the big giant project chart and they go, oh, that's wrong. And that throws everything off and there's screaming.

• 12:44 Kellen

  But with software that would be the equivalent of a third party library having a problem and they're a lot more of those in software development. Uh, than there are contractors in, you know, building a building.

• 12:55 Joshua

  Yeah. Another thing that you mentioned that I wanted to pick up before I forget, there's also this concept of estimations only really being valid for one person.

• 13:08 Kellen

  Oh yeah.

• 13:10 Joshua

  You were talking about a junior not being able to estimate it based on what somebody else could do and that's absolutely true. I mean even two senior developers can't estimate off of each other.

• 13:20 Joshua

  It might help if you are at the same level. You're going to have roughly the same sorts of things, but if you've got a different knowledge set or different experience at or just at different positions in your career or whatever it may be, it may take you more or less time to do that piece so you can't estimate it for one person and then directly apply that to another person and particularly as a project manager, that's really important because you need to start to learn your team so you know that developer A is going to get that done in two hours and developer B might take 12.

• 13:54 Kellen

  I was just going to bring that up. That's actually like a team skill, like a skill that you kind of learn together as a team is a part of the development, especially in agile because the, the, the estimates are going to come up from development, product management doesn't really get to pick which one they like. Um, and they're not going to get to pick which developer works on it either in most cases.

• 14:12 Kellen

  So it's kind of a group skill that you have to practice of. Okay. We're, you know, the junior person estimates this will take them a week. The senior person says about two hours. We, you know, over time you have to kind of figure out what that really means in terms of team a team points. Like, is that actually about a day? It's probably about a day. It's like the junior person would do it. If they did it on their own, it would take them forever, but they have other people that they can ask questions of and they'll figure it out pretty quickly.

• 14:40 Kellen

  Um, but you kind of have to go for whatever the lowest one is, you know, however long it's going to take the, the, the, the least technical person w

• 14:48 Joshua

  ith help. I have seen that go horrifically wrong as well. Exactly that point. The senior developer says, yeah, it would take me two hours to do that. Then they put that down on the books and then assign a junior developer to the task.

• 15:01 Kellen

  Yep. That happens all the time.

• 15:01 Joshua

  And then at the end they're saying, why is this so wildly over budget? It took a week to get that done. You said it'd be two hours and the senior developer saying, well, you didn't ask me how long it would take him to do it. I told you it takes me two hours. Why did you assign it to him after asking me, you should've asked him. Well, he didn't know because he's a junior developer and he doesn't know how to estimate.

• 15:20 Joshua

  He should listen to our podcast. ;)

• 15:24 Kellen

  Oh, the poor blokes that like that actually is one of the arguments for why the developers are self assigning in a lot of agile groups is because it's really difficult to, to match estimates, you know, that's like one of the many, many, many reasons to do that. But a part of that is because it's really difficult to estimate it, you know, the junior dev can go, I can't get that done within that estimate. I can't work on that ticket or we have to go back to product manager and explain, hey, this one's going to take longer. Um, so there's some back and forth there for, for those types of issues.

• 15:54 Joshua

  Yep. And at any level, it is a skill that you do have to develop. It's not just something that you can listen to a podcast or read a couple of blogs and suddenly understand exactly how to estimate for yourself or for a team or how to get your team to work together to estimate accurately. It's something that you need to learn a lot about, but then you need to practice because it takes time

• 16:18 Kellen

  And I can give some. We do have like advice we can give for how you should practice, uh, you know, there's very important things you should do. You should be breaking them down into the smallest pieces that you're comfortable creating estimates for and then kind of combining those into one estimate. Um, you can, you should be tracking metrics on individual estimates so you can go back and compare how you did last time. It's a lot easier to know how far off you are when you actually have accurate notes telling you how far off you are, um, and metrics and graphs and such can even show you how that changes over time, which is really important when you have a big team.

• 16:52 Joshua

  Absolutely for big teams, but even individually, not necessarily keeping huge notes or anything like that. It doesn't have to be a huge task, but, and some of this will happen naturally. You will remember the last time I estimated this is going gonna be two hours. It took me eight hours this time.yyou know what, I'm just going to write down eight hours just in case because you automatically, you learned from your experiences and that's why it is very difficult to estimate early on because you don't have enough experiences to pull from.

• 17:22 Kellen

  Right.

• 17:23 Kellen

  And some of that, like what you just described, I actually have to write down because I never remember what I said last time. It's like, did I say a day, did I say a half day? Did I say a week? What did I say? And so that's why I actually mentioned specifically I write it down because I won't remember next time. So some of this is obviously uhh, you know, how you, how you track yourself.

• 17:43 Joshua

  Yes, absolutely. And estimation in general is a very personal thing. I have never run into two people who exactly in the same way and what I tell people to do sometimes they come back to me and they say, I tried it your way and I just, I can't get it to work. This works for me. Is that okay? It works for you. Yes, it's okay, do that. In fact, you know what, if it works for you, you tell me and I'll see if it works for me too because you may have a better way of it than I have.

• 18:10 Kellen

  Exactly, and that's always the best thing to add to your team. I love it when you can add to like somebody who does estimate and estimate something that works and it's totally different than the way you go about it because then together you're approaching the problem from two different angles and your answer is going to be that much better because of it

• 18:28 Joshua

  And that's true of any skill, realistically. When you're working with a team, that's one of the best parts of working with a team is everybody thinks differently and I'm actually. We should probably get into this in another episode, but I've run into companies that interview people looking for people who are exactly like all the other people on their team.

• 18:44 Joshua

  I keep saying, well, no, you want to interview people who are different because different people have different ways of doing things and quite often you will find that your team has been estimating things this way and they might be 80 percent accurate, but they've been doing it the same way for the past 10 years and you get some new guy in who's completely different than the rest of the team has a different level of experience, comes from a different background and he estimates it in a completely different way and it increases your efficiency drastically because he's brought in new information. If you keep bringing in the same information, you're not going to move anywhere. Nothing's going to shift. It's all gonna be the same.

• 19:19 Kellen

  I've seen junior developers make those kinds of changes in teams as well. They came in with experiences, you know, Random New Technology 1 and some feature of that that they really liked and kind of pushed for on their new team and it turned out, yeah, that was a really great idea. It was that knowing that different way of doing something really helped everybody else when they started adopting that practice, even though the junior developer can do a whole heck of a lot else to help out, you know, right off the... Right out of the gate.

• 19:47 Joshua

  Yeah. I think we should probably plan that to be our next podcast, discussing hiring people who add to your team.

• 19:54 Kellen

  That's a pretty good topic.

• 19:55 Joshua

  So we will go plan that one and in the meantime I will put some transcripts up at gettingappsdone.com.

• 20:02 Joshua

  Please be sure to check out my website at joshuagraham.info to learn more about me.

• 20:07 Joshua

  And check out Mr Piffner's website as well at piffner.com.

• 20:13 Joshua

  Don't forget to subscribe to the podcast and check out our website, drop us a line.

• 20:17 Joshua

  If you've got any questions about estimation or if you tried estimating in the past and things went horrifically wrong or if you've got a completely different way of estimating, as we said, we'd love to hear about that, so please let us know. Drop us a line and we'll check that out later.

• 20:31 Joshua

  Until next time, thank you for listening.