Software project estimation is an age old problem and hence come with a lot of flavors. In this post, I plan to cover T-shirt sizing as an effective agile estimation technique to scope large amount of work in relatively less time without getting into analysis — paralysis.
Rules of scoping
- Speed over accuracy. Planning and/or estimation don’t deliver any value by itself. Get it done fast and use agile delivery of team to adjust plans as you go.
- Collaborative techniques — complete team participation. 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.
T-Shirt size scoping
Use 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.
If an effort is big enough to fall in any of below bucket try to break it down and rescope.
It’s difficult to scope for unknowns, but usually with any unknown move the task to XL range automatically; more iterations and research may bring the task to lower sizes.
T1, T2, and T3 scoping.
The scale of T-shirt size scoping can be adjusted based on business and project needs. It may not be possible to have granular user stories defined if the project is in the strategic planning phase. Strategic planning is when stake holders need very high-level estimates in order to calculate the ROI among different initiatives.
Based on my past work experience I use below metrics to define T1, T2, and T3
In startups due to speed and resource constraint getting T3 estimates is not too relevant. Stakeholders should use T1 and T2 dates with care for internal forecasting.
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.
I hope this article provides one easy to use tool to your team for scoping, give it a try and then feedback me.