1

I've read articles with very conflicting arguments on t-shirt estimates. Neither article seemed all that credible so I thought I would bring this up here.

Are t-shirt estimates a good idea?

For those who haven't heard of this: T-shirt estimates are the practice of giving very vague and high level estimates when given vague, high level requirements, and no resources to estimate.

They are based on t-shirt sizes and as such are broken down into: XS, S, M, L, XL, etc.

I don't see any problem in them in principle. Requirement gathering, requirements research and proper estimation all require time. Much of the time, 'clients' can request premature estimates and the ability to use t-shirt estimations allows for answers that are obviously overly vague and can't be held to any standard. At the time, this satisfies the 'clients' as they at least something to base their thinking on.

Conversely, if you were to give the same client the answer of 5,000 hours but gave the stipulation that this was just a guess and put that in bold, red, and blinking text. You run the risk of the client 'forgetting' this and then getting upset when these hours change drastically when a proper estimate is done.

Improve this question
  • 2
    So basically you are gauging the relative merit of this technique in direct proportion to the amount of meaningless satisfaction experienced by a pointy-haired boss? – Robert Harvey Aug 7 '13 at 21:25
  • 1
    T-Shirt estimates are just agile "story points" with a different name. – Gort the Robot Aug 8 '13 at 1:45
  • @StevenBurnap if you are playing planning poker though the story points are on an exponential curve its not clear that T-shirt estimates are (and this might be a weakness of them) – jk. Aug 8 '13 at 7:58
3

A manager's S is probably a programmer's L, and a programmer's L when being asked to give an estimate in under 30 seconds is often an XXXL in real life.

And of course your cautious programmer may say L whereas your flippant one says M.

So, they're only as good as the communication between the two people having the discussion. At my small, close-knit firm where we're in good relations, my manager knows "shouldn't take too long" means "thinking about it for 10 seconds I don't see any glaring problems." But he also knows I would have to think about it a lot longer to be more sure no huge snags are hit. And, if you rely on t-shirt estimates, be sure you're only making commitments as good as your data.

Don't fall for the trap where these sound quantitative. They are qualitative. Thinking of how my firm operates, this table is problem accurate for how we would use them:

  • S - "shouldn't take too long." (Later: oh wait, this thing needs to be done too)
  • M - "doesn't sound that hard." (But it involves a lot of components and one of them might be harder to code on or scale than I realize right now.)
  • L - "that's not easy." (A week or two. You probably don't want to do it unless it's an actual real project.)
Improve this answer
  • You would establish it based on common grounds. Each person is aware of the size of the project relative other projects they've done for the same 'client'. Maybe this model works best for internal IT shops that cater to one business always. – user606723 Aug 9 '13 at 19:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.