TL;DR
Projects change, products evolve, and team composition often needs to change along with them. Slack and reasonable levels of idling are the cost of doing business in an agile framework, but don't be afraid to add or remove people from the Development Team when it measurably benefits the project.
Analysis and Recommendations
Analysis
You may have a cross-functional team, but your UX person sounds like they aren't themselves cross-functional. This is really the X in your X/Y problem. At heart, you're asking what you should do with this person when they aren't being adequately utilized within your current business context.
Don't fall prey to the 100% utilization fallacy. 100% of the Development Team does not need to be utilized at 100% for an effective Scrum implementation. In fact, very high levels of utilization will often reduce flexibility, throughput, and self-organizing behaviors within the team. Don't do that!
If you've gotten towards the end of a project, it may be too late to start encouraging a Development Team member to become cross-functional in a way that brings a near-term benefit to the current project. The optimal time to have done that would have been earlier in the project lifecycle.
However, if you take a longer view, it's never too late to train teams or individuals for future needs. This is especially valuable in organizations with long-lived teams that will work on multiple projects over time, or companies where there will be similar/related projects in the future.
Recommendations
In your specific use case, I'd evaluate whether the project still needs a dedicated UX specialist on the team. If any remaining UX work can be handled by another cross-functional team member, or if the Product Backlog can be pruned of optional or non-essential UX work (under the YAGNI principle), then you should strongly consider removing your I-shaped UX person from the team altogether. You can then decide whether to stick with a reduced headcount for the time being, or if it makes more sense to replace the I-shaped person with a more T-shaped individual who can work on other deliverables in addition to any future UX tasks.
Don't think of this as a matrixing opportunity; that's not at all agile. Removing a specialized team member may require treating future UX work as an external dependency or schedule risk. Adding another team member in the future, whether the same person or someone unfamiliar with the product, often requires significant ramp-up time on both product and team process, and this will likely fall afoul of Brooks' Law.
In the end, it really just comes down to a cost/benefit analysis. You should calculate:
- Whether the cost of carrying an unproductive team member for the remainder of the project against potential future need will have a material impact on the project's budget or profitability.
- The opportunity cost or schedule delays that might be encountered if the team loses a dedicated resource.
Collaborate with the Scrum Team and line management to determine the cost/benefit and gain consensus; then have senior management make a business decision. It doesn't actually matter what you collectively decide, so long as the majority of project stakeholders (including the team itself) see the decision as sensible and necessary. Treat any residual risk related to the decision the same way you handle other project risks: accept, mitigate, or transfer it.
Disrupting a cohesive team should be a last resort, and shouldn't be done based on the needs of a Sprint or two. However, updating team composition to better meet the needs of the project in a forward-looking way is a valid way to "[w]elcome changing requirements, even late in development."
