Should BA or UX work be part of sprint backlog?

Because "a new Sprint starts immediately after the conclusion of the previous Sprint", everything in Scrum happens within a Sprint.

It seems like the real question is if UX and BA work should be planned as part of a Sprint or managed in some other way. Ultimately, this is up to the team, but my experience tells me that this type of work is more closely aligned with Product Backlog Refinement and would be managed however the team refines their work to get it ready for Sprint Planning.

If the work the UX or BA person is doing is to achieve the Sprint Goal, then it should be made transparent in the Sprint Backlog. 

There might be other work they are doing that isn't for the current Sprint Goal, such as customer interviews. You may consider that Product Backlog refinement and not include it on the Sprint Backlog.

How to deal with UX and BA work in Scrum? Should it be part of the sprint or not?

Think in terms of the Developers' accountability and the commitments they are making. Is that "UX and BA work" necessary for the Sprint Goal or for the Definition of Done to be satisfied?

"The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team."

Based on this definition, either BA and UX people are not part of scrum team or their work should be part of the sprint, correct? If their work is part of the sprint, it should contribute to sprint goal. As long as sprint delivers value, this means that BA and UX work sould be part of each deliverable. If so, how to fit it into a sprint which is let say 2 weeks long? For each product backlog item we need to do BA, UX, back end, front end development, and testing sequentially.

What do you think about my inference?

@Oleksiy, As you rightly pointed out, the Product Backlog serves as a dynamic repository of prioritised requirements overseen by the Product Owner to guide the course of product development. Within the Scrum Team, which comprises not only developers but also Business Analysts and User Experience professionals, collaborative efforts are channeled towards iteratively delivering functional product increments during each Sprint.

In response to your query regarding the integration of Business Analyst (BA) and User Experience (UX) tasks within a Sprint, allow me to outline the typical process based on my experience:

Prior to the onset of our Sprint, the Scrum Team, inclusive of BA and UX roles, partakes in refinement sessions. As you are aware, during Sprint Planning, the team selects a subset of backlog items to address throughout the Sprint. This deliberation necessitates the inclusion of BA and UX tasks, where relevant.

BA and UX activities can progress concurrently with other development tasks. While developers focus on a particular backlog item, BA and UX professionals initiates preparations for subsequent items in the backlog. This ensures a seamless workflow throughout the Sprint duration.

In our team, the determination of the number of Product Backlog Items (PBI) accommodated within a Sprint is guided by our velocity and Sprint Goal. Nevertheless, our Sprint culminates in a product increment that is potentially deployable. Thus, even in scenarios where not all BA and UX work can be fully realised within the Sprint due to constraints, significant progress is made to deliver a valuable product increment.

It's important to note that this process might not be universally applicable; rather, it necessitates collaborative efforts from you and your team during your Retro to determine the most effective integration of all required work elements for achieving a potentially shippable product. 

I understand that BA and UX roles work a Sprint (or more) ahead on PBIs to get these refined, before Developers implement these in the software?

BA and UX, just as architecture and testing and ..., should not be roles but considered as skills. With that I mean that any person who is interested in it can learn these skills and other related practices and techniques. People who do not yet have that skill can anyway participate in this work and ask questions, provide their perspectives etc based on their experiences and using their skills.

Once a team understands this, refinements are not done only by BA and UX roles, but with all team members. Refinement is about understanding the challenge of the market (of users) so the challenge can be addressed during a Sprint. People who will address the challenge (all team members) should understand the challenge, and as such participate in refinements.

Some BA work might/will be needed so the team understands the challenge.
Some UX work might/will be needed so the team understands the challenge.
Some ... might/will be needed so the team understands the challenge.
But not always. Certainly not in its totality.
The BA/UX/... work that was not needed to understand the challenge will have to be done in the Sprint that implements the PBI. And that's perfect. Because all the upfront work might be invalidated by new insights while working on the PBI, by getting new feedback during Sprint Reviews, by ...

As long as BA and UX are considered roles, and not skills, a waterfall approach will stay in place, potentially resulting in a lot of rework during implementation. For sure, there will always stay hand-over of the refined work from BA and UX to Dev.
With a hand-over there are a lot of filters in the communication:
- BA explains to Dev, based on the BA's understanding and what the BA thinks that is important for the Devs to know; also the BA will make assumptions about what the Devs know, are expected to know, etc. So quite some info is filtered out.
- Devs hear the message from BAs. Devs will make assumptions what the BA explains, what the BA does not explain, will hear meanings of words based on their owns experiences, etc. So again a lot of info is filtered out.
Involve Devs in the refinements pls, which includes they also do BA and UX work.

Hope this helps.
Grtz
Steven

The detail of how the work is done can be up to the team, but having a back log item defined and pulled into a sprint for BA/UX work is one way. The rest of the team can then also see the progress, contribute or at least see what is coming in the near future. 

Saying that, I prefer the BA and UX accountabilities to work in the team context as most as possible. Having the BA/UX work outside the team and only add partial time to the teams "sprint capacity", can cause division and a hierarchy to form, a situation to be avoided. 

I think it is easy to talk about accountabilities, skills, and not roles. However in reality it's a bit more difficult. Developers don't like to create designs in Figma, don't like to write specs. They like coding. I think it's quite normal to let people do what they like to do. 

Anyway there are several skills needed to produce a valuable increment in software development setting: BA, UX, BE, FE, QA. It is not possible to find people on the market who will do all of these. If all of these skills contribute to the current sprint goal, I find it quite hard to deliver a reasonably sized increment within 2 weeks. Or we end up with unfinished PBIs.

What do you tsay about this?

How to deal with UX and BA work in Scrum? Should it be part of the sprint or not? 

It is usually a part of the Product Backlog refinement where PBIs are getting ready for the upcoming Sprints (e.g the UX is preparing frames to support the readiness of the PBIs, BA works on the PBIs using their proficiency in the business matter) and also part of the work towards the Sprint Goal where selected PBIs are already in the Sprint Backlog (e.g UX and BA may need to do the changes, provide further support etc...).

How much is being done as part of the refinement vs. sprint goal work, needs to be discovered by the team and adjusted based on the past Sprint experience. 

What is important is to have everyone involved within the Scrum Team

I have seen a project where UX was working closely with the business sort of outside of the Scrum Team. Then the Scrum Team was asked to produce the BPIs based on the UX designs. 

It was a poor setup. The developers didn't understand well enough what the business wanted, the UX was often not efficient in regards to the technology.