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
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Andrew Schamp, Software Engineer at Dropbox, recalls how he made a design decision using a tradeoff analysis that made them deliver a new beta product on a tight deadline.
Software Engineer at Dropbox
Nael El Shawwa, former VP of Engineering of Shutterstock, dissects the mystery behind assigning story points to tickets emphasizing that estimates should always be relative.
Nael El Shawwa
Head of Engineering at Perpetua
Nael El Shawwa, former VP of Engineering at Shutterstock, explains why reframing estimates is necessary and how that resonates with the very nature of the engineering work.
Nael El Shawwa
Head of Engineering at Perpetua
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 Inc.
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.