Inception

Inception is the project phase that turns a validated product idea into a de-risked plan for delivering it. Where discovery establishes what to build and why, inception is concerned with how to get it off the ground: validating the expected outcomes, clarifying scope, identifying dependencies, agreeing ways of working, probing technical feasibility, and shaping the first iterations of delivery.

Its purpose is to de-risk delivery. An inception brings the right people into the room early – engineers, product owners, and designers – to ask the right questions together. The result is the alignment and the just-enough plan a team needs to hit the ground running. The output is not a complete design but a set of high-level deliverables: a problem and solution statement, a delivery approach, the principal risks and dependencies, and a rough plan and cost for at least the first iteration.

Inception is not a big design up-front exercise. The intent is to do just enough up-front work to start well, then let the design evolve through iterative and incremental delivery. Typical technical activities include architectural spikes and producing a walking skeleton. This is a thin end-to-end slice that exercises the proposed architecture and surfaces integration risks before the bulk of the work begins.

Note

The word inception for an opening project phase originates with the Rational Unified Process (RUP), whose first of four phases is named Inception and covers scope, business case, and risk. The modern, agile-influenced usage narrows and reframes that idea. Discovery owns the "what and why", inception owns "how to get it off the ground", and delivery owns building, operating, and improving the solution. The boundary is one of emphasis, not a hard gate. High-performing teams frequently run aspects of all three in parallel.

See also

References