We work in scrum teams with a product owner who is responsible for the backlog and prioritisation of that backlog. Recently the topic of un-ticketed work came up, developers for one of the applications are doing un-ticketed work that they regard as important. Typically this is tech debt but can also be things like migrating to a better library etc.
The argument from the developers was that these are generally small things and in an agile team they should be able to exercise their judgement and fit them in around sprint work. E.g. if waiting for the CI system to build and deploy they could tidy up some code. The effort of raising a ticket will take longer than actually doing the work. The work being done is tested via automated tests and so there is no additional burden on the QA members of the team.
The argument against this is that the developers are effectively saying their opinion on what work is a priority is more important than any other stakeholder and are not going to go through the PO so it can be compared against other work in the backlog. There is also a case to be made that if a developer has spare time then it would be more productive for them to be elaborating upcoming stories. The state of stories coming into sprint has been raised at retros before and so more elaboration can only help this. There is also a concern that the self policing of what size falls into this category may start to stretch and result in even more time being spent on un-ticketed work.
I can see both sides of the argument to an extent but should all work no matter how small be ticketed and go through sprint planning rather than be done as and when by developers if it is small?