Introduce some sensitivity to ticket types and/or team member affinity

[danielnixon]

Currently, all tickets are treated the same (the simulation draws no distinction between ticket type or size or complexity or story points or time estimates or anything else).

This is done for a good (if perhaps surprising) reason: tickets spend the vast majority of their lives in "waiting" states (backlog, waiting for QA, waiting for UAT, waiting for deployment, etc). For this reason, the size of individual tickets doesn't have a meaningful impact on delivery time (or so the reasoning goes). Another argument is that this liberates our forecasting from estimating (e.g. story pointing) which is subjective...

I tend to agree with all that, and it certainly makes our forecasting algorithm simpler, but I can't help feeling like there are certain projects and certain team arrangements where this forecasting breaks down. Consider an example where you have a highly heterogeneous team, consisting of specialists with non-overlapping skills. There are going to be tickets that can only be worked on by certain people on the team. This ticket-person "affinity" may or may not be made explicit (via a label or some other categorization). This means that naively using our team velocity could lead us to incorrect forecasts. In such an arrangement we might get better results if we instead use the velocity of individuals (or groups of similarly shaped specialists).

This would complicate our model significantly, so it may or may not be worth it.

[danielnixon]

We may not even have to consider team members or specialist types: just having the labels on the tickets and considering those velocities separately may be enough.