Prompt
You have a task to implement a "forgot password" flow. Break it into subtasks and assign story points (Fibonacci: 1,2,3,5,8,13).
Solution
The process failure estimation prevents: the business committing to a number whose hidden assumptions nobody wrote down. An estimate is a decision-support artifact, not a number — and the breakdown is where its honesty lives, because decomposing "forgot password" is what surfaces the work that isn't on the screen: the reset-token backend, the email-provider integration, token expiry handling, and the E2E test. Un-decomposed estimates are wrong precisely by the size of the invisible work.
Fibonacci points encode two senior ideas. First, relative sizing: you calibrate against the team's historical velocity ("yesterday's weather"), not against hours, because teams are far better at "this is like that other task" than at absolute time. Second, the widening gaps (5, 8, 13) admit that uncertainty grows with size — arguing 8 versus 9 is false precision the scale refuses to express. A 13 is a signal to split before it enters a sprint, not a task to attempt.
Note testing is a first-class subtask: if the Definition of Done says tested and reviewed, that effort belongs in the estimate, not smuggled in afterward.
Red flag: giving a single confident number. Padded or not, it signals you don't know estimates are probability distributions — always a range resting on stated assumptions, risks, and exclusions.
Say it: "I decompose until the hidden work is visible, size relatively against velocity with Fibonacci, and anything at 13 gets split — the breakdown is the estimate; the number is just its summary."