I work in IT and we do a lot of our software development projects based on pre-defined delivery dates (no one really knows where they come from). Sometimes this works out, but usually we end up delivering the project months late because we had no idea the project was as big or as complex as anyone had originally thought. A friend says his company uses “t-shirt sizing” for project estimates and I’ve never heard of it. What can you tell me about this new approach?
- I’m willing to learn from the fashion industry
Dear I’m willing:
T-shirt sizing has been around in one form or another for a few years but it is not a widespread mainstream estimating method. It is a quick and dirty way to estimate software size using ranges of size. Once you have the relative size (e.g., XS, Small, Medium, Large, XL, XXL, or larger), you can enter it into several different estimating tools as the size on which to base the estimate. While this doesn’t give you a guaranteed size for the software to be delivered, it is better than not having any idea of the size. Size (scope) is one of the three main tenets of the triple constraints (scope, budget and schedule) for project management. Given one, you can estimate the other two.
Some estimating tools come pre-loaded with t-shirt sizing ranges (such as QSM’s SLIM-Estimate) while others need a single figure size, in which case you enter in the upper range of the T-shirt size to be conservative with the estimate and allow for “growth." Sometimes, as in SLIM, the range of T-shirt sizing varies with the type of project (i.e., real time projects and banking software projects have a slightly different t-shirt sizing scale). The advantage to t-shirt sizing the way it is implemented in SLIM is that you can choose to use it in various units of size – Effective Use Cases, SLOC (Source Lines Of Code), Function Points (FP), RICE objects ((R)eports, (I)interfaces, (C)onversions, (E)nhancements) and others.
Here is a screen shot of how SLIM does t-shirt sizing with Effective Use Cases:
T-shirt sizing allows you to “estimate” a relative software size (scope) so that you have a solid base assumption (still an assumption, but at least it’s a “line in the sand” assessment) on which to estimate the other two variables (cost and effort).
I’m willing, I hope this gives you the information you need.
QSM hosts a free advice column for software professionals who seek help to solve project management, communication and general software project issues. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to Ask Carol!