> What happens if we don't discover what we want to in that amount of time? We reevaluate with more information than we have right now. This pattern of task i

> What happens if we don't discover what we want to in that amount of time? We reevaluate with more information than we have right now. This pattern of task is helpful for things where the unknowns are substantially greater than the knowns. The idea is to incrementally shift the balance until the knowns are _enough_ to actually make an informed guess instead of just a wild guess. There's a bug in the legacy codebase. The replacement is nearly finished and slated for launch in two months. How do we handle that bug? We could ignore it, we could just tell someone "go fix it, whatever it takes". Neither is a great option. So: "Go investigate this bug, don't spend more than an hour, and let me know how far you get." By the time you're done, we'll have a _better_ idea what the shape of the problem is. Maybe you come back and say "yeah I found the problem's in this area, I need to sit down with someone that understands the business logic better to untangle this and then we can tweak and fix it"--great, we'll get you the appropriate resources and try and follow through with a fix. We'll figure on something like an afternoon of interruption for you. Maybe you just come back saying "it's in this part of the code and it's pretty organized, just couldn't quite track it down yet" and we can greenlight more time based on some level of confidence that it won't be an enormous task. (Or maybe not, depending on the actual scope and severity of the bug.) We'll figure on a day or two of interruption to get it over the line. Maybe you come back saying "it's somewhere in this eldritch spaghetti, and when I stared into it the abyss starting back at me sent chills up my spine and the pictures on my walls wept blood, please don't send me back there" and it's clear it's not worth pursuing any further and we drop it.