What metrics can we generate from t-shirt sizes (rather than story points) when estimating user stories?

Question

If I am using T-shirt sizing for my user story estimates, what metrics I can measure and report? We currently use a Sprint burn-down chart when using story points.

Answer 1

Summary

To calculate velocity when using non-numeric relative sizing, you first need to map your story sizes to numeric values. I provide a working example of how to do this with tee shirt sizes, and then show how to calculate the mean velocity of some shirt-based Sprints.

I also provide some of my thoughts on this as an agile technique, and some suggestions about when using non-numeric sequences can make sense. Feel free to skip that part if your heart is set on using tee shirt sizes.

Use Enumeration

You need to use a technique called enumeration. In this technique, you:

1. List all your story sizes from smallest to largest.
2. Assign an ordinal (but not necessarily sequential) point value to each element.
3. Use the numerical values to perform any mathematical calculations.

You can do this in the programming language of your choice, in Microsoft Excel, or by hand. The technique itself is the same, but the implementation may differ based on your tools.

Ruby Example

Here is a Ruby-based example that maps tee shirt sizes to the modified Fibonacci sequence. Once you've assigned a point value to each tee shirt size, you can then do whatever you'd normally do with a numeric story size.

# Map each tee shirt size to a point value. The value
# doesn't really matter, so long as it increases along
# an axis.
tee_shirt_sizes = {
    "S" => 1,
    "M" => 2,
    "L" => 5,
   "XL" => 8,
  "XXL" => 13
}

# Track your completed stories as an array of tee shirt
# sizes.
stories_completed = %w[S M XL M L S]

# Sum the point total for each tee shirt size. In this
# particular example, the result will be 19.
current_sprint = stories_completed.sum do |story_size|
  tee_shirt_sizes[story_size]
end

# Get your average velocity from an array of Sprint
# results. Since you're just working with numbers at
# this point, your calculations can be as simple or as
# complex as you choose to make them.
points_each_sprint = [21, 15, current_sprint]
mean_velocity =
  points_each_sprint.sum / points_each_sprint.size
puts "Average velocity: #{mean_velocity}"

Your output from this application will be:

Average velocity: 18

Question the Technique's Assumptions

Relative Sizing Imagery

The whole idea of using non-numeric sizing is to help unmoor estimates further from ideal hours, and to increase the team's ability to estimate relative to other stories. Whether tee shirt sizes really do that, as opposed to something easier to visualize like:

1. Meerkat
2. House Cat
3. Tiger
4. Elephant
5. Blue Whale

is (to me, anyway) somewhat questionable. While the technique is popular in the field, I have never found tee shirt sizes or drink sizes to yield better estimates than the Fibonacci sequence. It may help teams with the initial cognitive load of learning good estimation, but the quality of the estimates seem to have little to do with the "currency of estimation" once the team truly understands relative sizing.

Proxy Values

Perhaps more importantly, estimating in non-point values has many of the same problems as treating story points as a proxy for time. In particular:

1. The mapping itself often defeats the purpose of using non-numerical values in the first place.
2. It creates a layer of indirection if you're really trying to track capacity or velocity as first-class metrics, rather than simply trying to improve estimation of relative sizing.

As a purely practical matter, I tell organizations that want to plan in hours to just do that, even when it yields less reliable estimates than story points. The reason I do that is because the cognitive effort (and dissonance!) of pretending the team isn't really estimating in hours doesn't accomplish anything other than to force everyone to keep converting back and forth to come up with unreliable guesstimates anyway. I'm going to give the same advice to you about tee shirt sizes: If you need numerical values, use them directly rather than futzing around with conversion tables and enumeration!

When Non-Numeric Values Make Sense

Generally speaking, estimating in tee shirts, coffee cups, or mammals is not inherently a bad technique. I don't want you to think that it is, or that all the people doing it (whether well or poorly) are out of their minds. It's a good technique, but it's just often misapplied.

In my professional experience, non-numeric values for estimation are great when:

• Initially trying to break teams of the habit of estimating in hours.
• When the sizes can be truly seen as relative to one another yet unmoored from hours, points, or some other proxy value.
• In agile frameworks like XP or Kanban where batch size and flow are more important than capacity planning.

Since it's hard to really estimate how many meerkats and albino tigers can fit into a given Sprint without anchoring the sizes to numerical values anyway, and since it's never been clear to me how many crop-tops equal an extra-large tee shirt, I strongly feel that such systems aren't a good fit for capacity-based time boxes in frameworks like Scrum.

In Scrum, it's relatively easy to apply a fudge factor for a vacationing developer or an off-site meeting when you have a numerical value for velocity. Need to cut a day from a two-week Sprint? Cut your initial capacity estimate by 10%. Have 7 developers, and one is taking a two-week vacation? Cut capacity forecasts by at least 15%. Granted that these are just fudge factors, and the real planning values will need to be determined by the Development Team during Sprint Planning, but using numbers definitely helps guide a more accurate forecast.

---

Important Note: While the Scrum framework talks about capacity planning and forecasts for Sprints, it doesn't actually require velocity metrics, burn-downs, or other prescriptive practices.

---

Non-numeric estimates are much more valuable in frameworks like Kanban, where keeping work units as small as possible and as consistent in size as possible are core values. In such systems, work-in-progress limits (not Sprint capacity or velocity estimates) are the most important planning values. Using non-numeric systems as a quick way to sort work into like-sized buckets is great because the aggregate sizes of the stories aren't first-class metrics.

Conclusion

Story pointing is a great technique. I highly recommend it, as do many agile coaches and practitioners. You can use non-numeric story points by applying a variety of enumeration techniques to convert your arbitrary values to numbers, but this may or may not really buy you anything if your primary metric is numeric.

In other words, your mileage may vary. Shares can be worth more or less at redemption. Caveat emptor. Excelsior!

See Also

• Agile Estimation and Planning. Cohn, Mike. 2005.
• User Stories Applied: For Agile Software Development. Cohn, Mike. 2004.

Answer 2

T-shirt sizing is a way to do relative sizing.You can compare stories, as small,medium,large etc.Basically,T-shirt sizing is used for broad level estimations and maximum you can probably use it in planning as well.You can say,I will be able to accomodate 3 small stories and 1 large story in a sprint.