login


Google Sign inLinkedIn Sign in

Don't have an account? 

Project Estimation Using T-Shirt Sizes

Deadlines

17 July, 2019

Abhishek Bambha describes how and why he uses t-shirt sizes as a method to categorize time estimates for software projects.

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

Related stories

Moving Legacy Applications Into the Cloud
13 May

Peter Maddison, Founder at Xodiac, delves into all the important details of moving legacy applications into the cloud.

Dev Processes
Deadlines
Collaboration
Peter Maddison

Peter Maddison

Founder at Xodiac

Launching a New Product
11 May

Wayne Haber, Director of Engineering at GitLab, explains how he successfully turned a proof of concept to a full product.

Product
Prioritization
Deadlines
Wayne Haber

Wayne Haber

Director of Engineering at GitLab

People and Stakeholder Management in Times of Pressure and UncertaintyRecognizing Outside Pressures and How to Best Solve Them
26 November

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.

Conflict solving
Deadlines
Health / Stress / Burn-Out
Arti Kotadia

Arti Kotadia

Director of Program Management, EIT Operations at Peloton Interactive

Estimation Spreadsheets That Map Resources
8 October

Julia Graham shares how product and engineering collaborate on estimation exercises in order to suitably roadmap their available resources.

Collaboration
Deadlines
Product
Team processes
Julia Graham

Julia Graham

Product Manager at Airbnb

Project Estimation Using T-Shirt Sizes
17 July

Abhishek Bambha describes how and why he uses t-shirt sizes as a method to categorize time estimates for software projects.

Deadlines
Abhishek Bambha

Abhishek Bambha

Head Of Recommendations at Roku (Ex Twilio, Marketo, Myspace)

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.