What exactly is a “guesstimate”? Well, it’s an approximate estimate made without knowing all required information necessary to make a proper estimate.
When it comes to estimating, there are a lot of factors that come into play and even then, you might not have the full picture. While you might think, “it’s ok, I’ll come back to it”, that might not always be possible. Sometimes pressure is on and you need to provide some kind of number - days, weeks, hours, months - who knows.
This is where guesstimates comes into play. I’m not saying, use this approach all the time, but it can help you in a pinch. Similarly to estimating, you can use the following 10 steps to improve that guesstimate. You might find you don’t need all 10 steps but rather you might just need to pick and choose which are appropriate.
Understand the Context
Just as you would when you’re estimating, you’re going to need to understand the problem, scope, stakeholders, success criteria and whether there are external factors and what the availability of resources is like.
A question to ask yourself is have I been in this situation, faced a similar problem, or had to deliver something of approximately the same value or capability?
Identify Key Parameters
This is ultimately the variables like, cost but in terms of Sitecore, it could be, number or types of fields or rendering parameters, number of components, APIs, etc. Gathering all these together you can then prioritize them, identify any interdependencies, or validate any assumptions.
It’s also a good time to account for uncertainty. Some factors might have more uncertainty than others. Are there questions you can ask to reduce that uncertainty?
Use Available Information
Ultimately this is relying on things like documentation, but also potential past projects that perhaps had similar requirements. Maybe you built a nearly identical component or page or site prior. Perhaps you even have both the estimate you provided back then and then the actual time it took to complete.
These analogous situations can help you draw parallels between the two. You may be required to justify your response and this is a great way to do that.
Breakdown the Problem
Clearly defining the problem and the desirable outcome reduces complexity and confusion. By breaking down the problem into smaller chunks, we can more easily digest the solution mentally and visualize the steps necessary to deliver the solution.
Use Reasoning and Logic
This might be, in my opinion, the most powerful of all steps. And that might seem obvious, but let me explore why. As part of exploring a challenge, we can look into the following aspects:
- Patterns and trends
- Cause-and-Effect relationships
- Plausibility
Let’s take a look at each.
Patterns and Trends
Identify patterns, connections, or associations among variables that offer understanding of the issue or challenge at hand. If we’re building a component, are there sub-components we are able to build to improve efficiency? Have we already built something similar?
Cause-and-Effect Relationships
Think about the potential effects that changes to one part of the issue may have on other components. This enables you to make more educated assumptions and to foresee the possible effects of your decisions.
Plausibility
Think about if your presumptions make sense based on empirical data, well-established facts, or common sense. If an assumption appears implausible or goes against accepted wisdom, review your logic and modify your strategy. If you’ve been building components one way, but in order to build something another way, could that impact the delivery? Is it a valid choice to alter the component design to make this one work?
Sensitivity Analysis
Numerous disciplines, including finance, engineering, project management, and decision sciences, frequently use sensitivity analysis. It offers insightful information on the factors that contribute to uncertainty and unpredictability in complex systems, assisting decision-makers in reducing risks and making better decisions.
Consult Experts / Other Developers
It’s highly likely you’re not working on this alone. Even if you’re the only developer on the project, there are likely others at your company, or even in the community you might be able to ask pertinent questions to that will improve confidence in your response.
Document Assumptions
Ensuring you keep track of the problem, questions, answers, acceptance criteria and communications leading up to your guesstimate will reduce anxiety for both the project manager and likely the client. It will show them that you’ve taken into account as much as you can before just jumping to a number.
Communicate Uncertainty
If you don’t know, or you are simply flat out uncertain as to what the estimate could be, there’s no shame in acknowledging it. Telling your project manager that, “I need more time” or “I need to take this information away” is a valid response. There might still be some urgency but providing a reasonable estimate on the spot can be at times nearly impossible.
Iterate and Refactor
Lastly, you can only get better at your guesstimates by doing it, taking note of your accuracy and then applying that reasoning again. Rarely are guesstimates accurate the first time. Iterating entails going over and improving your analysis again and again in response to fresh data, criticism, or altered conditions. You can add new information, revise assumptions, and increase the precision of your estimations with each cycle.
If you’re not on your first project, you likely have experience you can apply to a guesstimate that would be on solid footing. It might seem like everything above is just a natural part of estimating, and it largely is. The expectation here though is that you can apply this reasoning faster, not having to always go through all the steps, and you’ll improve your speed at coming to the number you need.
