How is task management like gambling? There is a direct connection in selecting a set of tasks to fill a timebox. You are essentially "betting" a certain number of work hours, and therefore dollars, will be enough to complete a particular task. Let's leave aside for the moment the question of whether that task will result in something of value and assume that every completed task produces an amount of value that is linear with the cost of execution. That way we can say that 8 hours of effort that results in a completed task is worth 8 units of value.
The problem is, we don't know a priori how many hours will be necessary to complete a task, which is where the risk comes in. In general, we hope that increasing the number of hours spent on a task increases the likelihood of completion, although that isn't guaranteed. Standard project estimation techniques rely on hi-low ranges such as "Task 8 will take from 2-8 hours to complete". What we might really be saying is, "There is a 10% chance that this will only take me 2 hours, and a 90% chance it will take me less than 8 hours". The percentages change from task to task, and it could be %90 less than 2 hours and 95% less than 8 hours for another task, which is why the hi-low estimate leaves out a lot of information.
I like to turn this around and state the range as: "If you give me 2 hours, there is a 10% chance that I will complete the task, and if you give me 8 hours, there is a 90% chance I will complete it". That's nice from a management standpoint, because the number of hours you have are generally fixed, so you can look across your tasks and decide how high you want to raise the percentage for any given task. The output of a timebox then is a set of completion probabilities. Ideally, you group things by low, medium, and high probability of success in order to get a sense of what is likely to be the state of your system at the end of the timebox.
What about when you don't have any idea how many hours are needed for a particular probability of success? That's where the metatasks that involve improving your task estimates come in. Whether or not you think of these estimation tasks as metatasks, most projects do quite a bit of them. Processes such as CMM are oriented around helping you provide the best estimates possible. But how much are better estimates worth?
Let's say you have a task that you think will take between 8 and 24 hours to perform. How much it is worth to you to know that it will actually take between 6 and 15 hours (reducing the max-min ratio of 3 to 1.5)? It depends on the cost of a bad estimate. The costs of estimating too low include deadline slippage, loss of trust from stakeholders, and overwork of employees trying to use heroics to meet impossible estimates, to name a few. Estimating too high has other costs, the main one being that tasks tend to fill the space allocated to them, so high estimates lead to developers spending unnecessary time on things. Even if this effect is tempered, there are other problems such as having to constantly rebalance to add more tasks to a timebox, and just simply looking less efficient than other comparable groups.
Your decision about whether or not to improve your estimate depends on how expensive you believe over and under-estimation to be. In my experience, underestimation is significantly more costly than overestimation, so I like to improve my estimates when they look suspiciously low, since that tends to result in the most benefit. Overall, I don't like to spend more than about a quarter of the low-estimate time on better estimation since you are usually better off spending that time on doing the work.
Integrating these estimate-improvement tasks into your timebox along other metatasks, plus the addition of success probabilities to every element means that you can conceive of your outcome as what we will likely have done, and what we will likely know. Making this switch can often help communicate to stakeholders better about what you are accomplishing, where you see the risks, and where you are taking your gambles.