Using T-Shirt Sizes for Story Size Estimation in Agile

Posted on

One of the most read articles on this blog is my 2010 post Introduction to Minimum Marketable Features (MMF). Today an interesting question from Kevin Patrick of was added asking if any of the readers had a simple method for applying t-shirt sizes (xs,s,m,l,xl etc) to stories in order to infer the size/complexity of a story. I added the method that I’ve found to work as a comment and thought I would expand that comment out into a new post.

The big problem with any kind of size estimation is that one mans hill is a another mans mountain, therefore using a fixed value like time often produces mixed results. For example an experienced developer who’s been working on the product for years and your new intern are likely to give wildly different estimations on the same feature if asked to make a time based estimation. To get around this problem it’s popular to use relative rather than fixed values, with the most popular system being t-shirt sizes as it’s an easily understood metaphor that doesn’t require much explanation, even here in Cambodia.

Being involved in several software startups has it’s advantages, one of the big ones is that I oversee around half a dozen teams to am able to quickly test new ideas. I’ve played around with t-shirt sizes a fair bit for these teams and have found a solution that seems to work well. I always begin by asking the team to take a story from that backlog that is of average size and clearly understood in terms of scope and complexity by **ALL** of the team. This “yard stick” story is very important as in the beginning it will be used as a reference point when estimating other stories in the backlog.

Once we have our yard stick story we then explain to the team that this is considered medium and then go on to explain what the other t-shirt sizes mean in relation to this one. We say that a “large” is double the size of a “medium”, a “small” is half the size of a “medium”, an “extra small” is half the size of a small and an “extra large” is double the size of a large. We also have a rule that if in doubt we always round up, so for example if the team is unsure whether the story is a medium or a large, then it’s rounded up to a large.

I tell all of the team to use their initial gut feeling and not to over think it. If there are some wildly different estimations coming from different team members, for example one says “small” the other says “large” I ask each member to explain the reasons for their estimation until the team reaches a consensus.

This system makes the process of estimation extremely quick as it can be achieved with a series of yes/no questions. We hold up story A and ask “Is story A double the size of story Z” (with story Z being our yardstick), if the answer is yes, we then ask the question “Is it more than double the size of story Z”, if the answer is also yes, we then ask “Is it four times the size of story Z”, if the answer is no, we then mark the story as a “large” and move on.

This may seem like the kind of exercise that you would give to kindergarten children, but anyone who’s experienced the pain of sitting through estimation sessions that often descend into petty arguments and that can drag out for hours will appreciate the simplicity of this system.

Some teams have trouble moving away from long drawn out debates about feature size and instead trusting their gut feeling, for these types of teams you should either time box the estimations sessions or as I prefer, do the estimation sessions as a stand-up meeting.

Leave a Reply

Your email address will not be published. Required fields are marked *