Technical Feasibility Assessment. @feasibility-assessment

Most expensive software failures were knowable before the build started. The Technical Feasibility Assessment answers the question first: can this product or feature be built with your constraints — the data you hold, the systems you must integrate, the performance you need, the budget you have. Senior engineers who build production systems run the assessment, so the answer is implementation-backed rather than theoretical.

The finish state is a clear verdict: build, don't build, or build differently. You get the evidence behind it — spike results, risk register, and an effort model — so the decision stands up in front of your board or investors.

Feasibility Spike

The riskiest technical assumptions tested in code: a thin proof against your real data, APIs, or performance targets — not a slideware opinion.

Risk Register

Every material technical risk named, sized, and ranked, with the mitigation or the kill-switch condition for each.

Effort & Cost Model

A phased effort estimate for the viable path, with the cost drivers and the assumptions that would change the number.

Recommendation Report

A written verdict — build, adapt, or stop — with the reasoning, the spike evidence, and the recommended next step.

1. Scope — Fix the proposal under test, the constraints that matter, and the two or three assumptions that decide viability.
2. Build — Run the spikes against real systems and data, compile the risk register, and model effort for the surviving path.
3. Handover — The recommendation report walked through with your decision-makers, plus the spike code and findings.

The Technical Feasibility Assessment is a menu item on the Scrums.com delivery catalog, available at every plan tier. Add it to your plan backlog and your delivery team schedules it like any other item — scoped, tracked, and reported through the SEOP. See Delivery Plan Tiers.

Is this a full architecture design?

No. This sprint decides whether and how to build. If the verdict is build, the Solution Architecture Blueprint is the natural next item — it turns the viable path into a target architecture.

What do you need from us to start?

The proposal in whatever form it exists, access to the systems and data the build would touch, and an hour with the person who owns the decision.

What if the answer is no?

Then the sprint has done its job cheaply. The report states why, what would have to change for the answer to become yes, and any narrower version that is viable now.