There are three artifacts in Scrum, the product increment, product backlog, and sprint backlog. Artifact is just a fancy word for something made or given shape by man. Stonehenge is an artifact built by ancient druids 2,500 to 5,000 years ago, or according to some, perhaps built my aliens. Each of Scrum's three artifacts include what is called a commitment. I find that term a bit confusing. You can think of each artifact's commitment as what the Scum team is working toward with that artifact. With the product backlog, the team is working toward a product goal. With this sprint backlog the, team working towards a sprint goal and for the increment that will be built in a Sprint the Team is Working toward meeting a definition of done. Let's begin by looking at the Product Backlog. When I first started doing Scrum, that term didn't yet exist. So my teams called this a prioritized features list. I'm not suggesting a change to the vocabulary of Scum, but I still like that. The product backlog is a prioritize features. It's a list of the desired features, and it's been prioritised by the product owner. As such, the product backlog should contain everything the Product Owner once added to, or done to the, product. I should be careful when saying everything. The product backlog does not need to include things in the team's distant future. Why not? Because the project backlog is emergent. It evolves over time. The product backlog is always changing and evolving as the product owner and the rest of the team discover new information about the products. In traditional project management, we had a requirements phase. In that phase, We expected all of the product requirements to be known ahead of time. in Scrum,we recognize that we need to quickly adapt to change and that planning is good, but detailed planning should only occur shortly before we do the work. Because the Product Backlog is prioritized, higher priority items are at the top of this list and are likely to work on sooner. The items toward the bottom of the list may be vague ideas, and that's okay. As they move up the lists, more detail is added. Items on the product backlog should be created and prioritized in pursuit of a product goal, which I mentioned earlier as the commitment associated with the Product Backlog. The Product Goal describes a future state of product. it is essentially the products owner's vision for the The team and product owner can define a product goal that is any distance into the future. A month, a quarter, or a year, decade, an eon. My recommendation is that a Product Goal should be far enough in the Future to be inspirational, but not so far away that progress toward the goal is barely discernible each Sprint. I like setting a series of quarterly Product goals. Achieve one, and then set the next Product goal three months further ahead.