Vox

Leitura de 27 min

Better Low-Information Estimates - Putting the “Scientific” in SWAG

Summary

This episode addresses the common challenge of estimating software work when requirements are ill-defined, a frequent scenario in startup and agile environments. The host begins by framing the problem from a leadership perspective: decision-makers need cost estimates to evaluate projects against benefits and allocate resources effectively, yet they often lack detailed specifications.

The discussion clarifies the fundamental nature of an estimate as “some guess about the future combined with some idea of how likely that guess is,” contrasting it with a deadline, which is a commitment device. Deadlines are often used for risk mitigation and to apply Parkinson’s Law (work expands to fill the time available), but they are distinct from estimates and can create unnecessary stress if their real consequences are unclear.

The core of the episode presents three practical frameworks for estimating poorly-defined work. First, affinity or relative estimation involves comparing the new body of work to similar past projects the team has completed, using metrics like total story points or cycle time to derive a reasonable guess. Second, the PERT (Program Evaluation and Review Technique) method uses a three-point estimation formula: (Optimistic + 4*Most Likely + Pessimistic) / 6, which creates a weighted average that accounts for best-case, worst-case, and most likely scenarios.

Third, the host recommends requesting a small amount of discovery time, based on the principle that the first bits of investigation yield the highest return on investment in reducing uncertainty. By identifying the one or two principal components or assumptions that could drastically change the scope (e.g., vendor dependencies, compliance requirements), teams can provide estimates with explicit caveats that increase confidence.

The host concludes by emphasizing that a true estimate should be a range with a confidence interval, not a single date. Combining these approaches helps wrangle undefined work, decrease the estimation range, and improve confidence, providing a more scientific alternative to a pure SWAG (Scientific Wild-Ass Guess).

Recommendations

Concepts

  • Parkinson’s Law — Mentioned in the context of deadlines, it’s the idea that work expands to fill the time allotted for its completion. Deadlines can act as a container to apply this law.
  • Affinity / Relative Estimation — An estimation technique where you compare a new body of work to similar past projects (reference classes) the team has completed to gauge its relative size and complexity.
  • PERT (Program Evaluation and Review Technique) — A three-point estimation method using optimistic, most likely, and pessimistic scenarios. The formula (O + 4M + P) / 6 provides a weighted average estimate.
  • SWAG (Scientific Wild-Ass Guess) — Referenced in the episode title, it’s a colloquial term for a rough estimate. The episode aims to put more ‘scientific’ methods behind such guesses.

Tools

  • Wix Studio — The episode’s sponsor. Described as a developer-first website builder with a node-based editor, VS Code-based IDE or local GitHub integration, AI code assistant, and automatically maintained infrastructure.

Topic Timeline

  • 00:00:00 — Introduction to planning and estimation pitfalls — The episode opens by setting the context of year-end and Q1 planning, highlighting the common challenge of estimating ill-defined work. The host explains that leaders need cost estimates to make investment decisions, comparing expected costs to benefits, whether in agile or waterfall environments. This creates pressure on engineering teams to provide estimates with limited information.
  • 00:03:49 — Defining what an estimate truly is — The host defines an estimate as a guess about the future paired with a confidence interval or likelihood. He contrasts this with a deadline, which is a commitment device, not an estimate. Deadlines operate on psychology via Parkinson’s Law and are used to mitigate risk, but missing an estimate is different from missing a commitment—one is an incorrect guess, the other is a broken promise.
  • 00:13:16 — Three frameworks for estimating undefined work — The host introduces three tactical approaches for estimating work that isn’t well-defined. The first is affinity or relative estimation, where you compare the new work to similar past projects the team has completed, using metrics like story points or cycle time from those ‘reference classes’ to gauge the new effort.
  • 00:16:22 — The PERT three-point estimation method — The second framework is PERT, a three-point estimation technique. You gather optimistic, pessimistic, and most likely scenarios from the team, then apply the formula (O + 4M + P) / 6. This creates a weighted average that leans toward the most likely case while accounting for extremes, offering a more statistically grounded guess.
  • 00:18:51 — The value of small discovery and key assumptions — The third method involves asking for a small amount of discovery time. The host explains that initial investigation yields the highest ROI in reducing uncertainty. He advises identifying the one or two ‘principal components’—assumptions or factors that could explode the scope—and stating these explicitly in the estimate. This buys certainty and clarifies the estimate’s boundaries.
  • 00:25:09 — Conclusion and recap of estimation principles — The host concludes by reiterating that a true estimate is a range with a confidence interval. Combining the three approaches helps decrease the range size and improve confidence. He acknowledges more complex factors like dependencies weren’t covered, but for simple projects, these techniques improve ‘blind estimates.’ The episode ends with a teaser for a future episode on New Year’s resolutions.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2024-12-17T08:00:00Z
  • Duration: 00:27:10

References

Podcast Info

Transcript

[00:00:00] With the end of the year comes a lot of reflection and time looking back.

[00:00:18] But for most of us, it also comes with a lot of looking forward, forward

[00:00:24] looking planning for, for example, Q1.

[00:00:28] I want to talk a little bit about planning and some of the pitfalls

[00:00:33] that I’ve seen in my career and that you’ve probably seen in your career

[00:00:37] as well in the planning process and specifically as it relates to

[00:00:43] planning ill-defined work in most startup environments, work is not

[00:00:50] extremely well-defined before the organization wants to make a decision

[00:00:57] about whether they’re going to invest in it.

[00:01:00] And so the organization wants to lean a bit on the engineering teams,

[00:01:05] the implementation teams, design, et cetera, to provide some kind of price tag.

[00:01:12] And I say this in this particular way, because I want you to shift your

[00:01:17] frame of thinking into your leader’s frame of thinking.

[00:01:22] The people who are trying to make the decisions about what kind of work

[00:01:26] are we going to pick up next?

[00:01:28] This question is looking for some kind of information in order to make that

[00:01:35] assessment, in order to make that decision.

[00:01:39] The leaders who are determining what projects to pick up next, probably

[00:01:44] have some concept of a budget, mostly in terms of resources or FTEs, for example.

[00:01:52] And they want to evaluate projects based on their expected cost

[00:01:57] and their series of benefits.

[00:02:01] If you’re in a highly tuned kind of metrics driven organization, these

[00:02:07] projects are theoretically spread across your, you know, for example, your OKRs.

[00:02:13] If you are in an organization that is early in the startup phase, then you’re

[00:02:18] probably looking for quick wins, ROI, that is realized as soon as possible.

[00:02:24] There’s a lot of different strategies that these decision-making kind

[00:02:29] of efforts would be going towards.

[00:02:33] But for the most part, what they’re trying to do is identify some point of

[00:02:37] value, and this works both in agile environments as well as in waterfall

[00:02:43] environments. So you’re looking for some delivery point and the cost to get to

[00:02:49] that delivery point compared to the benefits of getting to that delivery

[00:02:53] point. This simple ROI calculation, of course, turns out to be more complex in

[00:03:00] reality. But in order to make reasonable decisions with as limited level of

[00:03:05] information, these simple factors need to be condensed down into the simplest

[00:03:12] form possible, which is why you are being asked right now, probably, for

[00:03:18] estimates. How long would this take?

[00:03:22] But if your organization is like many organizations, the investment to define

[00:03:28] the work down to its clearest, smallest format may not necessarily be done or

[00:03:34] perhaps is done for some work and not done for others.

[00:03:38] In this episode, I want to give you some tactical advice for how you might

[00:03:43] estimate when the amount of information is limited.

[00:03:49] First, let’s talk about today’s sponsor.

[00:03:51] Maybe you have nightmares of building with the old school website, automatic

[00:04:09] slicers like Dreamweaver or something.

[00:04:11] So when I say website builder, you’re probably thinking, oh, that’s limited

[00:04:15] control. It’s not really useful for me.

[00:04:18] But what about a node based builder that lets you add full stack JavaScript code

[00:04:23] to any site that you have with Wix Studio?

[00:04:26] You can spend less time on your UI coding and fiddling, hosting, security,

[00:04:32] and more on the custom logic and functionalities that actually matter to

[00:04:36] your business. Develop in your preferred coding environment online in a VS code

[00:04:41] based IDE or locally through a GitHub integration.

[00:04:44] Either way, with Wix Studio, you’re deploying in a click.

[00:04:48] You can extend and replace hundreds of powerful business solutions and custom

[00:04:53] built features with APIs and integrations.

[00:04:55] And when you need to speed things up, Wix Studio’s AI assistant is on hand to

[00:04:59] generate tailored code snippets, troubleshoot bugs, and retrieve product

[00:05:03] answers in just seconds.

[00:05:06] All of that is neatly wrapped up into an automatically maintained infrastructure

[00:05:10] for total peace of mind.

[00:05:12] Work in a developer first ecosystem.

[00:05:14] Go to wixstudio.com.

[00:05:16] That’s w i x studio.com.

[00:05:19] Thanks again to Wix for sponsoring today’s episode of developer team.

[00:05:33] How do we estimate the unknown?

[00:05:38] We may take a few episodes to talk about estimation because it is a fundamentally

[00:05:43] interesting and deeply psychological process.

[00:05:48] Um, and, and most people are used to doing estimates in only one very narrow way.

[00:05:55] I want to talk about a couple of different ways to approach this, this problem.

[00:05:59] Um, understand that the concept of estimation means something a little bit

[00:06:05] different to most other people.

[00:06:08] And so if you were to ask, let’s say, uh, any given engineering leader, what

[00:06:14] an estimate means, they might say, oh, it’s the number of story points

[00:06:17] that you put on a story.

[00:06:19] Someone else might say, what’s the date that you expect to get something done by?

[00:06:24] The truth is it can be parts of both of those things, but estimates are largely

[00:06:30] some guess about the future combined with some idea of how likely that guess is.

[00:06:38] Okay.

[00:06:39] So think about this very, very clearly here, some guess about what will

[00:06:43] happen in the future paired with some likelihood or some confidence that

[00:06:48] that’s going to actually happen in many ways.

[00:06:51] These are like casting bets, bets on, for example, a sports event.

[00:06:58] If you notice bets are always cast in virtually every sports event in both

[00:07:03] directions.

[00:07:04] And the reason for this is because no matter what we do, there’s always some

[00:07:10] level of uncertainty before something happens, there’s always some potential

[00:07:17] that the underdog will win in your estimates, uh, for, for your work.

[00:07:25] There may be some, uh, you know, unlikelihood that you would consider disqualified.

[00:07:31] In other words, there’s no way that we get it done this week.

[00:07:34] There’s a 0% chance of that happening.

[00:07:36] But as you extend further out your confidence interval, uh, if, if you’re

[00:07:43] going with a date based or date range based estimate, you could say, okay,

[00:07:47] it’s going to get done in two to three weeks, or it’s going to get done in two

[00:07:51] to three months, your confidence interval will go up as that time increases.

[00:07:57] Because in virtually every case, the more time you have, the more likely

[00:08:02] more is getting done.

[00:08:03] And so as you accumulate the, you know, the, the completed work in a body of work,

[00:08:09] you are estimating the likelihood going up and the further out you go, the higher

[00:08:15] the chance is that you’ve accumulated enough to complete that body of work.

[00:08:19] So that’s the basic idea, uh, kind of defining an estimate, some, uh, guess

[00:08:25] about the future with paired with some confidence interval.

[00:08:30] So what is not an estimate?

[00:08:33] Well, a single date that you are saying something will absolutely be done by.

[00:08:38] Deadlines are not estimates.

[00:08:40] So that’s the key differentiator.

[00:08:41] I want you to walk away with a deadline is not estimated as specific

[00:08:45] concrete date is not an estimate.

[00:08:47] Usually, usually, uh, companies are using those specific

[00:08:53] deadlines as a commitment device.

[00:08:56] All right.

[00:08:57] And a commitment device operates on our psychology in a bunch of different ways.

[00:09:02] All right.

[00:09:02] So a couple of those ways, one, uh, if you have a clear deadline, then

[00:09:08] you have created a container.

[00:09:12] This is following Parkinson’s law.

[00:09:14] The idea is that work will fill the time that you’ve allotted for its completion.

[00:09:20] Right?

[00:09:20] So if you were to set a shorter deadline, then Parkinson’s law states

[00:09:24] that you would theoretically finish that, that work in a shorter amount of time.

[00:09:30] Parkinson’s law, I think needs to be balanced out with what is actually feasible.

[00:09:35] That is if you set a very long deadline, it’s very likely that the project is not

[00:09:40] going to complete until that very long deadline, but you can’t set an arbitrarily

[00:09:46] short deadline and expect it to have the same effect.

[00:09:50] Now, why is this important?

[00:09:52] Well, I want you to understand the difference between a commitment,

[00:09:57] the deadline and an estimate.

[00:09:59] All right.

[00:10:00] But I also want you to be able to set or, or meet deadlines that are reasonable

[00:10:07] because this is a very difficult to learn skill, but one that is highly valued.

[00:10:13] Now, in my opinion, deadlines are far too often abused and can sometimes

[00:10:20] lead to unnecessary stress and unnecessary stressful environments.

[00:10:27] But if you can learn how to set deadlines in a way that is less stressful and is

[00:10:33] more like a Parkinson’s law trigger, that is, let’s say that you had a

[00:10:38] confidence interval of 90% and you set a deadline that is near that 90% mark.

[00:10:45] Then it’s possible.

[00:10:47] It’s possible that the deadline will help avoid a scope creep.

[00:10:52] For example, right?

[00:10:53] You’ll have to have to make some harder decisions because you’re

[00:10:57] facing the deadline upcoming.

[00:11:01] Okay.

[00:11:01] So understanding that deadlines are commitment devices.

[00:11:06] Very often they are intended to mitigate risk.

[00:11:10] Uh, that risk being, you know, whatever that remainder 10% risk is.

[00:11:15] In your original estimate, a deadline or a commitment, um, helps you avoid that

[00:11:21] 10%, right?

[00:11:22] Because the commitment is saying, I’m going to do whatever I need to do to

[00:11:28] reduce that risk to zero on behalf of the company, or else my, my personal

[00:11:33] reputation or the team’s reputation is put on the line for missing a commitment.

[00:11:40] Now understand that, again, the psychology difference here, missing

[00:11:43] an estimate versus missing a commitment, missing an estimate is essentially

[00:11:49] saying, well, it seems like our guess was incorrect.

[00:11:53] It’s squaring with the reality of the risk that’s inherent.

[00:11:57] That’s a part of your estimate.

[00:12:00] Missing a commitment is saying, well, I believed that something was doable.

[00:12:05] I told everyone that I would lay out in order to make it doable, but

[00:12:10] unfortunately it wasn’t doable.

[00:12:13] It’s important to understand that most organizations for better, for worse,

[00:12:18] use deadlines, they use deadlines mostly once again, as a risk mitigation tool.

[00:12:24] But it’s also important to understand whether the deadline is real.

[00:12:29] In other words, what are the actual consequences both for the business, but

[00:12:34] also for the teams, if they actually miss a deadline, does this come back on, let’s

[00:12:42] say a performance review, what happens if you miss one deadline versus missing

[00:12:47] multiple deadlines without knowing what the consequences of missing the deadline

[00:12:52] are, the arbitrary pressure of the deadline takes over and our imaginations

[00:12:59] fill in the blank with the worst possible thing.

[00:13:02] This can be even more stressful than just having a deadline.

[00:13:07] Okay.

[00:13:08] So enough talk about deadlines.

[00:13:10] I do want to give you some practical advice once again, for estimating

[00:13:13] work that is not well defined.

[00:13:16] Okay.

[00:13:16] I’m going to give you three very quick frameworks for doing this or tactics,

[00:13:20] ways of managing this kind of estimation.

[00:13:23] The first is called affinity estimation or relative estimation.

[00:13:27] You probably have done something kind of like this with t-shirts, but I’m going

[00:13:30] to teach you a slightly different path for this.

[00:13:33] If you have, let’s say a body of work that’s about an Epic.

[00:13:38] So let’s say eight to 12 items.

[00:13:43] It could be eight to 12.

[00:13:45] It could be 20, or it could be five.

[00:13:47] How do you know without breaking the work down?

[00:13:50] Because let’s say you’re, you’re not, you don’t have enough time to actually do

[00:13:53] the discovery before the estimate is needed for that planning process.

[00:13:58] For example, without breaking that work down, how could you make a pretty

[00:14:03] reasonable guess as to about how much work this is going from five to

[00:14:08] 20, that’s four times as much work.

[00:14:10] So which one, you know, where should we lean?

[00:14:13] My recommendation is you talk to the team, especially the team members who

[00:14:18] have been on this team long enough and have worked on something

[00:14:22] that is similar before.

[00:14:25] Right.

[00:14:25] So something that they’ve done before that they would say, yeah, this

[00:14:30] is about the same level of complexity, about the same amount of work.

[00:14:34] All right.

[00:14:35] Even better if you could find two or three of those and then identify,

[00:14:40] you can do multiple things.

[00:14:41] If you’re using something like story points, you could total up the story

[00:14:45] points in those, what are called reference classes, those previous bodies

[00:14:49] of work that this team has done that are similar to this one, you could total

[00:14:54] up the number of stories.

[00:14:55] If you’re not using story points, you could look at the cycle time, assuming

[00:14:58] that the team was totally focused on those, uh, on those efforts before.

[00:15:03] Could you look at the, the amount of time that those efforts took and apply

[00:15:07] a similar, uh, estimation for the new one?

[00:15:11] Right.

[00:15:12] So, uh, what you’re doing is you’re trying to get something that is a little

[00:15:16] more and then a little less, and then something that’s right in the middle.

[00:15:21] All right.

[00:15:21] Something that, uh, the team says, oh yeah, this is, this is right on.

[00:15:25] This is something that is very close.

[00:15:27] Something that’s a little more or something that’s a little less.

[00:15:30] If you had both of those, you could estimate somewhere in the middle.

[00:15:33] Right.

[00:15:34] So again, the goal is, is to shift the conversation away from trying to do a

[00:15:39] bunch of technical specification and guessing about the actual work to be done

[00:15:44] and instead use something that humans are very good at, very, very good at,

[00:15:49] which is relative comparison.

[00:15:52] Okay.

[00:15:52] We would have a better intuition, a better natural approach to comparing this new

[00:15:58] body of work to a previous body of work that we’ve done before.

[00:16:03] So this is what affinity estimates are.

[00:16:05] There is some affinity or connection, uh, that this is similar or, or it is,

[00:16:12] um, you know, tied to this other thing.

[00:16:15] They are alike in some way.

[00:16:18] The second is a kind of a modified version of this.

[00:16:22] If you were to take, uh, you know, those, the, the affinity highest, uh, the

[00:16:28] affinity lowest and the affinity middle, you can apply something called Pert.

[00:16:35] And this is a three point estimation and it involves taking these three points,

[00:16:40] right?

[00:16:41] The, the lowest, the medium or the most likely and the highest and running them

[00:16:47] through a really basic, essentially a distribution, or I’ll give you that

[00:16:53] formula in just a second.

[00:16:54] Another way that you can get the lowest, medium and highest is to use the same

[00:16:59] concept, uh, but use your team’s kind of, uh, uh, you know, swag guesses.

[00:17:05] In other words, asking your team, look at this work and tell me what is the worst

[00:17:10] case scenario, what is the absolute best case scenario, or in other words,

[00:17:15] optimistic and pessimistic.

[00:17:16] And then what is the most likely scenario?

[00:17:19] Once you have all of those numbers from your team, you can average for each of

[00:17:23] those three points and then it’s a basic calculation.

[00:17:27] You take the worst case, you add it to four times the most likely case and

[00:17:36] then add that to the best case scenario and then divide all of that by six.

[00:17:43] So the idea is you have, you know, six possible, uh, kind of inputs to this thing.

[00:17:48] One will be the worst case, one will be the best case and the other four will be

[00:17:52] the likely case, the kind of the middle ground, uh, between all of these.

[00:17:57] This creates a distribution that you’re pulling essentially a

[00:18:01] mean point on this distribution.

[00:18:04] And if you plug in some, some kind of fake numbers for this, you can see that

[00:18:09] a very high worst case is going to skew the number, but it’s not going to skew

[00:18:12] it completely because we’re waiting, uh, we’re waiting the total average, um,

[00:18:18] towards the middle, towards that most likely case.

[00:18:21] So this is a really useful method because it allows you to take in multiple

[00:18:26] inputs and it tries to approach something like a, a statistical or a

[00:18:34] statistically backed approach to this.

[00:18:37] Um, so, so you’re still using judgment in this case, right?

[00:18:40] Um, you know, it’s hard to get away from judgment when there’s not

[00:18:44] a lot of information available.

[00:18:47] The last method I want to talk to you about is, is breaking the rules a little

[00:18:51] bit because you’re going to have to ask for a very small amount of discovery time.

[00:18:56] Okay.

[00:18:57] Instead of saying, well, I can produce this in three hours.

[00:18:59] You might ask for, let’s say three days or maybe a week.

[00:19:03] And the idea here is once again, based on an interesting statistical

[00:19:08] phenomena, uh, around uncertainty.

[00:19:12] Specifically, before you do any kind of investigation into the work that

[00:19:18] is associated with, uh, you know, a particular work item, let’s say, you

[00:19:23] know, this, this is something that is on the order of about a quarter worth of

[00:19:27] work before you do any kind of investigation at all, the theoretical

[00:19:33] uncertainty, we’ll talk about what that means in just a minute, but the

[00:19:35] theoretical uncertainty is at its absolute maximum, potentially an infinite

[00:19:41] level of uncertainty.

[00:19:43] Now it’s very likely that the practical uncertainty here is, it is much

[00:19:47] lower than the theoretical uncertainty.

[00:19:50] The theoretical uncertainty would say that there’s some amount of work here

[00:19:54] that is impossible to do with all of the time, uh, you know, in the universe.

[00:19:59] Right.

[00:20:00] That’s a theoretical uncertainty.

[00:20:01] It’s extremely unlikely.

[00:20:02] We can probably rule that out, but even if we’re only talking about a practical

[00:20:07] uncertainty, for example, this might be a year of work, right?

[00:20:13] It might be an entire year of investment.

[00:20:17] We don’t know because we’ve done virtually no investigation into what

[00:20:21] this work is, but you know, the maximum we can imagine, uh, without doing any

[00:20:26] further investigation is a year working from that assumption, the first bit of

[00:20:32] information you get is the most valuable.

[00:20:38] Well, let me explain what I mean.

[00:20:40] The smallest amount of investigation is likely to yield large improvements.

[00:20:47] The largest improvements in your refinement of your estimation.

[00:20:54] Think about it.

[00:20:55] If you have a ton of uncertainty, possibly this is, this could take a year

[00:21:00] with that level of uncertainty, you are likely to learn in the very first pieces

[00:21:05] of information about this work, that it’s going to take much less than a year.

[00:21:12] Perhaps you can cut that estimate by up to 50%.

[00:21:16] A small investigation might lead to a major increase in your

[00:21:21] confidence in your first estimate.

[00:21:25] You could go very easily from a 10 or 20% confidence to a 50% or

[00:21:30] 60% confidence in your estimate.

[00:21:33] Later refinements have a much lower ROI.

[00:21:38] In other words, uh, you know, trying to determine exactly how long something

[00:21:42] will take down to the, let’s say day is extremely difficult.

[00:21:47] And in fact, most often it is not worth the time, the time you’re spending

[00:21:53] investigating or planning will exceed the time that it would take to actually do

[00:21:59] the work.

[00:22:00] And so it’s an inverted kind of economic situation.

[00:22:04] This actually does happen in a lot of workplaces.

[00:22:07] There’s a lot of reporting and status and kind of, uh, communication that happens

[00:22:12] that exceeds the cost of actually doing the work.

[00:22:16] You’ve probably experienced this in your workplace before, but in the earliest

[00:22:21] phases, that is completely flipped the other direction.

[00:22:25] And the smallest amount of investigation is going to yield major, major

[00:22:29] improvement.

[00:22:30] So here’s my recommendation, okay.

[00:22:33] In order to provide an estimate on something that is not well defined, try

[00:22:39] to identify the one or two areas that could drastically change your estimate.

[00:22:46] Okay.

[00:22:46] These are kind of principal components of a longer estimate.

[00:22:51] So the way you would do this is talk to the team and say, okay, what exactly

[00:22:55] could happen that would make the scope of this completely unattainable?

[00:23:01] Or would, would absolutely explode the scope on this project.

[00:23:06] And what they’re going to come back with is probably three or four things,

[00:23:09] depending on how big the project is.

[00:23:12] They may say, well, if, uh, as long as we don’t have to worry about external

[00:23:15] vendors, or as long as we don’t have to worry about compliance, or if we can do

[00:23:19] this work after, if we can sequence it after we do this other work, then it

[00:23:23] cut cuts down a lot of the potential complexity.

[00:23:26] These are areas that you can provide as a part of your estimate, right?

[00:23:32] When you’re coming back and you say, okay, here’s some

[00:23:34] assumptions we are making these assumptions.

[00:23:37] This is really critical.

[00:23:38] These assumptions are buying you.

[00:23:42] Okay.

[00:23:42] You’re they’re buying you a lot of extra certainty in your estimates.

[00:23:47] If you put that leader hat back on and, you know, imagine that they’re purchasing

[00:23:52] something, they’re purchasing a car and your assumption is, well, if you choose

[00:23:56] a standard color, right, if you choose a car with a standard color, then it’s

[00:24:01] going to be much more affordable than if we have to, you know, uh, wait for the

[00:24:06] car to have a custom color or custom paint job, uh, applied overall, these

[00:24:11] three different approaches can, they can all be combined, right?

[00:24:16] Uh, these three approaches can help you wrangle some of the less defined work

[00:24:22] that may be sitting in front of you to estimate it’s very difficult to estimate

[00:24:26] work already, but choosing some approach that doesn’t try to dig into the specific

[00:24:32] details because you probably don’t have time to do that, but isn’t just a wild

[00:24:37] guess without any kind of, uh, you know, mitigation for the risks of that wild

[00:24:42] guess and is also a true estimate, a true estimate, a true estimate is some

[00:24:49] kind of range, a low and a high range, as well as a confidence interval.

[00:24:54] This is a guess about the future or the confidence interval.

[00:24:57] Taking one of these three approaches is likely to decrease the size of the

[00:25:02] range and it’s also likely to improve your confidence intervals.

[00:25:09] Thank you so much for listening to today’s episode of developer

[00:25:12] T. I hope you enjoyed this discussion.

[00:25:13] I hope it’s useful to you if you’re planning for the next couple of months

[00:25:17] of work, or if you’re an engineer on a team and you’re trying to understand how

[00:25:21] do we do all of this in such a short amount of time, I encourage you to share

[00:25:25] this, share this episode with whatever, uh, engineering leader you think needs

[00:25:29] to hear it, um, this by no means is the full picture, of course, we didn’t even

[00:25:34] talk about things like dependencies or, uh, you know, ongoing work, multiple

[00:25:38] work streams, uh, we didn’t talk about saturating those work streams.

[00:25:42] So there’s a lot more complicated stuff that we could get into, but for the

[00:25:47] sake of the simplest projects, these three techniques are going to be a

[00:25:51] very useful approach to improving your kind of blind estimates.

[00:25:57] Thanks so much for listening.

[00:25:58] Thank you again to today’s sponsor.

[00:26:00] WIC studio with WIC studios, developer first ecosystem.

[00:26:03] You could spend less time on tedious tasks and more time on the functionality

[00:26:07] that actually matters to your customers, to your business develop online in a

[00:26:12] VS code based IDE, or you can develop locally using GitHub, you can extend

[00:26:16] and replace a suite of powerful business solutions and ship faster with WIC

[00:26:20] studios, AI code assistant.

[00:26:23] All of that is wrapped up in an automatically maintained

[00:26:25] info for total peace of mind.

[00:26:27] We’re going to develop our first ecosystem by heading over to WICs studio.com.

[00:26:32] Thanks again to WIC studio for sponsoring today’s episode of developer team.

[00:26:36] As we approach the end of the year, we are likely to have a couple of

[00:26:39] weeks where we don’t have episodes.

[00:26:42] I’m going to try to put out an episode next week, uh, to talk a little bit

[00:26:47] about goal setting and, uh, and to discuss the new year’s resolutions.

[00:26:52] We talk about this every year on the show to talk a little bit more in depth

[00:26:56] about resolutions and how to make them work better for you.

[00:26:59] So look out for that episode next week and until next time, enjoy your tea.

Visão de gráfico