When your team is working on a project, you generally need to know how long the project will take and how much effort is required in order to understand the project’s overall cost and feasibility.
However, software estimation is difficult. No method of estimation is perfect. By having a number of estimation tools in your arsenal and using them properly, your team can provide useful estimates.
Three common methods of estimating that can be used in stand-alone and complementary processes are T-Shirt Sizing, Story Points, and Time estimations.
T-Shirt Sizing
T-Shirt Sizing is a quick and simple way to estimate the size of a feature or user story. The team starts by determining available sizes, usually from XS to XL (or XXL). Then, each item is assigned one of these sizes based on the effort, complexity, and estimated time to complete the item.
When to Use T-Shirt Sizing
- Preliminary Planning - T-Shirt Sizing is particularly helpful when first starting to plan a project, and allows you to get a “gut sense” of how much work something will be. By comparing this size estimate with the estimated criticality or impact of the story, you can quickly build out a rough roadmap of which items to address first.
- When Estimating Together - Estimation techniques such as “Planning Poker” can make excellent use of T-Shirt sizing. It’s easier to get team members to agree that an item is “Small” than to reach a consensus on whether an item will take 4 or 6 hours to complete.
When to Not Use T-Shirt Sizing
- You Need More Granularity - T-Shirt Sizing is great for quick estimates, but it’s meant to be a high-level approach. When you reach the point of refining your backlog, you may need to use a method that offers better granularity.
- You Need to Communicate to External Parties - T-Shirt Sizes are relative, to both the individual or team that estimated them, as well as to your organization as a whole. What one team considers a “Small”, another team may consider “Medium”, or even “Large”. Be careful when communicating T-shirt Sizes outside of your team.
Story Points
Using story points is a popular way of estimating software projects. A point scale, such as the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13…) is chosen, and much like T-Shirt Sizing, items are assigned a point value based on the estimated effort, complexity, and time to complete each item.
When to Use Points
- Experienced Teams - Points work best when the team using them has experience working together, and there have been no recent changes to their tools, projects, or processes.
- Needed Layer of Abstraction - Sometimes points provide a needed layer of abstraction over time. Since story points are not equal to time, they are able to communicate some extra data about effort and complexity. When first estimating a project, it is often easier to think in terms of points than hours.
When Not to Use Points
- Across Teams or Organizations - Both Story Points and T-Shirt Sizing are estimation tools that should be used internally by the team. They are abstract concepts to help the team estimate complexity and difficulty. If one team finishes 40 points a sprint and another team only complete 10, it does not automatically mean that one team is 4 times as productive.
- If You’re Really Using Hours - You can and should use points to help schedule projects, but if points are taken and immediately converted to hours, then your team may be better off using time estimates, and skipping the extra conversion.
Time
Instead of using an abstract estimation stand-in, there are other estimation techniques that use time (usually in hours or days). When using time for estimating, it’s generally a good idea to provide a range (ie 8 - 12 hours) and to beware of using units that contain too much precision. 500 minutes feels like a more accurate estimation than 8-9 hours or “about a day”, and can tempt users into treating estimates like promises.
When to Use Time
- When your Team is not Stable - Points and their corresponding metrics are unique to each team. They should not be compared across teams and they will not be reliable when a team is unstable. If a team is in constant flux (due to turnover, changes in projects, tools, etc.) it may be easier to estimate using time ranges.
- Repeat Tasks - If your team has routine tasks, you may already explicitly know how long the task will take, and there’s little need to assign a point value.
- External Communication - If your team works closely with other teams or clients, using time may work best. This is especially true when clients are paying you for your time. Since points are unique to the team, telling external parties the team’s estimated point value may not carry much meaning. When working with multiple clients across teams, it’s best to use a unit of measurement that everyone understands.
When to Not Use Time
- At Project Inception - Many teams find it difficult to think in terms of time at the very beginning of a project. T-Shirt sizing or Story Points may be an easier place to start, and user stories can be further refined into time estimates later.
- When Estimates are Taken Too Literally - If the team has estimated something to take 12 hours, that number, like all estimates, should be taken with a grain of salt. Estimates are estimates, and should never be taken as absolutes. If management or other parties think of hours as promises on the calendar, your team may be better off using points.
Use What Works for Your Team
Estimation is hard – and there is no one best practice that works for every team and every project. Don’t be afraid to let teams experiment with different estimation styles, and find the method or methods that work best for your team and your organization.
