Working with UX designers during a sprint

There's no best practices. What is best depends on your context.

In my experience, some aspects of UX research and design is more closely aligned with product management. Things like user research and information architecture may be done earlier, as part of creating and defining the initial Product Backlog Items. Visual design is probably going to happen during or even after refinement. Some work that your UX designers do will be outside of the context of a Sprint, but they will also be involved in planning and executing the work during a Sprint.

It does make sense to be able to order, manage, visualize, and track the work done by the UX designers, even if it's outside of the Sprint cadence. There are a number of ways to do this, so you may need to experiment and find what works for you and what makes sense based on your tools and way of working.

I am trying to figure out how the developers will know that UX is done with their stories and it’s ready for them to Work on. Or should we create a Kamban board for the UX team ? 

Why do you think that UX is a separate concern for another team to work on?

I'd suggest that a Scrum Team ought to have all the skills to self-manage and ensure that their work is Ready for Sprint Planning.

UX is either :



A consideration required to complete a done increment, in which case, UX is a skillset inside the team, and how the team then organizes to complete that work is up to them as a self-managing group. 



Or



Not a consideration for releasing a done increment, in which case, why is it even a concern? (The more pragmatic offer would be that UX as a component of backlog building and creating PBI's might make sense, but since the team should be able to decide how the work gets done, if they are truly self managing, the work will get thrown away often. in which case, why bother?) 



Realistically, it sounds like you're not describing a scrum team, and so the answer is; create a scrum team. Bring UX into the team, and make sure it contains all the skills required to release an increment. 



People with a UX specialized skillset will naturally spend more of their time helping in backlog refinement activities than in getting in progress work to done, but there is stll benefit to having them in the team, with their priority on the done increment, so their skillset can help with the actual build and delivery of user value. (I've seen UX designers become the most unhelpful stakeholders because they come to sprint review and want to know why things don't look or behave exactly as designed. By having them in the team, that problem disappears)

First, stop thinking in the terms of stories since they are not actually part of the Scrum framework.  

Second, start thinking in terms of work that is needed in order to produce an Increment.  From the Scrum Guide, the increment is described as

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Also consider the description of the Scrum Team from the Scrum Guide

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Refer to the description of the Developers from the Scrum Guide

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog;

• Instilling quality by adhering to a Definition of Done;

• Adapting their plan each day toward the Sprint Goal; and,

• Holding each other accountable as professionals.

Use the description of the Sprint Backlog from the Scrum Guide

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Given all of that, I feel you should not be asking us this question.  You should be asking the Developers the question. Wouldn't you agree?

Take a look at the PSU Suggested Reading: https://www.scrum.org/resources/suggested-reading-professional-scrum-user-experience



Maybe you can take inspiration from  https://www.jpattonassociates.com/dual-track-development/ , which is on the suggested reading list. The article talks about how UX and other product development activities can be integrated into one Scrum Team.



To address some comments made above: the Dual Track Development article describes UX Design as "discovery work", and all members of the team may be involved in doing the work. It is part of the cycle to get to a Done increment. You will define work to be done, refine it, complete it, experiment and learn (and throw it away if that's what you learned): all product development activities. What you should not do is treat it as "the analysis phase", no: it IS development work.



Sometimes you'll see "refinement" being described or treated as "analysis" and essentially being a phase, that it is not. Sometimes you see Product Owners who are analysts, they are not. Analysis is one of the development activities, and the analysts are Developers. This is why Kanban teams may have WIP limits of 0.5 or even lower (0.5 = 1 Work Item per 2 Developers): because they aren't all programmers, chemists or lawyers (you can develop other products than software!), people with different skillsets are working on the same item, and it is all "development".



In summary: UX is development work, and should be done during the Sprint by the Developers.