Estimating #

T-Shirt sizing engineering efforts - a simple approach to estimation #

Software project estimation is an age old problem and hence come with a lot of flavors. In this article, I plan to cover T-shirt sizing as an effective agile estimation technique to scope large amounts of work in less time without getting into analysis — paralysis.

While there are any number of approaches for estimating software projects and efforts, t-shirt sizing is targeted at the early planning stages of the software life-cycle and is primarily used in the planning or strategic phases to order work and determine what is feasible to target over longer periods of time (think over the next year). Because it occurs very early, it really is not as accurate as some of the more detailed agile approaches where points may be assigned and velocity is measured, it is primarily intended to give relative ideas of the complexity and the scope of effort required.

The basic rules for sizing estimates: #

• Speed over absolute accuracy - planning and/or estimation don’t deliver any value by themselves. Get the estimates done fast and use agile delivery of teams to adjust plans as you go.
• Collaborative - The accuracy of estimates turns much better if more people get engaged and involved; this also avoids the blame game.
• Relative Units - We don’t try to estimate and plan based on “real” units such as dollars or hours. Instead, we use ordering, relative estimation and other relative techniques to compare between options. Humans are bad at estimating in absolute units. We are much better at relative estimation and planning.

Defining the t-shirt sizes #

Use XS, S, M, L, XL as a way to bucket the unit of work.The idea is to go over user stories or unit of work in a team setting and have team members put it into one of 4 buckets. T-Shirt sizes can be mapped to 1 man work weeks which can be anything as decided by the team itself. I usually have seen a variation of below table.

Considerations #

To make sure that our t-shirt size estimates are realistic, you should consider the following factors when choosing a final size. I usually grade / size each one of these areas separately and then weigh them against each other. You and your team may use different weights for sizing to come up with the final size for an effort.

Understanding of the requirements #

Essentially, the more information you have on the scope of the project and the desired outcomes, the better it is.

Are the business requirements defined and have they been validated with users with an appropriate technique (such as walk-throughs, workshops, etc.)? Here, I consider the following three (3) conditions: requirements fully defined or understood, business case understood along success measures defined, and deliverables defined. If all three of these conditions are met, this is Small sized. If two of the three are met, then it is a medium. If only one condition is met then I consider it a Large. If no conditions are met, it defaults to XL.

Practical Experience and Knowledge #

Depending on project specifics, the team might need to use complex tools, third-party APIs or even find custom solutions to some problems. Thus, an estimate needs to cover the research or the learning curve involved.

Here I consider the following three (3) conditions: the project will use a proven approach with plenty of samples, this type of project has been done before here at Sphera, and this project will use techniques that have been applied to this type of project before. As before, if all three conditions are met, I usually consider this a S. If only two of three are met, it is a M. A single met condition is a L. No conditions met makes it an XL.

Design complexity #

The size and scope of a given design is of particular interest and can have a major impact on estimates.

Here I consider the following size factors as a proxy for complexity. A smaller number of modules (5 or less) and limited to a single service boundary is typically a S. Five to 15 modules and a more complex service or more than one service is typically a M. Multiple services, events and integrations or more than 50 modules is typically a L. XL is for very complex interactions spanning multiple services and and PaaS functionality.

The teams #

While not always known at the planning stages of an effort, the team, its composition, and availability has a very large impact on actual delivery times and estimates.

Here, I will focus on team stability or cohesiveness. If a team has previously worked together and there is low expected turnover on the team during the duration of the effort, I mark this as a S. It becomes M for teams that have not worked together before OR there is expected turnover during the duration of the effort. It is L of the team has not worked together before AND there is expected turnover. Finally, I mark it as XL if, in addition to the H criteria, the teams are geographically dispersed.

It can also be useful to consider the experience makeup of the team selected for the effort. What takes a senior software engineer an hour to implement might take a junior dev several days. Therefore, estimates should be tailored to the team that will work on the project.

Comparisons to previous work #

Another quick and easy way to t-shirt size work is in comparison to previous efforts. If there was a previous project that was M in size and everyone can agree that the new effort is bigger by roughly 50%, then it is probably a L. This approach is very useful at the T1 stage of estimation. It is really not useful with T2 and even less so with T3 estimation (see below for explanation of estimating approaches).​

Accuracy improves as the work progresses #

For the purposes of sizing an effort, there are three general levels of accuracy that I strive to shoot for, depending on where and what we are attempting to accomplish. Because I am not very creative, lets call this different levels for sizing something simple: T1, T2, and​T3.

Project scoping and forecasting are an important tool for any industry. In Software, it helps teams to understand their velocity and discover unknowns early in the process. It helps executives for resource planning,defines sales and marketing strategies etc. In startups doing scoping requires a fine balance; too much time on scoping would deter the long term velocity and too little time can create wrong estimates and cause more stress and anxiety to meet the project dates.

​