T-shirt sizing is ‘relative’ sizing and less prone to errors than estimation of effort, in real days.
For instance, you can be guaranteed that two developers are like two watches. They never agree when it comes to how long it will take to develop a piece of functionality. One might say that it will take two weeks while the other smirks with an I-can-do-it-in-two-days attitude. That may be true as different developers come with varied skills and experience. Relative sizing is about comparing two different pieces of functionality and agreeing on which one is smaller (or larger) in size and by how much. Rarely do developers disagree on this. And if they do, you can be sure that the story is not clear enough or there are major unknowns.
One way to estimate using relative sizing is to use the T-shirt sizes; small, medium, large and x-large. Too many sizes may confuse the developers and the team, so it is wise to stick to three or four sizes. You always estimate with more than one developer in the room, so that there can be a good debate about confusing issues. The skills and experience levels of the developers are not that important. It may even be good to have a wide spectrum.
Start by writing up cards with S, M, L, XL for each of the developers in the room. The Business Analyst or the Product Owner then explains the stories, one by one, and the developers estimate by putting forward one of the cards, simultaneously so that one does not influence the other. Whenever there is a mismatch in their estimates they discuss and debate the point in the room and re-estimate straight away. Usually it ends up with a consensus, as debates clear up the confusion. Always estimate with the end-users and stakeholders in the room to clear up any doubts.
At the end of this exercise all the stories would have been classified into the different size buckets. Now what? Sample and work out the time required to develop a small, medium, large and x-large, respectively. Start with one from each size bucket and break them down into developer tasks, at the minute level possible. It is not too much to break down to a task level of even an hour’s work. Then estimate each of these minute tasks to calculate how long it will take, in real hours, to develop a small, a medium and so on.
Sampling is quite important in this process. It is good to start with random samples and then move on to boundary samples. From each bucket, pick ones that seem to be the largest and the smallest. Estimate these. How much do they vary? Is the smallest medium larger than the largest small? By how much? What is the variance within each bucket? Can the smallest and the largest in mediums still be called mediums?
Depending on the results of the above analysis, the buckets and the stories in them may have to be rearranged.
Once this exercise is over, we can now apply the real estimates from the samples to all the stories in a bucket to get an overall estimate of the size of the project. It is now time to step back and take stock of the budget, cost-benefit, approvals, schedule, road map and so on before progressing any further.
