T-Shirt Size and total estimation, how to manage them?

Question

I'm working on a project and the Product Owner has to decide if and how many new game-features implement in a SmartPhone app. Those game-features have the goal of keep the user more active inside the app. Currently those features were explained by the Product Owner in a rough way, not detailed, but in a more generic way.

We planned a session to analyse generically every feature, splitting them in macro areas to develop (Drupal, Frontend, Middleware, ...), to estimate them, not with points, but with t-shirt sizes and the goal was to understand effort, risks, reusability of common components. At the end this estimation should output sort of a charts of features, from the most efficient to the last.

With efficiency we should consider users interest (coming from a survey) and estimation sizes. But, how could you precisely analyse t-shirt sizes like XS, S, M, L, XL? Would you map them with 1, 2, 3, 4, 5 and sum them? Or just check with gut feeling which one could be the most efficient to implement, just having a look at the sizes?

Answer 1

TL;DR

If you want to score things, you need to convert to a numerical or ordinal value to perform a comparison. However, part of the challenge is that you are using the wrong tool to compare features in multiple dimensions. Tee shirt sizing is a good relative comparison for level of effort, but isn't useful for comparing multiple criteria against each other with any granularity. You should use Theme Screening or Theme Scoring instead.

Theme Scoring

In general, when trying to rank features you want to use Theme Screening or Theme Scoring in order to compare features across dimensions. Theme Scoring uses two axes, where the X-axis is a set of epics or themes, and the Y-axis is a set of criteria. You can then tweak the relative weights of the criteria based on project goals (e.g. Project Success Sliders), or leave all the weights the same if you don't want to differentiate.

In any case, you then assign a rank of 1-5 to each criteria for each theme or epic, and a weighted score will emerge. If you have a large number of criteria, you almost always need to adjust the weightings in order to have a truly ordered set, but sometimes it's enough just to place your themes into a set of buckets (in this case, buckets #1-5) for later refinement.

Example

In this example, your Drupal, Front End, and Middleware themes are scored against effort, risk, and reusability. I used 1 as a "bad" score, and 5 as the best possible score; all criteria were equally weighted. Based on this example assessment of the criteria, we end up with a ranked priority of:

1. Middleware
2. Front End
3. Drupal

Obviously, your assessment and rankings may differ, but this gives you a solid example of how to filter and assess different aspects of a project, assign numerical weights to the criteria, and arrive at an ordinal ranking of the themes or epics that deliver the most value to the project.

According to the example assessment, the middleware delivers the most value, and should therefore be prioritized over other components. Pragmatically, you may not be able to deliver middleware without a vertical slice that includes both front and backend functionality, but it still helps you identify what work delivers the most bang for the buck.

Answer 2

I assume the surveys will yield a score each macro area, say like from 1 to 9, 9 being very high interest. I'd attach an ordinal scale to your t-shirt size estimates, 1 through 5. To make things relative, I'd take the user score for each macro area and divide it by the total user scores and do the same with the size estimates. Then I would simply divide the relative user score with the relative work size. This will bubble up the priority of those macro areas that score high for the user and will discriminate between two high scoring macro areas with different size work estimates where the lower work estimate will bubble up higher.

In this example, you can see Macro Area D beat G and F despite a lower user score because of the lower work estimate. H beat C because of a very low work estimate and C had a very high work estimate. Works pretty good.

So using "D" as an example, my formula was (7/41)/(2/32)*100 = 273.