Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Scrum Guide 2020, https://scrumguides.org/scrum-guide.html#product-backlog
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Scrum Guide 2020, https://scrumguides.org/scrum-guide.html#product-backlog
A Product Backlog is Emergent
The fixed mindset of traditional software development led to long product plans that had to be fully implemented. We have learned in the mean time that software products exist in a space that is continuously changing and evolving, and that the teams developing products learn more and more about it and about the development practices that can help them as time passes.
This means that starting with a fixed product backlog that you expect to deliver exactly as defined, ideally within a fixed time period, is an illusion in most situations.
There are of course parts of problems that are more constrained. For example if you are implementing a physical simulation for a set of users from inside the organization, you can be quite certain that the laws of physics will not change during the development. Your users will most likely use the product you develop. And probably there will be little to no competition to your product.
These domains are very limited in nature though. In the real world, most products are facing challenges from the competition, opportunities and threats from technical developments, users who don’t know what they need until they see it and know it’s not it, increased understanding or intuition of the market from your product people, increased awareness and technical prowess from developers etc.
This can only mean one thing: it’s best to start with a clear problem, split it into smaller problems, prioritize the smaller problems, and keep iterating on the most important problem until you have found a market fit. This is in a simple phrase why product backlogs are emergent and not fully fixed and detailed from the beginning.
A Product Backlog Is Not Necessarily A List
Despite the Scrum Guide saying that the product backlog is a list, there are alternatives to this approach. The most useful one is User Story Mapping, a method that builds a map of the product as a flow from the point of view of the user and turns it into a 2-dimensional backlog.
This approach to building a backlog has the advantage of placing each of the backlog items in context and showing the development progress.
This backlog is also emergent, since new ideas appear over time, and older ideas are removed or replaced.
The Product Backlog is Owned By the Product Owner
Anyone can ask or contribute to the Product Backlog, but the decision on the order of priorities and on what to include is made by the Product Owner.
Advanced teams often come up with ideas and add them to the backlog as suggestions for the Product Owner.
The Product Backlog is The Single Source of Work for The Team
Some organizations transitioning from a task-based way of work have challenges with switching to this model. It is important to keep the team focused on developing the product rather than being split in multiple directions through demands toward individual members.
Instead, add every piece of work required to the Product Backlog, and ask the Product Owner to prioritize them.
Occasionally, team members will be requested to fix specific problems outside the product scope due to their skills and knowledge. This is obviously fine as long as it happens rarely.