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?
Like spikes, the deliverable is knowledge. Treat them the same way. Common mistakes covers what goes wrong when investigation creeps into the story.