What happens with not completely defined items in the backlog? And with old items?

we use some principles of Scrum to organize our work and the shipping of newer versions for our products

The Scrum Guide says: "While implementing only parts of Scrum is possible, the result is not Scrum".

What commitment is there in your company to implement Scrum in its entirety, so improved outcomes might then be achieved?

In the first place, we have hunderds of items in the backlog some dating over two years. According to the guys over at the Your Daily Scrum podcast that should like a code smell, if that happens maybe they can be closed since they're not a priority. What is your take on that?

If you have a physical backlog, like using sticky notes on the wall, then a large backlog can be a problem. However, in today's world, I'd strongly suggest that teams use electronic tools for their backlog. Depending on the tool that you are using, it could go either way. The team should be focused on the most important backlog items, and electronic tools often add a way to filter your view of the backlog. I've found that keeping the backlog items around helps people to keep notes on them available over time to understand when people ask about certain things or if there's relevant information discovered that has an impact.

That said, I do think there are some things to watch out for.

From the Product Owner's perspective, they should be looking for work that becomes a "we will never do this". If something is so far out of scope for the product that it's not something that needs to be considered, then it can be removed. The Backlog should be a place to see options that the team has. If it's not a valid option to consider, then it shouldn't be there.

Irrelevant bugs are also something that can be removed. Keeping known issues that still exist in the system can, in some contexts be valuable. However, bugs that have been fixed or the parts of the system where they exist have been so fundamentally changed (or removed) that the bug is no longer reproducible can be closed.

However, I'll also say that you'll find a lot of takes on Product Backlog management. Some people use Zero Bug Policies. Others have a more stringent take on what level of confidence in doing the work needs to exist for the work to be a potential in the backlog. At the end of the day, you need to find out what works for you and your team.

And even more importantly, a lot of those backlog items are not completely defined. Maybe they're missing a translation that needs to be added to the code, or work from the UI/UX team, or maybe they were added without the approval of the PO. Sometimes backlog items are created directly as a TODO-item or as an idea that is good to check on later. In my opinion, it is really a mess that there's a massive list of things to do and when you start reviewing them for a sprint all of them are missing something or were created without thinking.

I've been reading about the controversial definition of ready, but in practice, should we have a criteria for our items in the backlog? Maybe, adding a separate list for those items that are not yet defined or ideas that need to be worked on before someone can grab them and start working on? Or the items in the backlog should not be that strict and it is ok to have very broad items that are incomplete and that are to be refined later? in that case, when it depends on another team that is maybe Design or Communications, how do you deal with them?

The idea of having a completely defined Product Backlog Item going into a Sprint leads you down into an incremental waterfall approach. It's also probably pretty wasteful in terms of reward versus effort. Similarly, a Definition of Ready can be a useful and powerful tool, making it too strict and requiring a lot of up-front analysis and design can turn your process into a waterfall or "Scrummerfall".

Again, I'd look at your refinement and making sure that there's enough definition to make sure that the team understands what the item represents and what stakeholders are expecting and that the risk is sufficiently reduced. What this means varies a lot, team-by-team and organization-by-organization. It could also vary based on what the work is.

Delete any items older than 3 months. Keep the backlog with just enough for 3-6 sprints.

If something is important then it will be recreated and recreated with the most up to date information.

A major issue with keeping items for a long time is that they need to be reviewed, refined from time to time, which is a huge waste of money. 

Think of items older than an 3 months as hoarding, spring clean every few weeks and you'll have alot more headspace.