--- > Estimations help prevent under- or over-commitment of resources. You don't want to leave your team stranded in a sea of unfinished tasks, nor do you want them twiddling their thumbs because you thought it'd take six - [View Highlight](https://read.readwise.io/read/01h14ssvbpvp188tc8d9s9fpt8) --- > Estimations create a shared understanding of the project size among team members and stakeholders. When everyone's on the same page about what needs to be done and when it's due, collaboration is more effective, and your team can focus on what they do best - writing kickass code - [View Highlight](https://read.readwise.io/read/01h14stfb3ngy7n80g5rmy4x46) --- > Estimations help you, as an engineering manager or startup founder, to maintain a semblance of sanity in the face of constant deadlines and deliverables. By knowing how long tasks should take, you can make informed decisions about priorities, allocate resources effectively, and maybe even get some sleep at night. - [View Highlight](https://read.readwise.io/read/01h14sv7j0rn2kjvh4jtf6cxmn) --- > you can’t account for thousands of unknowns, so the estimates should be on the safe side first and get shorter over time, not the other way around. - [View Highlight](https://read.readwise.io/read/01h14swr7rr7p3xjw3bexz1svt) --- > **No two projects are the same:** Sure, there may be similarities, but there's always a twist that'll throw a wrench in your well-laid plans. The key is to learn from past experiences and apply that knowledge to future projects. - [View Highlight](https://read.readwise.io/read/01h14sy463dqd3mrsjp3e61mb2) --- > Requirements change, stakeholders change their minds, and unforeseen challenges pop up like a bad case of acne. The best you can do is remain calm and adaptable and ensure your estimations have some buffer for the “human factor.” - [View Highlight](https://read.readwise.io/read/01h14t54y5xj42f3rpqst6gcw8) --- > I usually add 20-25% on top of the estimates - [View Highlight](https://read.readwise.io/read/01h14t5nx00bkxbmd6jygz76nd) --- > Keep the lines of communication open and clear, and you'll save yourself a world of pain. Remember — it’s better to over-communicate than to expect people to communicate with you first. - [View Highlight](https://read.readwise.io/read/01h14t6eazza30h713tpp5saa7) --- > Plucking numbers out of thin air is a surefire way to disappoint everyone involved. Base your estimations on data, past experiences, and input from your team, not wishful thinking. - [View Highlight](https://read.readwise.io/read/01h14t7xtnxc41nwtvbndbejqs) --- > Assuming that every task will take the same amount of time is a recipe for disaster. Different tasks have different complexities and require different skill sets. Consider these factors when estimating. - [View Highlight](https://read.readwise.io/read/01h14t8s0rwxkwsagntweqq37d) --- > Don't forget to account for meetings, code reviews, and other non-coding activities that will inevitably eat into your team's time. Failing to do so will leave you with overly optimistic estimations and a whole lot of explaining to do. ... Rule of thumb, 1.5x-2x your raw coding time estimation to get a good approximation of the real-time (incl. communication) you will spend on a task. --- > If you think your initial estimate is set in stone, you're setting yourself up for failure. Be open to revising your forecasts as new information becomes available and the project progresses. - [View Highlight](https://read.readwise.io/read/01h14tc4z4mv0gfxw90hg8p1mz) --- > my system does have one critical characteristic that I believe any effective estimation technique should have: it **captures both time and uncertainty**. An estimate that only includes time implies a high degree of certainty: if you tell me “that will take 10 days”, and we have a deadline 14 days out, I’ll assume we’re in great shape. If, on the other hand, we have that same deadline but you tell me “that will take 10-15 days”, now I know our deadline is at risk. - [View Highlight](https://read.readwise.io/read/01h14ttspqk8kfbp73eqcte9ht) --- > Initially, you might think of capturing a best-case and worst-case scenario, but I don’t find that too useful. Instead, I prefer to capture expected-case and worst-case. Coming in *early* is never a problem, and in my experience, the best-case rarely happens. But it is important to capture how long something *could* take if things go poorly. Therefore, my uncertainty system starts with the expected time (captured above), and then applies an “if-things-go-wrong” multiplier - [View Highlight](https://read.readwise.io/read/01h14tx9vfg9r1hx75wx7k1cpv) --- > **Break tasks down into manageable units:** Large tasks can be overwhelming and difficult to estimate accurately. - [View Highlight](https://read.readwise.io/read/01h14v0e79trkd5v7spdxgfpqt) --- > Familiarize yourself with estimation techniques, such as Planning Poker or Wideband Delphi, which can help your team reach a consensus. If you have the time, especially in a big corporation, you can use those techniques to greatly increase the estimate accuracy. - [View Highlight](https://read.readwise.io/read/01h14v1z9h0fq76b0ct4z2hkmx) --- > Instead of providing a single estimate, consider offering a range that reflects the degree of uncertainty involved in the task. This will help set realistic expectations and allow flexibility as the project evolves. Though sometimes people only hear the lower band, so you must explicitly mention that it’s a range and that “At least a year” does not mean “It will take us exactly a year.” - [View Highlight](https://read.readwise.io/read/01h14v3tv3waqmezcc5e8emd4j) --- > Learn from more experienced developers (you’re already here, so good on you!) who have honed their estimation skills over time. - [View Highlight](https://read.readwise.io/read/01h14v47djrgtjs6ywjk3wpb7c) --- > If your estimate is five weeks but your manager/senior dev/someone else wants it to be 3 weeks — stick to your guns. Unless there are objective reasons to refine your estimate, there’s absolutely no good outcome if you give in to some persuasion to lower it. - [View Highlight](https://read.readwise.io/read/01h14v50q6ksb1zwjpq9x68fap) - _Tags_: `favorite` --- > Regularly assess your team's progress and compare it to the initial estimations. This will help identify any discrepancies and allow you to address them promptly. Be honest and prompt if you think something is awry or not going as planned. - [View Highlight](https://read.readwise.io/read/01h14v62qm3y4sknjfcr3zpg56) --- > As you reach significant milestones, take the opportunity to reevaluate your estimations. This can help you identify any changes in scope, new requirements, or other factors that may impact the project timeline. ... It’s a crucial time to voice concerns for the next phase so everyone is aware if there’s a delay. --- > If your estimations need to be adjusted, ensure all stakeholders are informed and on the same page. Transparent communication is vital in managing expectations and maintaining trust. - [View Highlight](https://read.readwise.io/read/01h14v8tmc1trw5ymt4mwcbbd3) --- > You can think of your manager as a spider trying to process information from the different webs they have put in and making sure that none of them snap. - [View Highlight](https://read.readwise.io/read/01h14v9m5w1nvvpy335gz9as7r) --- > Don't wait for your manager to come to you for updates. Instead, take the initiative and share your progress, any potential roadblocks, and changes in estimates. - [View Highlight](https://read.readwise.io/read/01h14v9yevsq1srn9r1h3rx7k8) --- > Your knowledge as a developer is invaluable in project planning. Share it. Help your manager understand the technical aspects of the project - [View Highlight](https://read.readwise.io/read/01h14vae5g56f9rkghc4ab7x1k) --- > If you have doubts — speak up. Work with your manager to identify potential risks and develop mitigation strategies. Think of worst-case scenarios, and prepare for them. - [View Highlight](https://read.readwise.io/read/01h14var5yymzkv0g27exj2p6t) --- > The environment you work in plays a significant role in how accurate your estimations can be. A supportive work culture that values collaboration, communication, and learning from mistakes will enable you and your team to provide better estimates. - [View Highlight](https://read.readwise.io/read/01h14vbrk0r2p0hva72339p5wm) --- > Failing is normal across many industries where experimentation is encouraged. You should normalize that and ensure people don’t fail twice with the same mistake — documenting the experiences and post-mortems. - [View Highlight](https://read.readwise.io/read/01h14ve14aaymfrxeeb8w0gd65) --- > A flexible work culture that embraces change and is open to trying new techniques or methodologies can help the team discover more effective ways to estimate tasks and manage projects. - [View Highlight](https://read.readwise.io/read/01h14vepb4b2ffwbq6wx7x0r5p) --- > A work environment that promotes collaboration across all seniority levels can lead to more accurate estimates as team members share their expertise, helping each other improve. Even interns/junior developers should share their thoughts on the estimates — this allows them to learn from their seniors and try their hand at imagining how they would build this specific task. - [View Highlight](https://read.readwise.io/read/01h14vhva2edh4s80987a9vc77) ---