A new feature request puts two questions on the table: can we do it, and how long will it take? The business needs enough information to make a decision, often before engineering has worked through every dependency.
When those requests come up, I think about what is already there and reusable. In conversations about building systems, I have described that thinking this way:
“all the lego pieces are around, the connection to inventory, locations, etc”.
The picture helps me break down the request. Some capabilities already exist. Some need changing. The larger workflow may still need to be assembled. That gives me a starting point for gauging a timeline, while keeping the unknowns visible.
The important qualification is that finding the pieces does not tell us everything about the work. A connection to inventory can exist and still be unsuitable for the promise a new feature needs to make.
Start with the business promise
Consider an illustrative request: let a customer choose a pickup location based on stock availability. This is an example for reasoning through the approach, not a claim about a particular project.
The platform might already retrieve inventory and maintain a list of locations. That sounds encouraging. Before estimating, however, clarify what the customer is being promised.
Does the feature show where stock was recently reported? Does it confirm that the location supports pickup? Does selecting a location reserve anything? What happens if another customer buys the last item?
Those are different capabilities with different delivery costs. A stock display and a pickup commitment can use some of the same data while requiring substantially different workflows.
Describe the expected outcome precisely enough that engineering and the business are estimating the same request. Otherwise, an estimate for displaying information can quietly become a deadline for guaranteeing fulfillment.
Look for capabilities, then inspect their fit
The first pass is an inventory of what the platform can already do. Look beyond files with promising names. A function called getInventory is evidence of an implementation; its contract and behavior determine whether it helps this request.
For the pickup example, a small working table makes the remaining work easier to discuss:
| Area | Existing piece to inspect | Question that affects the estimate |
|---|---|---|
| Inventory | Stock lookup | Does it return on-hand stock or quantity available to promise? |
| Locations | Location directory | Does it identify pickup eligibility or only physical addresses? |
| Customer choice | Existing order fields | Can the selected location survive checkout and reach fulfillment? |
| Failure handling | Current error behavior | Can the experience handle unavailable inventory without presenting a false promise? |
Each answer can move work between reuse, adaptation, and new implementation. None of these rows should be treated as completed simply because an endpoint responds.
This is where building around business capabilities helps. An explicit capability is easier to evaluate than vendor calls scattered across unrelated screens.
Separate the work you understand from the questions you do not
A useful decomposition has four categories:
- Available capabilities: behavior that already meets the request, subject to verification.
- Adaptation: changes to existing capabilities, including compatibility with current callers.
- New work: missing decisions, workflow steps, interfaces, or operational support.
- Investigation: questions whose answers could materially change the approach or effort.
Keep investigation specific. “Inventory is complicated” gives nobody a useful next step. “Determine whether this inventory source accounts for reservations” identifies a question that can be answered.
The distinction also keeps uncertainty from disappearing inside implementation tasks. If location identifiers do not match across systems, a mapping decision may be needed before the interface work can proceed. Assigning more time to the interface does not resolve that dependency.
Estimate the complete path
Reusable pieces reduce some work. The estimate still needs to cover connecting them, testing the resulting behavior, protecting existing consumers, and introducing the feature safely.
Data freshness is one example. An inventory lookup used in an internal report may tolerate a delay that is unacceptable during customer checkout. The code can be reused while its caching assumptions require revision.
Ownership is another. If two systems can update the selected fulfillment location, deciding which one is authoritative becomes part of delivery. Failure handling matters too: a timeout must not become an apparently valid stock count.
Work also has an order. Two tasks may be independently implementable, while a third depends on a business decision or vendor answer. Engineering effort and elapsed delivery time should be discussed separately. A list of reusable modules cannot reveal that schedule by itself.
Give the range a reason
An estimate range becomes useful when its assumptions are visible. Explain which scope it covers, what supports the lower end, and which additional work could move delivery toward the upper end.
For this illustrative request, the narrower scope might display availability without reserving stock. A reservation guarantee could require a different estimate altogether. Keep that scope distinction explicit instead of stretching one range across two different promises.
When an unknown could invalidate the approach, investigate it before treating the estimate as a commitment. A focused check of inventory semantics may be more valuable than refining every small UI task. Revisit the range when the evidence changes; a fixed padding percentage cannot explain which assumption failed.
Let the estimate inform the feature
The useful output is a shared picture of the remaining work. The business can then decide whether to narrow the first release, fund a missing capability, or investigate a dependency before committing to a date.
That is why the Lego picture is useful to me: it connects what exists today with what a new request still needs. Moving between the pieces and the whole workflow helps expose those gaps. Planning for the unknown within reason helps decide which future changes deserve attention now.