Process improvement item in Sprint Backlog

Process Improvement Items identified in during sprint retrospective should not be added to the Product Backlog. 

The key difference between Product & Sprint Backlog

Product Backlog focus on 'WHAT'. Accountable- Product Owner 

Sprint Backlog focus on 'HOW'- Accountable- Development Team 

Generally, most of the process improvement items are linked to 'HOW' the team should deliver the product backlog item. As Sprint Backlog becomes the key reference artefact for the development team post sprint planning; process improvement items should be added to it. 

This also enhances the empirical process by bringing transparency for the entire development team and results can be inspected and teams can further adapt. 

You're correct. Team improvements like this are not meant to go to the PB.

According to the Scrum Guide, the Product Backlog is "an ordered list of everything that is known to be needed in the product". That precludes many, but not all, process improvement items from the Product Backlog. I would make the case that some items, such as those that would improve the testability or the easy of deployment of the product may be appropriate for the Product Backlog. My guidance would be to determine if the change has an impact on the functional or non-functional/quality attributes of the product - if it does, then the Product Backlog may be an appropriate place for it.

The Scrum Guide defines the Sprint Backlog as "the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product increment and realizing the Sprint Goal." Since process improvements would likely impact the plan to deliver the product increment, then making them visible as part of the Sprint Backlog is important to ensure transparency throughout the process.

I would also make the assertion that potential process improvement items should be captured somewhere and prioritized. Of course, how you do this depends on the tools that you are using for managing your Product Backlog and Sprint Backlog - I'd do it differently with physical note cards on a wall than I would in a tool such as Jira. I believe in visibility and transparency into potential areas for improvement can help the team remember them and enact them when appropriate.

Since process improvements would likely impact the plan to deliver the product increment, then making them visible as part of the Sprint Backlog is important to ensure transparency throughout the process.

It could be argued that they *should* impact the plan. A process improvement item ought to be timely, and therefore relevant to the work in hand.