Time Estimation

[00:00:03]
>> Francesca Sadikin: So, now we're shifting into handling common project execution problems. So, let's look at this scenario. Near the deadline, I let my manager know I am not going to finish the task, and it took another month to finish it. So what would you do in the scenario? What would you do differently?

[00:00:25]
>> Speaker 2: You could ask for any other help from the team.
>> Francesca Sadikin: Yes.
>> Speaker 2: Anybody, any other domain experts in the company.
>> Francesca Sadikin: Asking for help, yep.
>> Speaker 3: Yea, I just think it's important to communicate any blockers with your team so that you can get unblocked as quickly as possible?

[00:00:45]
>> Francesca Sadikin: Yes, communicate blockers.
>> Speaker 4: Explain the complexities of why it could take longer.
>> Speaker 4: One person said this is the part that scares me, giving timelines.
>> Francesca Sadikin: Okay, yes. You guys are all correct, but I find that when engineers are in this position, it's often, this is very common because they didn't know they weren't going to finish it until it was too late, right?

[00:01:21]
And so there's actually several pieces that leads into this problem. First is just that the belief that the task that you're working on is a fixed entity. Like, you didn't realize that there is flexibility sometimes in the deadlines, the scope, and the priorities, which changes with new insights and new information.

[00:01:45]
Second, like I mentioned, estimation is a problem. Many engineers feel like they're on track until it's too late to adjust and they're estimating the complexities involved. And then, like others mentioned, communication. Communication is very, very important. Keeping regular updates to stakeholders informed helps you uncover potential issues early, allowing for timely support and course corrections.

[00:02:12]
And compounding all of this is impostor syndrome which is experienced by many engineers which makes it harder to communicate that you are struggling. So, how do we navigate all of these issues effectively? So we're going to focus on gathering more information, embracing over-communication, and then also estimations skills.

[00:02:42]
Okay, so estimation, engineers have a higher chance of missing deadlines if they're still developing their estimation skills. By the way, estimation is very hard. Lots of engineers, super experienced engineers, get it wrong all the time, but there are tactics to help. One of the ones that I really like is to use a spike.

[00:03:07]
So, let's say that you have this task. You have requirements 1, 2 and 3. There's a testing phase and a deployment.
>> Francesca Sadikin: A lot of engineers, if they do a waterfall approach to these tasks, it's very risky. So what this would look like is like, they see it as like a checklist, they're like, okay, requirement 1, complete that, go move on to requirement 2, complete that.

[00:03:37]
Now, the problem is that if requirement 3 was actually really, really difficult. You would not have known until it was too late that you didn't have enough time and you needed more support, right? It's like you didn't know. It's the unknown, unknowns, you didn't know until it was too late.

[00:03:58]
So, if you use a spike. So, a spike is essentially, this is an agile term, I think, and there are other terms that kind of paints this process. But you would kind of take maybe a few hours, a day or two, depending on how complex this work is, and what you would do is take every single piece of it.

[00:04:20]
All three requirements, the testing, the deployment, and in that timeframe, you would go into each one upfront. That would look maybe like starting to look into the code, starting to write a little bit of a code, looking to see what would it take for you to do this work.

[00:04:39]
And by doing this upfront, you are starting to figure out very quickly like, is this task exactly what I was expecting? Or like, I don't actually know what's going on here and I should spend more time. And so this allows you to plan your work better. You can see this diagram here, where, okay, requirement 1.

[00:04:59]
I know how to do that. But requirements 2 and 3. Actually, this was actually a lot more complicated than I thought. I need to make sure that I'm planning for that work earlier, right? I'm starting to ask more questions about it beforehand. Realizing that testing, it's gonna be too hard to do it all at the end, we should really be doing it all, all throughout this process, and then we end with deployment.

[00:05:26]
>> Francesca Sadikin: So, this just allows you to solve some of those unknowns earlier on and allows you to plan your work better.
>> Francesca Sadikin: The other small tips that I have, is to practice breaking tasks down now. So especially if you haven't started working in a corporate setting. When you are doing a task, guess how long it was going to take you and then compare it to how long it actually took.

[00:05:54]
You're starting to develop an internal sense for how long you actually take when you know what to do and when you don't know what to do. Last, remember, understand how long it takes to actually get to completion in your company process. Completion doesn't mean code complete. It has to go through all of these other phases and you need to incorporate that into your estimation, right?

[00:06:22]
So, for example, does the PR review take, like, a few days a week or two? Does getting to testing staging production environments also take a few days? Because, like, I don't know, some different processes in different companies are always different. And does deployment, is it instantaneous, or does the company only deploy once a week?

[00:06:48]
You want to understand all of those additional time frames and make sure that when you're done, you've took into consideration all of this. Over-communicate. So, as I mentioned before, communicating is super duper important to give you more flexibility if there is a problem. Things you want to be communicating.

[00:07:16]
What has been done? What is currently in progress? What are blockers? Even just like a hint of a blocker, you want to communicate that and potential solutions for that blocker. You wanna talk about what's at risk of not being delivered. You should be talking about all of this to your manager, to teammates working on this task with you, and then any stakeholders relying on this work.

[00:07:46]
This last one is, if your manager and your other teammates weren't communicating this out to the stakeholders, maybe you should be responsible for doing that as well.
>> Francesca Sadikin: Lastly, gathering information. Gathering more information about the task provides flexibility when obstacles are hit, right? Cuz you might find that the requirements on a ticket, someone just wrote that, but it can change sometimes.

[00:08:18]
You wanna figure out what exactly is this task. Most tickets are not very detailed, and so it's up to you to actually understand what it's trying to ask for, what are the edge conditions that you want to handle. What are the validation steps to determine that this task is correct and done, right?

[00:08:40]
Does that mean that someone needs to check it. And when it's deployed in front of users and confirm that, yes, that's working now. Who are all the stakeholders to sign off on that work? Who is relying on this work? A lot of your work doesn't happen in isolation.

[00:08:57]
Usually, there is a pipeline and other people are probably relying on this. Why does this work matter, right? What's the importance to your team, to the people relying on it, to the business, and then, when is it needed, really? So, like to give you an example of how this plays out.

[00:09:20]
We're gonna take this task again. We have requirements 1, 2, and 3, we have a testing piece and a deployment. The initial deadline on this ticket was a month, right? In your investigation, you find out that, well, there is a team that needs it, but they only need requirement 2, and they only need that in a month.

[00:09:46]
So, keeping that in mind, if you run into problems, you can use that information to adjust the scope, right? So instead of trying to deliver everything at once and missing like the whole thing altogether. You can talk to the stakeholders to see like, hey, is it okay if I just deliver what you asked for requirement 2 in that one month.

[00:10:12]
And I can push off requirements 1 and 3 to be delivered after because it's not as critical for you. So, this is just like a little example of what it looks like. Like the flexibility that you can have, and the adjustments that can be made, if you just had more information about what this task actually is.

[00:10:33]
>> Francesca Sadikin: So, if we revisit that old scenario, given all this new skill, and mindsets. We can change this situation and say I proactively worked with my manager and stakeholders to arrive on a revised scope that allowed me to complete on time and still deliver what was needed.