Project Estimation Using T-Shirt Sizes

Problem

Project estimation for software is an age old problem. As a result, there are a lot of solutions to choose from. I have found that categorizing tasks using t-shirt sizing has been an effective agile estimation technique. It scopes large amounts of work in relatively less time and doesn't get into the analysis- paralysis paradigm.

Actions taken

Rules of scoping

• Speed over accuracy. Planning and/or estimating don't deliver any value by themselves. Get it done fast and use the team's agile delivery to modify plans as you go.
• Collaborative techniques . This requires complete team participation. The accuracy of estimates is much better if more people are engaged and involved. This also avoids getting caught up in the blame game.
• Relative units. We don't 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 your units of work.The idea is to go over user stories or units of work within a team setting, having team members put items into one of the 4 buckets.
• T-shirt sizes can be mapped to a 1 person work week. This 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 into any of the below buckets try to break it down and rescope.
• It's difficult to scope for unknowns, but usually with any unknown move the task to the XL range automatically. More iterations and research may bring the task to lower sizes. Size Estimate Work Range S 0-2 weeks M 2-4 weeks L 4-8 weeks XL 8-16 weeks T1, T2, and T3 scoping The scale of the 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 stakeholders require very high-level estimates in order to calculate the ROI among different initiatives. Based on my past work experiences I use the below metrics to define T1, T2, and T3. In startups, due to speed and resource constraints, getting T3 estimates is not as relevant. Stakeholders should use T1 and T2 dates with care for internal forecasting. T1 Technique Purpose: Strategic planning to calculate ROI Method: White boarding with stakeholders and technical leads Accuracy of delivery date: 50-50% Time spent: 1 hour T2 Technique Purpose: Rough estimates to date for internal forecasting Method: Design docs, test cases, user stories in Jira and story points accumulation Accuracy of deliver date: 70-30% Time spent: 1 week T3 Technique Purpose: Accurate estimates to date for client facing Method: T2 + API definitions, method signatures, and contracts; no unknowns. Accuracy of delivery date: 90-10% Time spent: 1 month

Lessons learned

• 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 also helps executives plan for resources, to define sales and marketing strategies, etc.
• In startups, scoping requires a sensitive balance- too much time on it could deter long-term velocity and too little time can create wrong estimates causing more stress and anxiety than needed to meet project dates. Source: https://medium.com/radius-engineering/project-estimation-through-t-shirt-size-ea496c631428