Items selected for a Sprint Backlog - Do they get moved out from the Product Backlog?

but I see references in other materials for moving out.

@Monir Khan, It would have been nice if you could have mentioned what those references are.

From the Scrum Guide,

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

Do the items that are selected for the Sprint Backlog get moved out from the Product Backlog?

Even if it does get moved, so what? Wouldn't the value/functionality delivered be transparent through the implementation of those PBI's in the Increment? The remaining work will be transparent through what is ordered in the Product Backlog.

If they do, then how do we maintain a holistic list of all the items? Looking for some clarification / best practices as a Product Owner must (should) have a consolidated list for all the items in one place for reference. 

There are no best practices. If someone really does require a list of these completed items, especially when you are considering a physical backlog, wouldn't the completed items automatically form a sort of completed list at the other end? In electronic tools, we can view what has been completed or closed.

So, does the movement really matter? :)

Do the items that are selected for the Sprint Backlog get moved out from the Product Backlog?

Does that work for the product no longer remain to be "Done"?

Thank you both - Steve and Ian. 

@Steve Matthew

It was an explanation provided for a question that I was reviewing - the excerpt is below and the italic line in it made me curious ..

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. The Items in the current Sprint are no longer on the Product Backlog, because they are now on the Sprint Backlog.  

However, it is certainly fine for the Product Owner to add detail and clarification to the current Sprint’s work as well.

So, does the movement really matter? :)

In terms of getting work done, it does not really matter but in terms of being organized, I think it depends: I would like to keep all the items in one place (list) for any future reference purposes even though the value/functionality delivered by creating Increments. I would like to have a consolidated list so I can always refer to it easily. May be sounding like an organized freak :-) 

Does that work for the product no longer remain to be "Done"?

@ Ian Mitchell

I would consider they are "Done" so they no longer need to go back to the Product BackLog per the Scrum Guide. So that means if those items were moved then there's no reference for them in the Product Backlog. Maybe it 's not needed at this point but was just thinking out loud:--)

A lot of software tools will imply that items move from one backlog to the other. Jira is one such example that I'm familiar with, as items eithe appears in the "sprint" or on the "backlog". Tools have limitations, and can lead to a stifled view of Scrum. As you look beyond these limitations, you might look at Scrum's artifacts in a different way.

From the Scrum Guide:

The Product Owner is the sole person responsible for managing the Product Backlog.

…

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a "Done" product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

…

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.

The responsibility for these two backlogs is distinct, so logically I could see that an item would remain on the Product Backlog, even if a plan exists on the Sprint Backlog. Particularly as Sprint Backlog items and Product Backlog items might not map one-to-one, and the Development Team might find a more suitable way of achieving the Sprint Goal, which results in certain functionality or use cases being excluded from the Sprint Backlog altogether.

The Scrum Guide also says:

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

So until the Increment is released, there's a strong case that it should be kept visible on the Product Backlog in some form.