Your Product Backlog and Scrum
The product backlog is a true scrum artifact and the master to-do list for the entire project. All scrum projects have product backlogs, and they are owned and maintained by the product owner.
The requirements from the product roadmap initially create the product backlog, and the highest-priority ones are broken down into user stories on Day 1.
In traditional project management frameworks, change was viewed as a reflection of poor planning. If something had to be changed, it was because someone messed up. In scrum, you see change as a sign of growth. As you discover your product more deeply, you will identify changes that need to be made. In scrum, if you’re not changing, you’re not learning, and that’s a problem. It’s a lack of change that is a sign of failure. Every day you need to learn something and that causes change.
Each item in the product backlog has the following elements:
Specific order number (priority slot in the product backlog; although product backlog items may be similar in priority, they cannot be worked on at exactly the same time).
Estimate of the effort required to complete.
ID number (optional).
Type of item (optional). This could be a requirement, overhead, maintenance, or improvement (see the following section).
Highest-priority requirements get broken down into the smallest actionable requirements possible in the product backlog. However, a small requirement doesn’t automatically make it a high-priority item. Many small requirements of low priority will likely never see production.