T-Shirt Sizing

The developers classify each feature's size relative to other features as Small, Medium, Large, or Extra Large. In parallel, the customer, marketing, sales, or other nontechnical stakeholders classify each feature's business value on the same scale.

T-shirt size estimates help a team conduct parallel, quick small group estimates early in a project (or multiple projects) without bogging down concerning points or exact numbers. This approach works well for large, complex program teams involving multiple technical organizations and user groups attempting to estimate multiple, overlaying projects for a coordinated release.

Description

Nontechnical stakeholders often want (and need) to make decisions about project scope during the wide part of the Cone of Uncertainty. A good estimator will refuse to provide highly precise estimates while the project is still in the wide part of the Cone. Sales and marketing staff will say, "How can I know whether I want that feature if I don't know how much it costs?" And a good estimator will say, "I can't tell you what it will cost until we've done more detailed requirements work." It would appear that the two groups are at an impasse.
This impasse can be broken by realizing that the goal of software estimation is not pinpoint accuracy but estimates that are accurate enough to support effective project control. In this case, nontechnical stakeholders are typically not asking for an estimate in staff hours. They are asking whether a specific feature is a mouse, rabbit, dog, or elephant. This observation leads to a very useful estimation approach called t-shirt sizing.\cite{McConnel_BlackArt05}
T-shirt sizing helps such teams to estimate by: \ref{Tabaka_CollaborationExplained06}

•  Providing a high-level abstraction language that specifically steers technical teams away from low-level technical detail in very early estimating efforts.
•  Allowing large teams to confidently break up the estimating work into parallel small group efforts.
•  Helping customers recognize early in a complex multi-project development definition what the gross efforts may entail.
•  Creating a placeholder, like a story card, for further discussion about the estimate when more detail can be discerned.
  In T-Shirt Estimating, as in story points, estimators work with a simple assumption to guide their estimating; for instance: Small (S) is probably half as big as Medium (M), which is half as big as Large (L). Prior to the estimating exercise, teams should agree on a rough standard for their use of the terms (some teams have the sizes increase more rapidly and on a sliding scale; other teams have the sizes represent much smaller increments in effort). Capture these assumptions clearly on a flipchart and make sure that all small groups working in parallel during the estimating exercise have access to the same set of assumptions. 

How To

In the preparation step follow these instructions: 

•  Prior to the meeting or as a previous agenda item in the meeting, determine which stories, requirements, or use cases will be estimated during the exercise. Also determine what the criteria should be for defining how small groups need to be working in parallel to complete the estimating.
•  Explain that the team will first resolve the assumptions about how to interpret the sizes for all of the subsequent small group work.
•  Ask for a volunteer from each small group to act as scribe for their group.
•  Have each scribe create a flipchart labeled "T-Shirt Sizes" and create a chart at the top for the size assumptions like in the example.
•  Explain that, for the remainder of the exercise, each of the groups will work independently to complete their estimates in t-shirt sizes.
•  Lead the entire team in a dialogue about the assumptions for sizing. Perform a consensus check about the accumulated assumptions and have the scribes record the final guidance for each size on the chart.

The second step is to introduce the agenda item that the team will be completing: "What are all the t-shirt estimated stories?".\ref{Tabaka_CollaborationExplained06}
In the last step execute the following steps for each story to be estimated:

•  Record the story title/description on the "Story Estimates" flipchart.
•  The developers then ask questions of the customers to clarify any needed information about the story in order to complete the estimate. Testers may also provide any clarity about the story that may impact the estimate.
•  The developers engage in discussion to determine an estimate: S, M, L, or XL.
•  In a consensus check, the final estimate is recorded on the flipchart and the "Total" column incremented by the estimate amount.

Examples

An example for a scale for T-Shirt sizing looks like the following table.

The discussion about what to carry and what to cut is easier if the feature list can be sorted into a rough cost/benefit order. Typically, that is done by assigning a net business value number. The following table shows one possible scheme for assigning net business value. You can use this scheme or come up with one that seems to more accurately reflect the values in your environment.

This sort of net business value lookup table allows you to add a third column to the original value/cost table \ref{table:TShirtExample} and to sort that table by net business value, as shown in the following table. The value of sorting by approximate business value is that it supports getting some quick "definitely yes" answers for the features at the top of the list and some quick "definitely no" decisions for the features at the bottom.