T-shirt Size Estimation - Better Than Story Points?

[@NotOnlyCode]

What's your take - story points or t-shirt sizes? Do you have experience with both? Which one do you prefer?

[@jayp-ki4zo]

How bout neither that ish is gaaayy

[@ridhwaans]

tshirt method seems better for projects with multiple teams, large backlogs of relatively large items, whereas story points seems to be for small teams with small backlog items

[@NotOnlyCode]

Do you have experience with that setup? I'm wondering why points would be better for small teams - I guess it's easier to find an agreement? A number of people told me that they use t-shirt sizes for epics and then story points when they split epics into tasks, but their only argument was that t-shirt estimation is good for a quick, rough estimation.

[@posdigitalgetnet3181]

When he said that his name is Gregory, i instantly got to Every Body Hates Chrisa ahahah

[@pakzuha2392]

I am applying for the university they ask me for t-shirt size what is meant by this? Is that mean how much work you do or something. Please explain.

[@toujoursunnerd]

I hope you were able to figure this out by now, but this video is about using standard shirt sizes as a resource in project management. Your university is asking you for your physical shirt size for you to wear.

[@not_enoughmana]

There are definitely benefits to using T-shirt sizes, but so SO difficult to get Product on board with the concept if they're already used to tracking based on time/points. Wondering if you have any thoughts on getting buy-in for transitioning to T-shirt size estimation with Product and/or leadership?

[@NotOnlyCode]

Great question! You're right it's difficult, and a lot depends on the management, sometimes no matter what you do, they won't buy it, because they want to have a very tight control. Anyway, there are a few things you can try: Usually the best way to sell an idea is to attach some value to it(preferably in dollars): since we know that our estimates are always off, why should we waste time discussing whether something is 2 or 3 points? Categorizing something as small/medium/large is easier, quicker and more intuitive. If we can save 1-2h a week per developer and get something that's just as accurate, then why don't we do it? Another argument is that velocity does not tell the whole story - let's say you have 3 developers and can deliver 18 points a week, does it mean that you can deliver 2 tasks, 8-points each? Probably no. If you say "we can take 1 large task a week and 2 medium tasks" that makes it easier to ensure that whatever you choose can actually be done. That means you can increase predictability Finally, there's one idea I've seen working, where developers suggested using t-shirt for estimating epics, while they don't have a full idea of what will be done yet. Product managers like it, because they know it's a rough estimation, but they're getting something almost instantly. If you can get people onboard with this, it's one step closer to moving all estimations to t-shirt sizes.

[@not_enoughmana]

@@NotOnlyCode Oooo! Love the idea of starting off with epics first. Thank you! I'll try this. :D

[@SH-py9ou]

What is the T-shirt size mean in term of time: Does small is something like 1 day? Medium is something like 2 days? Thanks

[@NotOnlyCode]

The point is that we do not estimate time, we estimate *size*. The time needed to complete a task will vary from person to person, that's why we can't estimate it. One developer will say 2 days, another will say 5 days and they both might be right. So we're estimating a size, because a size is more or less universal. I explain it better in the other video about estimation: kzbin.info/www/bejne/ap7Vf6d3fbt4p5o