Microspeak: T-shirt sizing

Larry Osterman discussed the buzzword T-shirt sizing, which means "making extremely rough estimates in terms of a small number of predefined categories." The term comes from the traditional way T-shirt sizes are specified in the United States. Instead of having T-shirts in sizes 4, 5, 6 and so on, there are only a small number of sizes: Small, medium, large, and extra-large. (Sometimes augmented by extra-small, extra-extra-large, etc.)

Forcing the estimate into one of a fixed set of sizes allows the process to go quickly while still producing a result that is at least within the same zip code as a more detailed answer. The idea is not to pin down the schedule precisely but rather to get a back-of-the-envelope feel for whether a project is a two-week project, a two-month project, or a two-year project.

The size breakdowns vary depending on the scope of the project. For a small project, small might mean "less than a day", whereas for a large project, small might mean "less than a week". People can usually come up with a gut feeling as to whether something will take "less than a week" much more quickly than they can say whether something will take one day, two days, or three days.

As the concept of T-shirt sizing spread through Microsoft, it inevitably became the source of a new set of derived jargon. I've seen T-shirt costing on a meeting agenda. Though thankfully I have yet to see T-shirting.

Comments (16)
  1. steven says:

    This comment was strangely prophetic:

    Re: Missed metaphors

    Saturday, June 02, 2007 4:01 AM by Mike Dunn

    And then a few months later, Raymond will write a post titled "Microspeak: T-shirting"

    The title is almost correct, but at least you mentioned "T-shirting" in the post :)

  2. John says:

    So how do you convert t-shirt sizes to plates?

  3. dave says:

    Next week, perhaps you could explain what it means for two estimates of time to be "in the same zip code", which seems to be an estimate of area.

    (Yes, I actually understand the metaphor).

  4. Colin Blair says:

    By attempt at a shirt to plate conversion:

    XS = saucer

    S = bread plate

    M = salad plate

    L = dinner plate

    XL = fajita skillet

    XXL = platter

    XXXL = tray

    XXXXL = table

    XXXXXL = buffet

    XXXXXXL = restaurant

  5. Jules says:

    This reminds me of extreme programming’s approach to task estimation: every task is scheduled as either 1, 2 or 3 points (or in some teams 1, 2 or 4).  If a task is larger than 3 points it needs to be broken down into subtasks because it’s too big to estimate exactly.  The size of each points is somewhat arbitrarily chosen.

  6. Keeron says:

    In our team we use Scrum and have similar costing (or sizing) system: S(4), M(8), L(16), XL(32), XXL(64), (and sometimes even XXXL, but those are broken down into smaller tasks right away). The points aren’t same as the hours, although I often confuse them while costing. I guess with expereince you start to attach number of hourse (personally can take) to each of these sizes. I.e. A small task (4 pts), I can do that in 8 hours.

  7. In an old team, I was faced with ‘old style T-shirt costing’ and ‘new style T-shirt costing’. I still havent figured out what the differences were :)

  8. Erisian23 says:

    T-shirting sounds remarkably like the companion to pantsing.

    I hope we don’t see it, but if so I need 90 days advance notice for any meeting whose agenda specifies "t-shirting" so I can turn it up a notch at the gym.

  9. funnyman says:

    "You can tell which people listed blogging as a performance review goal"

    yes, they re-blog :P

  10. Ray Trent says:

    As a complete nerd, I’ve always been really irritated by the "in the same zip code" analogy.

    There are many single buildings that have their own zip codes (some more than 1), and other zip codes (e.g. in Alaska) which are larger than most moderate sized states.

    As you can probably tell by the building example (but it’s true with more traditional zip codes too), there are zip codes entirely contained within another zip code, making it a non-unique mapping.

    Finally, numerous large areas have *no* zip code associated with them.

    Of course, I’ve seen numerous people that don’t fit into any standard T-shirt sizes.

    Or some zip codes.

  11. Worf says:

    Guess it’s just me then that likes the military-style sizing. (At least I know I fit inside a size 38R flightsuit – better than the S/M/L choice I was offered and had to guess…)

    Then again, we ballpark in the order of magnitude method – day/week/month/3months/6months/year, sometimes half that. Then we qualify the estimate – confident, reasonably confident, risky, just a WAG.

    Some things are so classic that we can often estimate in days – e.g., board bringup is normally a week, save fatal design flaws that make it not work period. But designs from existing designs mean the bootloader can be modified in a day, and hardware checkout can progress, then basic OS (kernel, minimal drivers) in a week. Enough to do hardware verification and validation, while everyone else works to get it all working.

    Unknown processors, unknown non-volatile memory add to time and decrease estimate confidence…

  12. Units says:


    Metric: XS, S, M, L

  13. Places with no zip (or in this case, being in the UK post) code are a pain; for a while my car spent nights in the public car park opposite my brother’s apartment building. Being a car park, it does not receive mail. Not receiving mail, it has been assigned no post code by the Post Office. Explaining this to the first insurance company call center drone was somewhat frustrating: he could not grasp the concept of a place simply not having a post code. Fortunately, when I called back I got someone who understood this and found a solution after escalating the query two levels.

    My biggest headache at the moment is dealing with construction people, who seem to think everything should be planned and scheduled with day by day resolution – probably viable with construction, where it’s all been done dozens of times before, but in software development…

  14. keith says:

    Nothing to add, except re: within the same zipcode:  I once discovered on a database project that you can’t rely on "State" having a functional dependency on "Zip Code", as Texhoma, 73949 lies in both TX and OK.  

  15. Matt says:

    @keith:  Yikes!  My heart just skipped a beat, as I never knew that.  I’m now running over about 50 projects in my head, trying to remember if this will/has broken any of them!

  16. keith says:

    Matt, it’s a real kick in the mental model, eh?  There’s a reason I remember it!

Comments are closed.

Skip to main content