That doesn't work in teams with collective code ownership, ie all successful teams. But you can replace this with "assign to a single team" and i think it works much the same. The footnote to this says:
> For larger teams, that can be a team account, but in that case, it is team leader responsibility to go through all team owned tickets regularly and delegate them
But that isn't correct. You can have a team pull from a single queue of tasks assigned to the team as a whole. There's no need to proactively assign them to individual team members.
> Every team must have a single ordered queue of tasks.
As long as you understand that "tasks" does not encompass technical housekeeping tasks like refactoring, improving the test pipeline, etc, sure. The queue of tasks needs to be ordered by someone with customer/business/domain knowledge. There's a negligible probability that this person is also expert enough to prioritise housekeeping against feature work. But the development team itself can do that, no problem.
> I advise to start with the “Todo”, “Doing” and “Done” triad and only add more if absolutely required
This sounds good. My one thought is that there are usually different people who can say "i think this is done" (the development team) and "yes, this is done" (product owner / QA / etc), so i suspect todo/doing/ready/accepted as the minimal set. But you could find a way to make three states work, i'm sure.
> When people scream “this is a bug”, it is irrelevant what it is caused by
It's relevant to estimating velocity. If over a quarter, you estimated you'd do a hundred features, but actually did one feature and ninety-nine bugs, you should not plan to deliver a hundred features next quarter.
It's relevant to continuous improvement. If you're getting a lot of feature requests, great, carry on. If you're getting a lot of bug reports, not so great, slow down and see how you can improve.
> Saying “no” is hard, but without it, the issue system becomes an unmanageable mess.
We must recognise this as simply being an expression of the author's deletionist aesthetic preference, not a fact about the world. As long as you know what the most important tasks are, it doesn't matter if there are an infinite number of less important tasks behind them.
> Yet I do believe this is actually a property of any job position: people rarely want their job to disappear. The moment you create a job position, it tends to metastasize.
Very strong truth! My third (?) law is that if you hire someone to do something, then that thing will get done regardless of whether it is actually useful. I am most often reminded of this law when dealing with security people.