I was always under impression that Sprint Backlog is part of Product Backlog -> it's impossible to add anything into Sprint Backlog without affecting Product Backlog
However, according to one of the comments to this post, these backlogs "are completely different artifacts"
We are using an electronic Scrum board; would it be possible to add things like items from our Retrospective into Sprint backlog and avoid messing up Product backlog?
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.
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:
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.
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.
Generally, Sprint Backlog items should be decompositions of Product 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 install 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.
[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.
You're not completely incorrect in your impression of the Sprint Backlog. The Product Backlog is the tool used by the product owner to keep track of all of the features that stakeholders would like to see implemented in the product whereas the Sprint Backlog is a subset of the Product Backlog representing the current active Sprint iteration.
From The IT BA - Product Backlog vs Spring Backlog:
A product backlog is a list of all desired product features (weather you plan to implement them or not).
Anyone can add anything to the Product Backlog at any time. However, the product owner prioritizes it. So if you and I both add a feature request to add a quote of the day feature to a product, the product owner could very well put this at the bottom of the stack, meaning she doesn't really intend to have that feature added.
The Sprint backlog is a to-do list of backlog items to be completed in the current iteration.
The Sprint Backlog, on the other hand, represents the current Sprint iteration, and once a Sprint begins, no one should be adding or removing anything from the Sprint Backlog. The Sprint Backlog is put together by the team -- and in case this isn't clear, only by the team -- by selecting items from the top of the Product Backlog. If something is not in the Product Backlog then it should not be in the Sprint Backlog.
If someone later on wants to add feature Y to the list, and it's a high priority item, it still goes in the Product Backlog, and if it's an important enough feature, the product owner can move it to the top of the Product Backlog so that it's likely to be selected in the next Sprint iteration.
The hierarchical relationship between a Product backlog and sprint backlog is caused by the iteration configuration in your timeline (by making sprint iterations children of the release iteration). Each timeline can have one Backlog iteration (that would normally be associated with the Product Backlog).
I can't think of any advantages to making the Scrum Backlog Tool a parent iteration. By associating it with the timeline as the defined Backlog iteration, it gets some special status. Adding it to the iteration hierarchy probably just crufts things up (you'll have more layers to navigate when picking an iteration, for example). It may also cause issues with roll-up displays in the plans -- you may now see roll-ups into the Product Backlog, which is not its purpose and may make it harder to work with.
