T-shirt sizing is generally used to give more of a rough estimate in sizing, and are usually used before all the acceptance criteria are worked out on the story. The t-shirt sizing method allows the team who will be doing the work to give the product owner a wild guess of how large a task may be.
This can be useful in backlog grooming. Let’s say a product owner has 5 stories in their backlog, and that product owner doesn’t have any way to gauge the relative size between them. Additionally let’s assume that all the acceptance criteria haven’t been worked out yet either. The product owner is just looking for an idea of relatively how big tasks are.
When you are t-shirt sizing, it’s a good idea to keep it simple with only 4 sizes, Small, Medium, Large and Extra-large. Sometimes I hear comments like that’s an extra-small size, or I have even found myself saying that that user story will be at least 4 extra-larges, which isn’t the best practice. Anything that is larger than an Extra-large is simply too large to estimate, or is too epic.
You might have two very small tasks, one is to change a single misspelling in a word and you know exactly where the change is, one of those tasks that might take you 15 seconds to find and to fix. Then you may have another task that requires changing several files, and some more testing. Both of these tasks however compared to the others that you are estimating are small, and therefor are given the t-shirt size of small.
Who can t-shirt size?
Only the people who could be doing the work should be allowed to provide t-shirt size estimates. The product owners and the scrum master should not be giving t-shirt sizes. I heard a funny comment from a product owner who stated that the team estimated it as a medium, but I rewrote the story as a small. I later learned that the PO did not talk to the team to get that small estimate, he just assumed that based on his changes it would be a small. This is very dangerous, PO’s should not be allowed to estimate t-shirt sizes or points.
While you are here, don’t forget to take a look at Uzility.com for Agile Kanban Boards.