Introduction
Effective project estimation is crucial for successful project management. In the world of Agile software development, the T-shirt sizing model is a popular high-level estimation technique that helps predict project scope and resource allocation. In this blog post, I will discuss the T-shirt sizing model for Scrum teams, its limitations, and how it can be used to estimate project costs while considering evidence-based scheduling.
Scrum Teams & Sprints
Scrum teams are cross-functional groups composed of engineers, designers, and product staff, widely adopted across industries for software development. They are supported by shared roles such as QA testers, dev ops, project managers, and user researchers, which can be part of the Scrum teams or work across multiple teams based on workload.
These teams typically consist of 7 +/- 2 members, following Jeff Bezos’ “two-pizza team rule,” which states that a team should be no larger than what can be fed by two pizzas (around 8 to 9 people). Sprints, or iterations, last two weeks, allowing teams to deliver software increments regularly.
Each Scrum team is assigned to a workstream that runs parallel to other workstreams. Reducing the number of Scrum teams leads to the combination of parallel workstreams, resulting in longer timelines for the same project scope.
The T-Shirt Sizing Model
The T-shirt sizing model categorizes projects into five sizes based on scope, complexity, duration, and resource requirements:
- Extra Small (XS): Projects or tasks with minimal features and complexity, requiring 2 sprints or less of 1 to 3 team members’ work.
- Small (S): Simple projects with few features, minimal complexity, and requiring 1 to 2 sprints of a single scrum team.
- Medium (M): Moderate projects with more features, moderate complexity, and requiring 3 to 4 sprints of a single scrum team.
- Large (L): Complex projects with a larger scope, significant complexity, and requiring 5 to 8 sprints of a single scrum team.
- Extra Large (XL): Highly complex projects with multiple components, high complexity, and requiring 8 or more sprints of a single scrum team.
Estimating Project Costs
To estimate project costs using the T-shirt sizing model, first determine the cost per team member per sprint. This can vary based on factors such as salaries, location, and overheads. For example, the median annual wage for a software developer in New York City is around $132,000. Given this salary and a two-week sprint, the cost per software developer per sprint is approximately $5,280.
Using this cost per sprint, we can provide ballpark dollar costs for each T-shirt size:
- XS: $5,280 to $31,680
- S: $26,400 to $94,920
- M: $79,200 to $189,840
- L: $132,000 to $379,680
- XL: $211,680 and above
The Limitations of Estimations and the Planning Fallacy
It’s essential to remember that estimates are just that—estimates. They are subject to numerous factors that can affect a project’s actual duration and cost. One such factor is the Planning Fallacy, a cognitive bias that causes people to underestimate the time and resources needed to complete a task (Kahneman & Tversky, 1979). This bias can lead to overly optimistic estimates that may not reflect the project’s true complexity and scope.
The Planning Fallacy is common human bias that I am fascinated by. I often encounter it, including in my own personal and professional work, despite my being keenly aware of it.
Evidence-Based Scheduling
Joel Spolsky, co-founder of Stack Overflow and Trello, introduced the concept of “Evidence-Based Scheduling” to address some of the issues with traditional estimation techniques. By collecting historical data on completed projects, evidence-based scheduling allows teams to create more accurate and realistic estimates. This approach considers the actual time taken by individual team members to complete tasks, rather than relying solely on expert judgment or high-level models like the T-shirt sizing model.
Spolsky’s method involves breaking down tasks into smaller units, tracking each team member’s performance, and using statistical techniques to generate a probability distribution of the project’s completion time. This helps teams to better understand the range of possible outcomes, rather than focusing on a single deadline. As a result, evidence-based scheduling can lead to better risk management and more informed decision-making throughout the project lifecycle.
Benefits of Evidence-Based Scheduling
There are several key benefits to using evidence-based scheduling in combination with the T-shirt sizing model:
- Improved accuracy: By basing estimates on historical data, evidence-based scheduling helps to account for the variability in team member performance and other factors that can influence project timelines.
- Reduced uncertainty: With a probability distribution of completion times, teams can identify and plan for potential risks more effectively, leading to more robust project planning.
- Continuous improvement: By regularly updating the historical data used in evidence-based scheduling, teams can identify trends and areas for improvement, leading to better overall performance over time.
Conclusion
The T-shirt sizing model is a valuable high-level estimation tool for Agile Scrum teams, helping predict project scope and resource allocation. However, it’s essential to be aware of the limitations of estimates and the influence of cognitive biases like the Planning Fallacy. Combining the T-shirt sizing model with more detailed planning and estimation techniques, such as evidence-based scheduling, can lead to better decision-making and more realistic expectations for project outcomes.
References
- Kahneman, D., & Tversky, A. (1979). Intuitive prediction: Biases and corrective procedures. In J. S. Carroll & J. W. Payne (Eds.), Cognition and social behavior. Lawrence Erlbaum Associates.
- Spolsky, J. (2007, October 26). Evidence-Based Scheduling. Joel on Software.
Thanks to my colleagues April Lane and Robert Gash for a discussion that included these topics that inspired me to publish this blog post.
You must log in to post a comment.