Estimating a prototype

The story whose deliverable is “we know what to build now,” not “we built it.”

A prototype is sized for learning, not for use. The point is to answer a question — does this interaction feel right, does this approach scale, will this API hold up — quickly enough that you can change direction before committing to it. Teams that estimate prototypes the same way they estimate features get a number that funds the wrong shape of work.

The other failure mode is the opposite: estimate a prototype small, ship something that “just works” enough, and then ship that thing to production because the schedule moved on. The prototype that becomes the product is the most expensive code in the codebase, because nobody planned for the parts that aren’t there.

What gets said in the room

Engineer: “I can throw something together in a couple of days.”

Lead: “What’s the question we’re trying to answer?”

PM: “Is this going in front of customers, or just internal?”

Lead: “If the answer is yes, we throw it away and rebuild?”

Engineer: “We never throw it away.”

Questions worth asking before voting

• What question is the prototype answering, and how will we know we have an answer?
• Internal-only, or in front of customers?
• Throwaway by default — and is the team committed to that?
• What’s the time-box, and what happens at the end of it?
• If it works, what’s the path from prototype to production code?

The engineer’s “we never throw it away” is the real risk: budget the prototype for the answer, and size the production build as its own story so the throwaway doesn’t get promoted by default.

Size a prototype for the answer, not the artifact — and plan the rebuild before the schedule plans it for you.

Like estimating a research spike, the deliverable is knowledge; treat them the same way. See common planning-poker mistakes on investigation creeping into the story, and the other worked estimation examples.