This is a pattern.

RapidEstimates are a must to keep the ProjectUnderControl. No developer should continue his coding unless he has estimated all his pending tasks. You would find this awful, especially if I forbid any estimate to be longer than 3 days. 

This is not exactly the GiveMeEstimatesNow AntiPattern.

Forces:

	1 The manager needs good estimates, and he needs them ASAP to dedicate the resources where they are needed.
	1 The developer is not very sure how long it will take.

Solution:

Developer: No problem. I will divide the task in several smaller tasks. All the tasks that can't be done by me, will be assigned to other groups, with no estimate from me and not including their tasks in my estimate. I will even divide my tasks so that I can estimate the smaller ones and then assign a big huge estimate to the one that will take the most time. 

Manager: Mhhh, everything seems fine, except this big huge task here that takes more than 3 days. In total, if I remove that task, everything is ok, I will then reassign this task to the developer that is the strongest in this area, (probably me), he will divide this task and assign the remainings to this developer who was collapsed by this task.

The same developer as above, eventually receives the same task he overestimated, but now the pieces are smaller. The estimates for most of them will be small and possibly one of those task will again be too much. The manager repeats the process until all tasks individually take less than 3 days or a number of days agreed before the project started.

But the developer can't give exact estimates all the time and the manager needs to know when the developer is just guessing. So a simple way to do this is to allow the developer to estimate minimum and maximum time for any task. Then the manager takes a look only at the maximum time, the minimum time is irrelevant. I ask each developer to estimate the minimum time and put a risk in, the risk is just a number from 1.0 to 10.0. That number multiplied by the minimum time is the maximum time. When the risk factor is too big, then the manager knows the developer has no idea. So risk is detected earlier and task can be reassigned to developers with more experience.

Notice that I would not recommend using this technique without using UnitTest''''''s.

A tool that already implements this idea is Insecticida (http://sourceforge.net/projects/insecticida/)

----
See EstimatesLongerThanThreeDaysConsideredHarmful.
-- GuillermoSchwarz