The Product Backlog is an emergent, ordered list of what is needed to improve the product, and an item is one entry on that list. Scrum says remarkably little about what an item should look like, and almost everything a candidate believes about items arrives from practices that grew up alongside the framework rather than inside it.
The list is the single source of work
The Product Backlog is the single source of work undertaken by the Scrum Team. Anything the Developers spend Sprint time on belongs on it, which includes defects, technical work and the research needed to answer an open question. A separate bug tracker or a private list of technical debt breaks that, because the ordering decision the Product Owner makes is then taken against an incomplete picture of what the team is doing.
Emergent is the other word worth pausing on. The list is expected to change as the product, the market and the team's understanding change, so a backlog that looks the same at the end of a quarter as it did at the start is evidence that nobody learned anything.
Ready means small enough to finish
Items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in Sprint Planning. That is the whole of what Scrum says about readiness. It describes size and shared understanding rather than a form to fill in, and the people qualified to make the judgement are the ones who will do the work.
Items usually reach that state through refinement, which runs continuously rather than at a fixed moment. Items near the top are small and well understood, while items further down can stay as a line of text, because refining work that may never be selected is waste.
User stories and epics are not part of Scrum
The Scrum Guide never mentions user stories, epics, acceptance criteria or a Definition of Ready. Not one of those terms appears in it. They are widely used practices that came from elsewhere, a team is free to adopt any of them, and a question that treats them as obligations is testing exactly this boundary.
What Scrum asks of an item is that the people who will build it understand it well enough to finish it inside a Sprint. Everything else about its shape is a local choice.
Why a Definition of Ready is risky
Scrum defines a standard for finishing and deliberately defines none for starting. Teams invent one anyway, and the trouble begins when it hardens into a gate. Items queue up waiting to qualify, Sprint Planning becomes an inspection of paperwork, and the Product Owner loses the ability to bring urgent work forward.
A working agreement about what usually helps an item get started is harmless. A rule that forbids selection until a checklist is complete is a stage gate, attached to a framework built to remove them.
Split so that each piece is usable
The splitting practice worth learning is to divide an item so that each piece delivers something a user could actually do, rather than by technical layer.
Splitting by layer feels tidy and produces nothing usable. A database change, a service change and an interface change each occupy a Sprint, and until the last one lands there is no Increment worth showing and no feedback to be had. A thin slice through every layer that serves one narrow case is smaller than the whole idea, and it can be released, watched and learned from while the rest of the idea is still open to change.