As with many development methodologies, it probably has a formal version that I'm not understanding.
But in my head, it's always been (1) identify areas of risk, (2) sprint to a prototype that decreases or quantifies that risk, (3) evaluate whether you've reduced risk sufficiently, then either (4a) proceed to the next risk or (4b) do another prototype sprint on this risk, and finally after all pockets of risk have been reduced (5) begin building your finished product.
Believe it comes from state of the art development for military procurement, where "What is even possible?" is a valid question.
But it always resonated with software planning for me, by making it more about risk reduction rather than guessing.
But in my head, it's always been (1) identify areas of risk, (2) sprint to a prototype that decreases or quantifies that risk, (3) evaluate whether you've reduced risk sufficiently, then either (4a) proceed to the next risk or (4b) do another prototype sprint on this risk, and finally after all pockets of risk have been reduced (5) begin building your finished product.
Believe it comes from state of the art development for military procurement, where "What is even possible?" is a valid question.
But it always resonated with software planning for me, by making it more about risk reduction rather than guessing.