There’s two types of leveling that I was interested in, new features and production bugs.

Features One approach had to do with alternating work on features. Let’s say a tester had to work with two developers, one on feature A and the other on B. They could do A first for a month and then B for the next month but didn’t. Instead they alternated so that there was never this accumulation of untested code commits growing for a single feature.

Bugs Meanwhile, as the drug-engine team removed sources of defects we had a pretty stable system of how we worked for new features. However there’d still be times when the developers weren’t ready or the BSA didn’t finish writing the requirements documents. So we filled in these gaps in work with the low priority production bugs of which there were countless. Even if the feature work was going well, we’d still intermingle some prod bugs because the longer code went untested, the worse the fluctuations. As a result we’d also increase our lead time. So even if we could typically write and execute tests for an issue in a week, we’d typically tell folks it’ll be ready in a month. I’d say this was an example of using time to control the fluctuation like is done with car delivery dates.