Backlog should not be confused as a Requirement Document. When applying Scrum, it’s not necessary to start a project with a lengthy, upfront effort to document all requirements.
A backlog is a list of features or technical tasks which the team maintains and which, at a given moment, are known to be necessary and sufficient to complete a project or a release. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers – Progressive Refinement, Emergent and Prioritized.
Product backlog can be considered as the ultimate “to-do” list for the team and Product Owners. It should contain at least three levels
- Product backlog
- Release backlog
- Sprint backlog
Product Backlog can be defined in as structured or as loose as you think is right for your project. Typically PO or Business Owner finds the Business value at an Epic or a Theme level.
User Story – Is an atomic form of a User Need, which can be delivered in a given sprint. It is characterized as a self-contained unit of work which constitutes the building blocks of a Sprint. Typically expressed as “a <type of user> I <want/can/am able to/need to/etc.> so that <some reason>”
Epic – Is a large User Story, which can be broken down into multiple user stories after refinement and can span across multiple Sprint. Epic” is just a label we apply to a large story for example stories for a monthly reporting part of the system are at an Epic Level.
Themes – Is a collection of user stories. A group of stories, one or more, can be from 1 or more Epics. While stories comprising a theme are related, each is independent enough to be delivered separately and still provide some measurable sense of business value.