The Product Owner owns the Product Backlog, and prioritizes it on behalf of the stakeholders. The Sprint Backlog is the property of the Team, and they are the sole arbiters of its contents.
Contents of the Sprint Backlog
The Sprint Backlog contains user stories popped off the top of the Product Backlog during Sprint Planning. However, the Sprint Backlog usually contains many things not on the Product Backlog, such as:
- Tasks that have been decomposed from the user stories accepted by the Team for the current iteration.
- Story points or time estimates for individual tasks.
- Refinements of the "definition of done" as it relates to a specific story or task.
- Refinements to stories that don't compromise the Sprint Goal or require the Product Owner to call for an early termination of the Sprint.
- In-sprint stories or tasks added by the Team to support the current Sprint Goal.
The Sprint Goal and stories accepted for the current Sprint are set during Spring Planning, but tasks (and occasionally stories) on the Sprint Backlog are updated and modified by the Team in whatever way they see fit--it's the Team's artifact, and is theirs to manage in support of the Sprint Goal.
Agile Means Change
While the stories accepted into the Sprint Backlog during Sprint Planning are generally fixed, if the team finishes early, they are encouraged to pull additional work off the Product Backlog if they believe it can fit into the current Sprint without compromising the Sprint Goal. In addition, sometimes additional knowledge or information comes to light during the Sprint, and the Team and Product Owner can cooperatively remove stories from the Sprint if doing so helps the Team meet the current Sprint Goal.
In addition, user stories are starting points for conversations with stakeholders (or the Product Owner if done by proxy), so adding and deleting tasks from the Sprint Backlog as stories are worked is quite common. Part of the art of Scrum is in differentiating between refinements that come from reducing the cone of uncertainty during a Sprint from changes to stories that jeopardize the Sprint Goal.
No Invisible Work, Ever
Generally, Sprint Backlog items should be decompositions of Sprint Backlog items, or supporting tasks that glue together stories in the current Sprint. Again, the art is in differentiating between tasks that the Team needs to create on the Sprint Backlog to support the Sprint Goal versus stories that need to be placed on the Product Backlog.
As an example, if you have a story that requires you to seed a database, you may need to add a task to your Sprint Backlog to stand up a new database server. Usually, this task would be added during Sprint Planning, but the task may not become obvious until later in the Sprint. In such cases, it's perfectly acceptable to add the newly-discovered tasks to the Sprint Backlog as long as they don't compromise the Sprint Goal or invalidate the stories accepted into the Sprint.
Team stories beyond that properly belong on the Product Backlog. For example, setting up a full-blown database architecture is a story that should be prioritized by the Product Owner as a prerequisite for other stories in the Product Backlog. These types of stories are generally added during Backlog Grooming, and occasionally during Sprint Planning; after that, they are treated like any other story in the Product Backlog.
Don't Fear the Product Backlog
[W]ould it be possible to add things like items from our Retrospective into Sprint backlog and avoid messing up Product backlog?
It depends. If your Sprint Retrospective leads to process changes or in-sprint tasks for the Team, then of course those things should be added to one of the backlogs. Tasks and internal processes belong on the Sprint Backlog; sub-projects that consume time or resources outside of individual story estimates belong on the Product Backlog.
Don't be afraid of "messing up the Product Backlog." The Product Backlog is not some inviolate, unchangeable document. A healthy Scrum process should encourage ongoing conversations between the Product Owner and the Team, and encourage adding infrastructure and tool-chain stories to the Product Backlog so that their costs and benefits are visible to the project and the organization.