Yes… and no. If we agree that the decision to release a software product is a business decision then I posit that the view will never change as business forces (e.g. time to market, a trade show, etc.) drive release decisions.

“Our customers shouldn’t have to prioritise bugs because they shouldn’t be being introduced in the first place.”

First, I believe that depends on your definition of ‘bug’. Is a deferred requirement or de-scoped feature a ‘bug’? If so, clearly the effort to develop that piece of functionality should be explicitly scoped, estimated, prioritized and tracked.

Secondly, avoding self-referential decision making is a lesson I revisit with teams over and over. Which is why I love the emphasis agile methods place on a close working relationship with the business owners. As members of the product development team we may have a good idea of how to prioritize our work, but ultimately it is the person writing the check that should tell us what they need and want.

“I’ve been in well performing teams that didn’t have to prioritise or estimate bugs because the number was so low that they could ‘absorb’ that as part of the normal day-to-day work, without impacting velocity (or raising concerns about tracking points against them).”

My lawyer charges me for every minute worked (including responding to my e-mails). So does my CPA. The same can be said for lots of other industries. Why do we as practitioners in the software industry continue to perform work and then hide it? No wonder that business owners and stakeholders continue to question what we are working on. We don’t give them nearly enough visibility into our efforts!

I agree that business should be able to prioritise new work over technical issues, but I think technical stories should be driven from a business need, rather than the other way around. Accumulating technical debt and then later asking the business to pay for it is not a professional approach.

I agree and disagree :)
Our industry has somehow grown accustomed with the fact that software contain bugs, and that’s acceptable. We need to change that view. Our customers shouldn’t have to prioritise bugs because they shouldn’t be being introduced in the first place. I’ve been in well performing teams that didn’t have to prioritise or estimate bugs because the number was so low that they could ‘absorb’ that as part of the normal day-to-day work, without impacting velocity (or raising concerns about tracking points against them). I know that’s an idealist view of the world, but it’s something we have to work to change (as you said, if you have lots of bugs then it’s a symptom of something else going wrong)

Having said that, if your team is doing only support work, then it’s probably mostly working on bugs, and then it might make sense to estimate/prioritise them. But again, this is work towards failure demand, which is considered waste in Lean. I guess you have to judge the merits of it based on your context.

Stakeholders should be able to prioritise new work over technical issues and I don’t see that really being possible without using comparable scales of effort.

If no-one can put business value on the technical task then arguably there is no technical issue at all, just the natural desire to fiddle with things to make them more intellectually or aesthetically pleasing.

Having said that, if you have lot of bugs found after stories are accepted then it’s a symptom of something going wrong in the development process which needs to be addressed.