How long do you think it'll take?
As builders and creative people, we are all too familiar with that question. Getting estimates right is incredibly difficult and it's a skill that we learn slowly over time as we gain more experience building and shipping projects.
So why is this simple exercise so difficult? Oftentimes it's because we forget to ask the right questions and make assumptions that may not be correct. Let's examine what are these questions that we should be asking and break them down into phases.
Scoping — What is being requested and when is it needed?
Don't assume what you think of as “done” is the same as what the party asking for an estimate would call, “done”. It is important to explicitly call out the timeline and specific deliverables before doing the exercise of estimation.
So part of that is first understanding what you are being asked to estimate. Make sure what you have in mind is an acceptable outcome for the stakeholder. If you don't already have it, make a list of user personas and stories to align on the requirements with the stakeholder and decide on what will be in scope.
Secondly, understand the user group that should be targeted as part of the delivery timeline. For example, will the product be shipped in phases such as internal, friends & family, early access, general availability, etc? If so what does our estimate aim for? Be explicit about which release phase you are estimating for.
Technical Exploration — How will it be built?
To provide a good estimate there has to be some level of understanding of the existing system and how to go about making changes in it.
You can never know exactly all the steps you may need to take but there has to be a certain degree of confidence. Anything below 70% confidence would warrant a technical exploration or a spike to get a better understanding of the required effort.
If you are going to touch a particular aspect of the system, take the opportunity to leave it in a better state than you found it in. This is a good time to identify if there are any long-standing hotspots or technical debt that could be addressed as part of this task. Even small incremental improvements will help keep the system maintainable over the long run.
Capacity Planning — What is the level of effort?
The next step in formulating an estimate is to get a handle on the capacity. For example, based on the technical exploration, you may think something might require one week of effort. This is the most common step where the estimation effort derails.
We are not done. We still have to further refine that and ask, “Is it one week of an average engineer's time? Or is it specifically your time?”
If you are estimating for yourself, does that account for all the meetings you have to attend? Are there any holidays coming up? Do you have any other competing priorities or commitments? Estimate the time you may have to focus on those things and add that to the estimate.
Also, does this account for time to deal with any potential hiccups or areas of high ambiguity that you may still have to be fleshed out? Figure out your confidence level after the technical exploration, then account for some additional time based on the percent of ambiguity that remains. It might be helpful to go through a Risks & Mitigations exercise here where you can list out all the areas of risks and potential actions to mitigate them.
Deployment Process — What will it take to be deployed?
We are in the final stretch, but the exercise is not over yet! Now that we are getting a better handle on the actual engineering time, let's start to think about the process of shipping the work.
What are the review phases that you will encounter? Will the changes have to go through peer reviews? If so, what kind of cycle time can we expect from the reviewers? There may be a review/feedback cycle to each change that is shipped. How long will that take approximately?
Will there be any other reviews outside of peer reviews? Will this have to go through a design review to ensure the final product matches the designs? Will it have to go through any compliance audits such as Privacy, Security, Legal, etc? Try to gather the rough turnaround time for those.
Final Thoughts
Providing time-based estimates is always hard. It involves a slew of factors and varies from person to person. That's one of the reasons why many teams have transitioned to a practice of assigning points to a task known as "story points", which is an agile development practice.
Instead of time spent, the team would assign a relative complexity of a task on a point scale. The scale can be anything from Fibonacci sequence to t-shirt sizes. Over time, the team builds a better understanding of how their story points map to difficulty of a task which in turn can be used to inform timelines.
No matter which framework you decide to use, like developing any skill, estimation requires continuous practice, refinement, and learning. You'll get better and better if you treat it as a skill that can be developed over time.
This post was originally published on the BetterUp Product Blog.
Top comments (0)