Relative Estimating with T-Shirt Sizes

A variation on estimating using story points is to use what I call “T-shirt sizes”.  This table shows the sizes I like to use.  The abbreviation is a good way to refer to the size in a tracking system.  The weighting factor helps you make more precise trade-offs between stories that need to fit into a development cycle.

Name Abbreviation Weighting Factor
Freebe freebe 0
Extra-Extra Small xx-small 1
Extra Small x-small 2
Small small 4
Medium medium 8
Large large 16
Extra Large x-large 32
Extra-Extra Large xx-large 64
Too Big too big

I really like to use this method to estimate stories because they:

  1. Expresses the relative estimate idea well
  2. Are easy to explain to stake-holders

This method expresses the relativity concept well because, unlike story points, it has meaning in the “real world”.  When you use shirt sizes it easy to understand the idea of relativity and you don’t automatically compare the estimates to anything like dollars, days, or weeks.  Even though the estimate isn’t precise, it has real meaning that is easy to understand.

I found that when attempting to associate with software product stakeholders, it can be difficult to explain our unusual ways.  In some environments, this means that stakeholders won’t show up to meetings or have trouble being willing participants in discussions such as software product stories and estimates.  If developers don’t get enough communication with stakeholders and customers, it can seriously harm product value.  Using concepts that are less intrusive can be a big help.

The “Freebe” is just as it sounds.  It is a feature that won’t count as a part of your budget.  This is not because it has no size; it just means that it is so small that talking about it takes more time than doing it.  Many freebes will add up to an xx-small eventually.

“Too Big”, just means that the team cannot accurately estimate the story because it doesn’t appear to fit into a development cycle.  This is especially easy to understand when the team works in sprints or iterations.  The easy way to take care of these is to simply divide them into smaller stories.

The weighting factor is really the same thing as story points.  The nice thing about these is you can make your own project-oriented weighting factors quite easily.   The thing is that you really need to keep them the same.  Make sure that you use a exponential equation to calculate them.  I suggest starting with ones like I have here, however.  I have actually used these numbers with great success.  You could use Fibonacci numbers too.  These numbers help you to have a better handle on how many stories can fit in a given time period.  You may only be able to do a single extra large story.  If they break down that story you could actually fit in 64 extra-extra small stories and possibly get more done with a little more planning effort.

Once you have these you have what you need to make your estimates for your stories.