What Engineers Need to Know Before They Can Estimate a Feature

“Add a filter so shoppers can see products available at their selected store.” On a product-listing page, the request might look like one more dropdown. It is tempting to estimate the control, its responsive styling, and the small piece of logic that updates the results.

But the size of that interface is not the size of the feature. If the existing catalog response already contains reliable store-specific availability, the work may be mostly frontend behavior. If availability must be requested from a different service for every product, the problem includes data access, performance, and possibly changes to the search system. If no supported service exists, a frontend estimate cannot describe the complete feature.

I have worked with long-running e-commerce frontends, where a proposed visual change has to fit real data and established behavior. The store-filter example here is entirely illustrative: it is not a client ticket, a production incident, or a claim that I delivered this exact feature. It lets us examine a question that matters well beyond e-commerce: what information makes an engineering estimate defensible?

Begin with the decision the estimate needs to support

An estimate is useful only in relation to a decision. Is someone choosing between two features? Reserving team capacity for the next Sprint? Coordinating an integration with another team? Or promising a public launch date? Each decision needs different precision, evidence, and treatment of uncertainty.

Martin Fowler makes this distinction in his essay on the purpose of estimation: estimates can be valuable for resource allocation and coordination, but their usefulness depends on the decision they inform. A rough comparison can help prioritize options; it is not necessarily enough to make a dated commitment to a customer.

Before estimating, I want to know what the number will be used for. Otherwise, an early sizing discussion can silently become a delivery promise that nobody was ready to make.

Be precise about what is being estimated

An estimate needs a boundary. For the store-availability filter, are we estimating only the control and client-side interaction, or a complete journey in which the selected store changes which products are returned? Does it include searching and pagination, error handling, keyboard use, mobile layout, analytics, regression checks, and deployment? Is an API change part of this work or owned elsewhere?

This is not an argument for exhausting every possible requirement before development. It is a way to avoid treating different scopes as the same task. A developer can reasonably estimate a frontend control against an existing data contract. That estimate becomes misleading if presented as the effort required to deliver an end-to-end feature whose data contract is still unknown.

The question I find most useful is: which assumptions, if false, would change the implementation approach rather than merely add a small adjustment? Those assumptions deserve attention before anyone attaches confidence to a number.

One request, three substantially different implementations

Consider three hypothetical technical states for exactly the same filter.

In the first, the product-search endpoint already accepts a store identifier and returns results filtered against an agreed availability rule. The UI needs to preserve the selected store, update the query, present loading and empty states, and remain accessible. The existing behavior and data contract give the engineer a workable basis for an estimate.

In the second, the listing receives catalog results, but store availability comes from a separate inventory endpoint for individual products. The engineer cannot simply fetch one page and remove unavailable items on the client: that could produce short pages, incorrect result counts, or pagination that skips eligible products. The team may need an availability-aware search query, an aggregation layer, or a deliberately narrower product experience. The approach—not merely the number of hours—has changed.

In the third, the required inventory data is not yet exposed to the frontend and another team must provide it. The frontend interaction may be estimable, but the overall feature depends on work and decisions outside that estimate. Adding an arbitrary buffer to the UI work would not make the missing service a solved problem.

No redesign of the dropdown is needed to create these differences. They emerge from the system in which the feature must operate. That is why understanding the current architecture matters before using past UI tasks as the basis for a forecast.

Separate the unknowns that change size from those that change timing

Not all unanswered questions have the same effect. Some alter the solution and engineering effort. Some are product decisions about what the feature means. Others do not change the implementation size but can prevent delivery while a dependency remains unavailable.

The following questions illustrate what I would verify for the hypothetical store filter. They are not an attempt to turn a small request into a large document. Their value is in revealing which answers would materially alter the estimate.

The last two rows are often confused with coding effort. Waiting for an external team can make delivery later without making the frontend code more complex. An unavailable test environment can block validation even when the implementation is straightforward. Good planning makes these distinctions visible instead of absorbing every problem into “development time.”

A short investigation may be the only honest estimate at first

Sometimes the most useful next step is not estimating the feature but estimating a bounded investigation. Teams commonly call this a technical spike: work intended to answer a specific question or reduce uncertainty rather than deliver the feature itself. Agile Alliance’s discussion of spikes describes this distinction.

For the store filter, the investigation might be narrow: inspect the inventory API contract, confirm whether a store identifier can be included in search, and test the shape of a representative response. The output is a decision about feasibility and integration boundaries, not a new feature hidden inside a research ticket.

The investigation should have an explicit stopping point. “Find out how inventory works” can expand indefinitely. “Determine whether our search service can filter by store availability without client-side filtering of paginated results, and document the supported approach” gives the work a useful result. If that question cannot be resolved within the agreed scope, the remaining uncertainty should be reported, not disguised as completed discovery.

Not every unknown merits a spike. A familiar low-impact variation with a clear fallback may be safely estimated under a stated assumption. A technical dependency that could turn a UI task into service development is different. The goal is to investigate where the information gained changes an actual decision.

After the implementation is better understood, Capacity Is Not a Commitment: Planning Software Work Under Uncertainty addresses the separate question of whether dependencies and available people support the delivery forecast.

Estimate effort, delivery time, and confidence separately

Three ideas often collapse into a single number. Effort is the work required under a particular scope and approach. Calendar time depends additionally on available capacity, coordination, review, and external waits. Confidence is how strongly the evidence supports the forecast. They influence each other, but they are not interchangeable.

A feature requiring a few concentrated days of engineering effort does not necessarily ship a few calendar days after someone approves it. The engineer may be working on other priorities. An API owner may not yet have committed the contract. A release may need a shared testing window. Conversely, a higher-effort task may progress quickly when several people can work on independent parts without increasing coordination or integration cost.

The 2020 Scrum Guide puts responsibility for sizing Product Backlog items with the Developers and notes that Sprint forecasting benefits from knowledge of past performance, upcoming capacity, and the Definition of Done. That does not turn sizing into a guarantee of dates. A delivery forecast has to reflect who is available and what work can realistically reach Done in the intended period.

The same discipline applies outside Scrum. If someone asks how long a change will take, the answer is more useful when it specifies whether it refers to engineering effort or a delivery window and what must be true for it to hold.

Choose the right response to the level of evidence

There is no need to force every request into either “ready” or “cannot estimate.” The appropriate response depends on the remaining uncertainty and its consequences.

A conditional estimate is not an excuse to avoid responsibility. It is a way of saying exactly which conditions the estimate covers. A timeboxed investigation is not an excuse to postpone work indefinitely. It should produce information that changes the planning decision. And a blocked dependency is not evidence of a slow engineer; it is a coordination issue that needs an owner.

Communicate the estimate as a small decision record

For the hypothetical feature, I would rather give a short explanation than an unsupported single number:

The responsive filter interface can be sized against the existing product-listing component. The end-to-end estimate is conditional on store-specific availability being available to the search results under an agreed freshness rule. I recommend verifying that contract first. If filtering cannot happen in the search service, we should choose a narrower experience or estimate the required service change separately. I will revise the feature estimate when that decision is made.

The wording is illustrative. Its value is the structure: what is known, what remains assumed, what could change the approach, who needs to decide, and when the estimate should be revisited. A stakeholder can act on that information. A bare number offers far fewer useful choices.

This also creates a better conversation about scope. If full store-availability filtering is expensive or dependent on an unfinished service, perhaps a product-detail availability check meets the immediate business need. That is a product decision to evaluate, not a shortcut an engineer should introduce silently.

Update estimates when the evidence changes

An estimate made before the API contract was examined should not retain the same authority after integration testing reveals a different system boundary. The reason to revisit a forecast is not that an engineer has failed. It is that the assumptions supporting the forecast have changed.

Changes worth communicating include a new business rule, a confirmed incompatibility, missing data, a newly discovered legacy consumer, a dependency moving outside the planned window, or verification work that was not included in the original scope. Explain which new fact affected which part of the estimate. That is more useful than simply replacing one number with another.

It is equally important not to inflate the process when the evidence is already sufficient. Routine work on a known system can often be sized quickly through comparison with similar completed work. The right amount of analysis is the amount that improves the decision, not the amount that makes the estimation meeting appear thorough.

An estimate is a forecast about a particular version of the problem

Estimating well does not mean predicting every complication. It means understanding enough of the work to choose a credible approach, identifying the unknowns that could change that approach, and telling the people planning the work what the estimate actually includes.

The store filter looks simple in a screenshot. Depending on the system, it might be a contained UI change, an integration change, or a feature waiting on an inventory service. An experienced engineer should be able to explain that difference before asking the team to commit to one delivery expectation.

The useful question is therefore not only “How long will this take?” It is “What do we know, what is our estimate assuming, and what decision can we responsibly make with that information?”