A quick way to do this would be to have each developer in the room write down (privately) his/her estimate for each story according to some variation of the following:
- X-Large: More than a month
- Large: Inside of one month
- Medium: Inside of one week
- Small: Inside of one day
- X-Small: Inside of one hour
Then the Scrum Master can go through each story and get each developer to say her/his estimate out loud. Through a facilitated discussion assumptions surface and a realistic estimate begins to emerge.
Suppose the team comes up with an initial estimate of "Medium." That would be written somewhere on the story card. If the team learns it's more like "Large" as they go along they cross off the "Medium" or "M" and replace it. Erasing is a "no-no" because the history of estimates proves useful later on.
As functionality goes into production and the actual amount of time to complete is recorded on the card this "library" becomes another source the Scrum Master and team members can draw upon when trying to triangulate into a realistic estimate.
This same method works quite well in a personal productivity system like GTD. As 43Folders put well in a recent blog: the time you have available to work is one of four criteria you take into consideration on deciding what to do next. If you have 30 minutes and are looking through your next action items you can quickly scan through until you find one marked "X-Small".
In fact, in GTD the above steps are only the beginning. Throwing a T-Shirt estimate at a project is a great next action when you're just trying to get a handle on what you're dealing with. But you're not done estimating until everything is reduced down to an "X-Small" level or in other words an actual sit-down-and-get-this-done-right-now-task.
I've included this latter process as one step in my weekly review: go through each project and break it down a step or two.
Personal Productivity, Time Management, Effectiveness, Scrum, Agile, GTD, Getting Things Done