There are two backlogs in Scrum: the product backlog and the sprint backlog. The sprint backlog represents items that are being worked on during the current sprint, and the product backlog represents all items required to deliver the product. The following are items that are typically found in a backlog:
An epic is a container or placeholder for backlog items that span multiple sprints. Epics are not sized. An example of an epic might be something like “build an accounting module”. Epics are optional – you don’t have to use them.
A story is a feature that provides value to the business and stakeholders. A story is sized in points according to it’s complexity. A story is small enough to be completed over the course of a single sprint. Stories have a user-centered description like “as an accounting user I would like to see a list of checks that haven’t cleared”. They also contain a set of acceptance criteria. When the criteria are met (by definition of done standards), the story is considered complete. Stories are a required component of scrum.
Chores are work that is required in order to deliver current and future stories with high fidelity, but provide no direct tangible benefit to a stakeholder. An example of a chore would be “implement an IOC container to make the app more testable”. This is certainly something important, but not something that a stakeholder will actually use. Chores should be sized in points according to complexity. Chores are optional.
A spike is a time-boxed action item that is not sized using points. An example of a spike would be “call vendor to request pricing options”. If you practice capacity planning you can subtract spikes from your total capacity. Spikes are optional.
Bugs that are found during the sprint that relate to sprint work can be added to the current sprint backlog and do not need to be sized. Bugs added the the product backlog should be sized before pulling them into a sprint.
Tasks are individual work items that can be tied to all PBIs except for epics. Tasks are optional (but a good idea) and are created by the scrum team. They’re simply used to organize the implementation of a particular PBI. During sprint planning you can assign hours to tasks and gain the advantage of producing a burndown chart and performing capacity planning.