How I use T-Shirt sizing as a Product Owner to estimate delivery
Effective use of T-Shirt sizing to quickly plan out releases as a PO.
Firstly, a few things this article is not. This isn’t a guide into why you should estimate or how estimates fit into Scrum — there’s already a good article written in this publication on that topic.
I work with Scrum teams using Story points predominantly. I’d recommend reading this article to avoid some common mistakes using story points.
I wanted to share an alternative estimating technique of T-shirt sizing instead of using Story points. This can be a good method for teams new to estimating. Then I’ll go through a couple of examples of using T-shirt sizing for planning product delivery.
T-shirt sizes for introducing relative estimation
T-shirt sizing as the name suggests is simply estimating with sizes similar to what you would find on a T-shirts’ label from Extra Small (XS) through to Extra Large (XL)... you can even keep going up to XXL, XXXL, etc. until it gets too ridiculous!
Where I find the most benefit of T-shirt sizing is they give an easy, clear understanding of relative sizes. This can be especially useful if you are working with a new team, the team is totally new to Scrum, or when trying to move away from estimating in hours.
While I prefer Story points they can take some getting used to. For introducing a team to estimation I have found anyone can quickly grasp the difference between a Medium and a Large story.
Like Story points, the variations in size indicate a difference in the complexity to complete a PBI. They are not exact time estimates (more like a range) so that we don’t fall into the trap of trying to guess the exact number of developer days. I find planning sessions finish quicker using this method because participants have to pick from a fixed set of sizes rather than trying to guess exact hours.
Here are two example stories:
As a visitor, I want to clearly see a PDF icon beside a link so I know it’s a PDF download.
As a visitor, I want to see the size of PDF files so I know how large it is to download.
In the former story, the requirement is to style links to show an icon. The latter story requires the file size to be calculated, stored and then displayed next to a link.
- Baseline the first story as Small to give relative sizing.
- The second story could be Medium or Large depending on the team estimating.
- The team can decide the first story is actually Extra Small if other Small stories seem bigger.
The downside of T-shirt sizing PBIs
Many of the tools out there for managing and measuring Scrum delivery base their reporting on points or hours, which makes them ideally suited for additive ways of estimating and measuring.
Unlike Story points, which can be added up, it is more tricky to review how much work is remaining or done. Your reports will indicate things like 10 Small, 4 Medium, and 3 Large PBIs were completed this Sprint. For this reason, it’s difficult to measure velocity, but not impossible. Instead, you have to map each size to an arbitrary, assumed value (i.e. S =1, M = 3, L = 5) then calculate your velocity and burndown.
In my example above, it would look like:
Velocity = 10 (S) + 12 (M) + 15 (L) = 37.
Also, relative sizing is subjective. It is easier to see that 3 points are 3x the size of 1, whereas it is harder to differentiate a precise difference between say Small and Medium.
If you are used to the Fibonacci sequence for Story points you can think of the T-shirt sizes when you are estimating PBIs in a similar pattern — XS (1), S (2), M (3), L (5), XL (8). Eventually, the team can switch to using these points directly.
You could argue that it is good not to add up T-shirt sizes. Estimating sizes are not meant to give an exact commitment. You will understand the relative size between features, but no one can know yet exactly how much time each item will take.
Delivery planning with T-shirt estimates
This is a technique used for providing an initial broad estimate. This may be the first round of estimating used to provide stakeholders with a rough idea of timescales in order to plan a budget and initial delivery date.
We decided at the company I work for to create a product to assist in this migration of content from a legacy website into the CMS software we work with. The intention was to remove the need for bespoke development to migrate old content and save time for our customers.
Initially, I worked with the stakeholders to come up with some high-level Epics the product needed to include. For example, there was a need for Importing Raw Data from the older site.
After the initial workshop, we had come up with 5 Epics for the MVP. The Tech Lead and myself went through each of these and gave them relative T-shirt sizes.
Securing access — S
Importing Raw data — M
Mapping Content types — L
Processing Import — M
Saving & Loading Mapping — M
My estimate range for each Epic size was
Small = 1–4 days
Medium = 5–10 days
Large = 10–20 days
Working with this range my initial estimate would put the first delivery of the product anywhere between 26–54 days. Yes, that’s a 50% margin of error but I did say this was an initial estimate and a rough time-frame. However, it did give management an idea that this MVP would be something that a small Scrum team could deliver in a couple of sprints.
There was a new client project that would need migration of content in about 6 weeks time. So given this time window, I decided to cut the least priority Epic, Saving & Loading Mapping, which gave a new rough estimate of 21–38 days.
Note that another option could have been reducing the scope to bring the Epic down from a Medium to a Small estimate.
The second round of planning
Now that I had my Epics ready I started creating placeholders for Product Backlog Items that corresponded to each Epic. I like to create a Story Map to help visualise the flow needed for different Sprints. The PBIs would still need further development into User Stories, but for the time being, I could validate my thinking.
I worked with the Technical Lead to create all the placeholder PBIs that I knew of for MVP and then we began giving each a T-shirt size from X-Small to Large. Anything bigger than a Large needed to be broken down into smaller PBIs.
For the epic Importing Raw Data here is a sample of the PBIs with their relative T-shirt sizes:
As an Administrator, I want to upload a text file so that it can be imported — M
As an Administrator, I want the system to validate the imported file for errors — S
As an Administrator, I want a preview of the text data to verify the content — L
My estimate range for each PBI size was:
XSmall = 1–2 hours
Small = 3–6 hours
Medium = 7–21 hours (1–3 days)
Large =28–56 hours (4–8 days)
After adding all of these together Importing Raw Data it came to a total of
S + M + L = 38–83 hours or 5–12 days.
That will still pretty close to the original Medium T-shirt size estimate of the Epic, but I obtained more insight into how big the individual PBIs were which prompted me to add a couple of extra days on the estimate.
This was not throwaway planning either. As part of this estimation process, the product backlog is being constructed. With expanded PBI definitions and acceptance criteria I then ran Sprint planning with the whole Scrum team. I removed the old T-shirt sizes and we estimated each PBI using Story points. While some of my original estimates were off I was surprised how many mapped directly from T-shirt sizes to Story points — using the Fibonacci to T-shirt sizing conversion. Below is a screenshot of the Story Map once points were applied.
Conclusion
There is no official rule in the Scrum guide as to how you should estimate. The more detailed you get into more granular individual PBIs the more precise your estimation and measurements can be. A balance is often needed though on how much time you spend estimating upfront without going into analysis paralysis.
Remember that estimation is only as good as how much knowledge you have available. T-shirt sizing I’ve found to be effective for its speed and ease-of-use when you still don’t have much of the information yet.
Scrum is a framework for building complex products in an agile environment which by its nature is hard to estimate and know what will happen in the future. We can plan our next upcoming Sprint with greater precision, but beyond that our knowledge is limited. Attempting to do everything upfront moves away from being agile and reverts back to more traditional Waterfall methods of delivery.
It’s no silver bullet and sometimes you will be way off, but often it can be helpful in determining the feasibility of delivering your product with a hypothetical set of features. Once your initial plan is set then you can keep building on this until you reach a confident delivery plan.
Special thanks to Rohit Ratan Mani and Willem-Jan Ageling.
