Project Estimation Using T-Shirt Sizes
17 July, 2019
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.
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
- 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
Marian Kamenistak, VP of Engineering at Mews, discusses how constant delays are usually caused by things other than inaccurate estimates.
VP of Engineering at Mews
Peter Maddison, Founder at Xodiac, delves into all the important details of moving legacy applications into the cloud.
Founder at Xodiac
Wayne Haber, Director of Engineering at GitLab, explains how he successfully turned a proof of concept to a full product.
Director of Engineering at GitLab
While now able to see leadership’s perspective from a better perspectivemore cognizant standpoint, Arti Kotadia, director of program management forand EIT operations at Peloton Interactive, reflects on how she dealt with a handful of pressures that leadership put on her team while working at a consultingant company.
Director of Program Management, EIT Operations at Peloton Interactive
Julia Graham shares how product and engineering collaborate on estimation exercises in order to suitably roadmap their available resources.
Product Manager at Airbnb
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.