Latest / DevQuestions with Tim Corey / 019 How Do You Estimate How Long a Project Will Take?

Transcript

019 How Do You Estimate How Long a Project Will Take? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:25
  SPEAKER_01: How do you estimate how long a project will take?
• 0:29
  SPEAKER_01: This question comes up a lot.
• 0:31
  SPEAKER_01: So Lee asked the question, how do you figure out time estimates?
• 0:35
  SPEAKER_01: And then Simon kind of followed it up with, Yeah, minimal experience makes it difficult to estimate time from inception to completion.
• 0:43
  SPEAKER_01: So how do you figure out how long your project's gonna take to complete?
• 0:49
  SPEAKER_01: That's the question for today's Dev Questions episode.
• 0:53
  SPEAKER_01: Now, if you don't already know, this is a podcast.
• 0:56
  SPEAKER_01: So if you're listening to the podcast, then you already know.
• 0:59
  SPEAKER_01: But if you're listening on YouTube, then this is also a podcast.
• 1:02
  SPEAKER_01: So if you want to know, listen to this on your drive to or from work, if you're going to work still or back to work, this would be a great time to check that out on iTunes, on Amazon, on Spotify.
• 1:15
  SPEAKER_01: There's pretty much a bunch of different places you can find it.
• 1:18
  SPEAKER_01: So let's talk about time estimates.
• 1:22
  SPEAKER_01: Time estimates are hard.
• 1:25
  SPEAKER_01: I wish I could give you a formula, but there just isn't one.
• 1:30
  SPEAKER_01: In fact, pretty much every estimate is just a wild guess.
• 1:36
  SPEAKER_01: That's what it comes down to.
• 1:38
  SPEAKER_01: And that's kind of pressing.
• 1:41
  SPEAKER_01: But if you know that going in, you have a better opportunity to communicate clearly what your estimates are really saying.
• 1:51
  SPEAKER_01: Let me explain that.
• 1:53
  SPEAKER_01: Let's say you're gonna build an application, a very, very simple application.
• 1:59
  SPEAKER_01: Let's just say you're gonna build a to-do list application that's only going to be a wind form application with a SQLite database.
• 2:09
  SPEAKER_01: So it's self-contained database with a wind form front end.
• 2:14
  SPEAKER_01: Really small, really self-contained, no special features.
• 2:18
  SPEAKER_01: Cool.
• 2:19
  SPEAKER_01: So your boss asks you for how long do you think that will take?
• 2:23
  SPEAKER_01: Or maybe you're trying to estimate and say, how long will this take?
• 2:27
  SPEAKER_01: Well, one way I say it is I think it's gonna take three months.
• 2:33
  SPEAKER_01: Why?
• 2:35
  SPEAKER_01: Because?
• 2:36
  SPEAKER_01: Okay, that's not a great answer, and it does not inspire confidence from anyone.
• 2:40
  SPEAKER_01: So one thing you can do is you can break the project down into its pieces.
• 2:46
  SPEAKER_01: If you've watched my C sharp application from start to finish course, or if you have watched the Timco Retail Manager series, to an extent, uh C sharp application is much more clear in the forefront of it.
• 3:00
  SPEAKER_01: Um, but if you've watched my uh Complete Foundation C Sharp series, in a number of different locations, I talk about the Wood Framework, W-O-U-L-D, where we're we're breaking down a project before you even start it, we're planning it out.
• 3:18
  SPEAKER_01: Go through that process.
• 3:20
  SPEAKER_01: Because if your boss asks you to estimate something and you haven't thought through the entire application, there is no way you can give anywhere close to an accurate assessment of how long it's gonna take.
• 3:35
  SPEAKER_01: It's gonna be a guess.
• 3:37
  SPEAKER_01: Now, your guess may be right, and you may be great at reading the wind or tea leaves or something and coming up with guesses that sound right and that tend to be right, but the reality is it is just a guess.
• 3:52
  SPEAKER_01: Until you have really identified what the application does in detail, until you've planned it out, you don't know.
• 4:02
  SPEAKER_01: So walk through that wood framework process, those five steps to start a project before you start coding.
• 4:09
  SPEAKER_01: Those five steps of planning out a project.
• 4:14
  SPEAKER_01: Now, if you do those five steps, and if you expand the project and figure it all out and lay it all out and identify your assumptions and eliminate them and identify the different pieces of your application, you will have broken it down into chunks.
• 4:33
  SPEAKER_01: Now, what you can do is estimate a chunk and say, how long will it take to build a SQLite database that does these 10 tables that has these 10 tables with these 50 fields total?
• 4:50
  SPEAKER_01: Well, that's a lot easier to estimate.
• 4:52
  SPEAKER_01: You can say, well, I create pretty much a table every 15 minutes, let's just say.
• 4:59
  SPEAKER_01: So with 10 tables, that means 150 minutes, that's two and a half hours.
• 5:05
  SPEAKER_01: Don't forget to add some slack time in there, some time for issues that come up, and so on.
• 5:10
  SPEAKER_01: So now that's gonna be four hours.
• 5:14
  SPEAKER_01: Four hours is your estimate.
• 5:16
  SPEAKER_01: Awesome.
• 5:16
  SPEAKER_01: Now you have an estimate for one piece of the process.
• 5:21
  SPEAKER_01: Do that with the rest of those chunks, and now you have a good estimate for the overall project because you have broken it down to chunks and estimated each chunk.
• 5:34
  SPEAKER_01: When you estimate a chunk, it's easier to get a good number out of that because it's easier to put that all in your mind at once to think about well, how do I do that process?
• 5:47
  SPEAKER_01: How long did it take last time, and so on.
• 5:50
  SPEAKER_01: And that brings up another point.
• 5:51
  SPEAKER_01: The more you practice, the more you build applications like this or build pieces like this, the better you will be at estimating time because you've done it before.
• 6:02
  SPEAKER_01: And so you reference past history.
• 6:06
  SPEAKER_01: Every time you run across something where you say, I've never done that before, that's a big red flag for estimation.
• 6:13
  SPEAKER_01: You're gonna have no clue.
• 6:15
  SPEAKER_01: So here's what I recommend.
• 6:17
  SPEAKER_01: If you come across something where you say, I've never done it before, build a sample project that does just that.
• 6:24
  SPEAKER_01: Not a whole real project, just something that tests out that little piece.
• 6:30
  SPEAKER_01: Learn about it, test it, and figure out how it works.
• 6:34
  SPEAKER_01: Now you have history.
• 6:36
  SPEAKER_01: Even if the history is from 15 minutes ago, now you know how long, roughly, that should take.
• 6:43
  SPEAKER_01: Add a little extra slack time in there for that newer thing because something will come up in that area.
• 6:49
  SPEAKER_01: But now you have a good estimation.
• 6:51
  SPEAKER_01: Because they're little chunks, it's easier to pull experiences from different areas.
• 6:57
  SPEAKER_01: Maybe you've never built a wind form application before, but connecting to a database, you did that in your WPF project or your ASPNet project.
• 7:06
  SPEAKER_01: Well, that's the same thing.
• 7:08
  SPEAKER_01: So you can estimate that chunk even though you haven't done the win form part of it.
• 7:13
  SPEAKER_01: So there's a lot that you can pull from different projects, again, from your experience, that will help you estimate those time chunks.
• 7:23
  SPEAKER_01: Now maybe time chunks that you just have to guess on.
• 7:26
  SPEAKER_01: But if it's a smaller piece, it's easier to make an educated guess on just that piece than it is the overall whole.
• 7:36
  SPEAKER_01: So you've broken it down, you've gone through the wood framework, you've tested out the things that are new, you've estimated all of those chunks, you've added them all together, and more importantly, you've added Slack for each of those pieces.
• 7:51
  SPEAKER_01: Like I said, if it takes you two and a half hours to create those SQLite tables, call it four.
• 7:57
  SPEAKER_01: Because something comes up.
• 8:00
  SPEAKER_01: Whether it's you're interrupted, you have the end of the day and the start of the day the next day that it kind of overlaps, and so there's a lot of you know, shutdown time and startup time that kind of takes away and just the general distractions of life.
• 8:16
  SPEAKER_01: You know, you get hungry at 9:30 in the morning.
• 8:19
  SPEAKER_01: Well, that's gonna take time away from your 8 to noon time frame.
• 8:24
  SPEAKER_01: So just make sure you put some slack in there for those things.
• 8:29
  SPEAKER_01: Now you have a better estimate.
• 8:31
  SPEAKER_01: Now you have an estimate that is more reasonable to the project.
• 8:37
  SPEAKER_01: So that's that's the ideal way of project estimation.
• 8:42
  SPEAKER_01: Break it down in chunks, estimate each chunk, make sure you have history that backs up your experience in that area.
• 8:50
  SPEAKER_01: That does mean that an estimate is not as quick as your boss saying, How long will that project take?
• 8:57
  SPEAKER_01: And you're going, eh, three hours.
• 9:01
  SPEAKER_01: That doesn't work.
• 9:02
  SPEAKER_01: Okay, you can't do that.
• 9:03
  SPEAKER_01: You're gonna have to take time to create a real estimate.
• 9:06
  SPEAKER_01: Try and communicate this with your boss or with a person asking.
• 9:11
  SPEAKER_01: That's the ideal for estimating a time, uh time for the project.
• 9:18
  SPEAKER_01: But there's more to a project than just the initial plan.
• 9:23
  SPEAKER_01: There is the the part where the stakeholder, whether it's the boss or somebody else, starts making changes.
• 9:32
  SPEAKER_01: This is where clear communication helps.
• 9:37
  SPEAKER_01: And that starts with the wood framework.
• 9:40
  SPEAKER_01: Because the wood framework, one of the things it talks about is making sure you have your assumptions written down and communicated so that everyone knows what you're assuming, everyone knows what the project will and will not do right up front, because then you have your set time that you say the project will take this long.
• 10:06
  SPEAKER_01: Then when someone comes to you and says, Boy, you know what would be great?
• 10:11
  SPEAKER_01: It'd be great if we had an API for this Winform project because that way later we can add a mobile app as well.
• 10:19
  SPEAKER_01: Cool idea, but that's not part of the original time estimate.
• 10:24
  SPEAKER_01: So now what you need to do is say, Okay, time out, pause.
• 10:30
  SPEAKER_01: We need to adjust our time frame, we need to adjust our plans based upon that new information.
• 10:38
  SPEAKER_01: And you again break it down to pieces, figure out what's gonna change, re-update your estimate, re-add those pieces together, and come and say, you know what, that's gonna take an extra five days of project time to do that.
• 10:54
  SPEAKER_01: Is that acceptable?
• 10:56
  SPEAKER_01: And if they say no, it's not acceptable and say, okay, we can't do that.
• 11:01
  SPEAKER_01: If they say, well, I still want that, which happens, then you have to have that conversation about reality.
• 11:08
  SPEAKER_01: Okay, if you want the API, but you don't want the cost associated, that time and effort associated, then you have to pay for it a different way.
• 11:20
  SPEAKER_01: That means taking something out of the project.
• 11:24
  SPEAKER_01: Since you've already broken down the project into chunks and you know what each chunk costs as far as time, then you can say, okay, the API costs this much.
• 11:36
  SPEAKER_01: And if we pull out this piece and this piece and this piece from the original project, that roughly equals the time that the API is going to cost.
• 11:45
  SPEAKER_01: So we can pull out these, let's say, five features and put in the API instead.
• 11:50
  SPEAKER_01: Is that better?
• 11:52
  SPEAKER_01: And then you have a conversation of this is just reality.
• 11:56
  SPEAKER_01: It costs time to do work, and you can't just add more work with no more time.
• 12:03
  SPEAKER_01: So that's the next battle to fight as you're going through your project, is maintaining the scope of work that you originally agreed upon.
• 12:16
  SPEAKER_01: Because if your scope of work changes, so does your time.
• 12:22
  SPEAKER_01: That also means that as you're going along, you can't just say, that's a cool feature, let's add that in instead.
• 12:32
  SPEAKER_01: You know, if we just tweak this here and there, we could do this.
• 12:36
  SPEAKER_01: That's great.
• 12:38
  SPEAKER_01: What's it gonna cost?
• 12:39
  SPEAKER_01: How's it gonna affect the overall timeline?
• 12:42
  SPEAKER_01: And that's something you have to keep aware of and keep track of.
• 12:47
  SPEAKER_01: Now, as you go through the project, you may find that you start to get ahead because you've added Slack in, and maybe you didn't need all of that Slack.
• 12:58
  SPEAKER_01: Cool.
• 12:59
  SPEAKER_01: That's a great place to be.
• 13:02
  SPEAKER_01: A lot of us aren't there very often, okay, to be honest, because usually things take longer than we expect them to.
• 13:08
  SPEAKER_01: But if you have that extra time, save it.
• 13:12
  SPEAKER_01: Don't just start adding features in before you reach the end goal.
• 13:16
  SPEAKER_01: Otherwise, what happens is that extra feature takes more time than you expected.
• 13:22
  SPEAKER_01: Now you're behind schedule and you've made your life miserable.
• 13:26
  SPEAKER_01: So if you have extra time, get to the end goal first, sooner, and then see what you can do in that two weeks extra you have, whatever time you is you have to add more features.
• 13:40
  SPEAKER_01: But get to the goal first.
• 13:42
  SPEAKER_01: Don't get distracted off the path because you think you have time.
• 13:47
  SPEAKER_01: Otherwise, you'll find out you didn't have time.
• 13:50
  SPEAKER_01: Something else is gonna take that time up.
• 13:53
  SPEAKER_01: Now, what happens if your time estimates are just horribly wrong?
• 13:59
  SPEAKER_01: Maybe you expected the database to take four hours and reality, something weird happened, SQLite has an update, it's not compatible with your version of Windows, and you've got to update.NET, and you got it's just a whole mess, and you waste three days trying to get it to work.
• 14:19
  SPEAKER_01: That's why you have Slack in the schedule.
• 14:21
  SPEAKER_01: Hopefully, you've put enough in, but either way, that's gonna cause some time pressure, in which case, communicate early.
• 14:31
  SPEAKER_01: Communicate, hey, you know what?
• 14:33
  SPEAKER_01: We slipped on our time schedule because of you know these issues that we could not have predicted, we couldn't prevent, don't make out excuses, just explanations of what happened, and talk about here's what that does to the timeline.
• 14:52
  SPEAKER_01: And talk about how, hey, we like to keep to the end date, and so therefore, we have to take out these three features.
• 15:01
  SPEAKER_01: Or we're gonna change the end date because of that slippage in time.
• 15:08
  SPEAKER_01: You've got to know what's more important to the project stakeholders, whether it's that end date or whether it's all the features.
• 15:16
  SPEAKER_01: And so you have to communicate those things, you have to talk about that, you have to talk about the fact that you know it's not just you're wasting time, but here's why this happened, here's how you're gonna correct for the future, those kind of things.
• 15:31
  SPEAKER_01: It all comes down to communication.
• 15:34
  SPEAKER_01: You don't wait until the end of the project and go, oh, by the way, we're three weeks late.
• 15:39
  SPEAKER_01: Don't do that.
• 15:41
  SPEAKER_01: Early and often, explain.
• 15:43
  SPEAKER_01: But then for your next project, learn from that.
• 15:47
  SPEAKER_01: Make your time frames larger, add extra slack in.
• 15:52
  SPEAKER_01: Usually what I do is I try and add about 40% of my time, maybe even 50% of my time to be uh Slack time, meaning time that's not dedicated to something that is just padding.
• 16:08
  SPEAKER_01: So if a task is gonna take one day, I say two days.
• 16:12
  SPEAKER_01: If a task is gonna take two weeks, I say a month.
• 16:15
  SPEAKER_01: And so I make sure I add extra time in there.
• 16:18
  SPEAKER_01: Now, sometimes if it's a two-week task, I might say three weeks, but I try really hard to say four.
• 16:26
  SPEAKER_01: Because adding that extra time in there allows me that buffer time to make sure that I underpromise and over-deliver.
• 16:36
  SPEAKER_01: If you're gonna make a mistake, estimate too much, estimate too long for the project.
• 16:43
  SPEAKER_01: Because if you come to your boss and say the project is done in 100 days and we said it'd take 150, your boss is gonna be happy.
• 16:54
  SPEAKER_01: But if you come to your boss and say the project took 100 days, we said it would take 50.
• 16:58
  SPEAKER_01: Your boss is gonna be upset.
• 17:00
  SPEAKER_01: Okay, same time frame, different attitude.
• 17:04
  SPEAKER_01: Now, your boss may say at the very beginning, I want it in 50 days, and you say, It's 150.
• 17:12
  SPEAKER_01: Okay, that may be the case.
• 17:15
  SPEAKER_01: And so again, you have to talk about what reality is and say, you know what?
• 17:20
  SPEAKER_01: We love to hit the 50-day time frame, but we think that in order to do that, we have to have only these certain features, and then discuss it's a matter of of time versus the job, how much time each task takes adds up, and it's not just free, it's not just we can add more people or or just add more effort and get this done.
• 17:46
  SPEAKER_01: Now, time estimation is always going to be an inexact science.
• 17:51
  SPEAKER_01: It's not something you can say, here's the formula.
• 17:55
  SPEAKER_01: But if you take steps to break the problem down, to make sure you add in Slack, to make sure that you maintain your scope and make sure you communicate your changes, by doing all of that, you will better control your estimates and you will have a better time estimation track record.
• 18:19
  SPEAKER_01: All right.
• 18:19
  SPEAKER_01: So that's that's my take on time estimation.
• 18:23
  SPEAKER_01: It takes a lot of work, it takes a lot of practice.
• 18:26
  SPEAKER_01: It's not something you're gonna get right a lot at first.
• 18:30
  SPEAKER_01: It's gonna take time to figure these things out, to try out different things.
• 18:35
  SPEAKER_01: And the more you have practiced each piece, the better you will be at estimating how long it's gonna take.
• 18:43
  SPEAKER_01: So make sure you practice as well and keep those practice projects.
• 18:46
  SPEAKER_01: Keep them in an archive and label them so you know, oh, I know how to do dependency injection in.NET Core.
• 18:53
  SPEAKER_01: I've got a sample project over here that did that.
• 18:56
  SPEAKER_01: Let's look at and refresh ourselves.
• 18:59
  SPEAKER_01: That will save you time.
• 19:01
  SPEAKER_01: So make sure you have that experience by practicing and then make sure that you do those steps to estimate your time well on a project.
• 19:13
  SPEAKER_01: Communicate clearly, and make sure that everyone's on the same page with a project.
• 19:19
  SPEAKER_01: So that's that's my take.
• 19:21
  SPEAKER_01: Thanks for listening.
• 19:22
  SPEAKER_01: As always, I am Tim Corey.
• 19:24
  SPEAKER_00: Thank you for joining us for this episode of Def Questions.
• 19:27
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 19:31
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions.
• 19:38
  SPEAKER_00: You can also send your questions to questions at IamTimcore.com.
• 19:43
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 19:50
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.