Dynamics of Effort Estimation

In most Product Development organizations, early effort estimation of prospective features is critical to assess the cost vs. benefit ratio of each feature.
These estimates are ultimately influencing which features will be part of the next release.
I'll be trying here to give an overview of the issues at play in the estimation process.
In my subsequent posts, I'll provide an overview of some popular estimation methods and I'll share my own recipes.

::The Role of Project Estimation:
Estimates are meant to establish the effort, timeframe -and ultimately the cost- involved in delivering a prospective project.
As such, they are a critical part of the Return on Investment (ROI) calculation of a given candidate feature, and help identify which features should be targeted and which one should be deferred or abandoned.
What is also at stake in the estimation process is how much and how early expectations can be set with the customer base - e.g. being able to tell customers they'll be able to get feature Foo by this date.
Ultimately, proper estimation is about the ability for the organization to plan accurately and execute in a profitable manner - by being able to make the right investment decisions.

The above being stated, in the same way as Planning is as beneficial as the Plan, the estimation process is as important as the actual estimate number you'll come-up with. Software development is in large part a process of discovery, and the estimation process contributes to that discovery.

::Informal vs. Formal Estimation Process:
The formality of the estimation process varies greatly between organizations. In some organizations -typically the smaller ones-, a single person might be planning the release by making informal assumptions about the cost of each feature, and incorporating it into her decisions.
In software shops with a high degree of collaboration between Product Management and Engineering, the estimation process could consist in just a short and informal chat between a product manager and an architect.
In more formal organizations, the estimation process can be quite involved, require iterations, reviews, and ultimately sign-off from the stakeholders.

The main factors that determine how much formality need to go into the estimation process include:
- The level of expertise of the people involved in the estimation process - i.e. how much Product Managers /Analysts are familiar with the business problem, as well as the Development Team's familiarity with potential solutions and their technical implications.
- The impact of missing estimates - In particular, the impact on customers (who might be expecting functionality to be delivered by a certain date); and more broadly, the impact on future revenues and profitability, if the estimates are off.
- The amount of functional risks in the features being considered - A feature that is well understood is much easier to estimate than one that is still blurry and which will most likely require many iterations before getting it right.
- The amount of technical risks in the features being considered - The more technical aspects of a solution are unknown, the less accurate the estimates can be.
- The organization's ability to mitigate risks - An organization that has some amount of free-play in adding resources, removing scope, or pushing dates might require less accuracy in estimates than an organization that has no slack.
- The level of trust between stakeholders - Trust allows stakeholders to be more accommodating and make trade-offs when estimates end-up being too aggressive. This tends to encourage bolder estimates. Conversely, punishing incorrect estimates -e.g. by forcing the Development Team to "eat-up" the increment of effort- encourages more conservative and/or carefully thought estimates.

::Aggressive vs. Conservative Estimates - How Accurate Your Estimates Need to Be?
Accountability being key to efficiency, the Development Team's Manager need to be held accountable for meeting the estimates she provides.
At the same time, adjusting plans -by pushing the dates, adding resources, or removing features- is not always an option: add budget constraints on top of the fact that the feature set and release date have been communicated to analysts, customers, or prospects; and making changes to the plan is close to impossible.
In these environments; one solution is to pad estimates, and communicate a more conservative number.

The amount of padding needs to be proportional to the risk and impacts in not meeting the estimates.
In software development, work expands to fill the available space - the more time one allocates to a task, the more time it will take to effectively complete that task.
As such, padding beyond reason is never a good idea:
a. It affects the performance of the development team - which the Development Manager is also measured on
b. It affects the motivation of people on the team - the type of Developers you want on your team will get bored if there is little sense of urgency
c. It generates distrust among other stakeholders
d. It doesn't contribute positively to the bottom line of the product being developed; which ultimately affects every one's success.

More importantly, estimates need only to be as good as the execution that will follow when the project starts.
Estimates that are over-aggressive by 30% can typically be caught on with proper project control and focus.

For these reasons, the Development Manager needs to provide estimates that are as aggressive as possible while remaining reasonable.

I'll describe some estimation methods -including my own- in subsequent posts.