A development team wants to automate deployment and testing. How would this be placed in the Sprint Backlog? And, how does this relate to Scrum Goal? e.g. CI/CD could be large enough that it could encompass a whole sprint in and of itself.
There are different ways to handle it. My preferred approach would look something like this.
First, the work should be expressed in the Product Backlog. The work in the Product Backlog is the work that is necessary to improve the product. The INVEST criteria are a good way to decompose the Product Backlog items into small, independently deliverable chunks that can move the team closer to their desired end-state. If this is the primary focus of the team, this work may be related to the Product Goal, but it doesn't have to be.
It's important to express the Product Backlog Items in a way that make sense to stakeholders outside of the team. Stakeholders should be able to understand why it's valuable to take on their work. In the case of CI/CD, automated testing, and automated deployment, there would be an emphasis on reducing manual activities, preventing human errors during test and deployment, and improving quality by having more rapid feedback to name a few. This can help the stakeholders understand the ordering of the work and why they should invest in the team to take it on over some other work.
Once the work is brought into a Sprint, it may or may not be related to the Sprint Goal. Although the Sprint Goal is the primary objective that the team wants to achieve during the Sprint, not all work in the Sprint Backlog needs to relate to the Sprint Goal. The team would approach it just like any other Sprint work, pulling it into progress and completing the work.
If you work in a scaled context, there may be some other considerations. Perhaps one team can take on the work for a Sprint or two in order to create the foundational framework that is then available for the other teams to incorporate into their Definition of Done. If there's a shared service team for infrastructure or product quality, then this team may take on that work themselves in addition to providing their services. The same general approach of putting the work on the Product Backlog, ordering it appropriately with all of the other product work, and then pulling it into Sprints does apply.
My preferred approach is to do a 'hello world' story. Pick something small or trivial on the backlog and decide that you will be delivering it using continuous delivery.
Inform your stakeholders that although they will see only a small amount of value from this story, it will be the first story delivered using continuous delivery. Help them to understand the value of this approach.
It may also be possible to split the introduction of CI/CD over a number of stories that are delivered over several sprints. Once again, explain your approach to your stakeholders. You might say something like this:
Story X will be the first story to be delivered behind a feature toggle. Let me explain to you why feature toggles are good...
Story Y will be the first story to be delivered using our new fully automated end-to-end tests. With fully automated end-to-end tests we will be able to...