What can the team do to prevent stories from completing until the last day of the sprint?

The team should be able to move the stories through the scrum board all the way to done. This should be without having to rely on resources outside the team. Is that possible with all of the phases in your process?

If yes, then how come the issues gets stuck and not completed? You should investigate and try to solve the issue.

If no, investigate what phases can't be finished and either remove those phases from the definition of done, or change the resources in the team to make sure all phases can be finished.

From my experience, setting interim goal of individual user stories target date spread across the sprint duration helped. That would of course require each story to be well sized and individually testable. Coupled with continuous integration and delivery, it helped me a lot to overcome this problem while leading technical delivery team.

Also, as you are planning sprints and choosing who will do what, look carefully for the dependencies that are always present in software. We use Microsoft Project® religiously to help everyone see how everything fits.

"Longer sprints" are often quite a bit more manageable.

Do stories generally get done by the end of the sprint? If so then leave things alone. Tracking the sprint burndown always feels to me like micro-management. The team are responsible for meeting the Definition of Done for stories by the end of each sprint. Track the product burn-up (or burn-down) on a sprint by sprint basis, not on a day by day basis.

You need to look at that is happening inside of your sprint. A few things that might provide insight include:

How quickly are items moving into your sprint?

If everything is moving into progress on day 1 and 2, this may indicate that your team is trying to divide and conquer. In this approach, everything starts on day 1 and ends on the last day by design (more or less). This can happen for a few reasons. The two most common are either that is is conscious or that work is split up by skills during or before sprint planning. The first - that it is conscious - is an education problem. Our intuition fails us here because it feels right that divide and conquer is more efficient, but in anything but strictly mechanical work, it almost never is. The second is a backlog problem. You need to have your backlog item represent capabilities or problems that you need multiple skills to solve.

How much time do items spend in wait states?

You have a lot of ready states in your process. This is fine, but keep an eye on them. Do things sit in them for long periods or pile up there? You might be seeing a flow problem where people are optimizing busy-ness of the person over the flow of work through your system. Tighter WIP limits can help with this, but you can't just jam that in. You have to also consider: do the team members and their stakeholders think it is better to get something finished quickly or to keep busy? Henrik Kniberg's Resource Utilization Trap video is still the best description of this problem out there.

Is your team focused on work items or the Sprint Goal?

This is one of the toughest mindset shifts when adopting Scrum. The work items (backlog items) are incidental. They are a way to put some bounds around a particular piece of work. They are a tool. Early on, focusing on the backlog items is useful. It provides something concrete to focus on day to day. However, in time, the team needs to shift that focus to the Product and Product Increment. There are a lot of articles on this - I'm not going to do it justice in a short StackExchange post. If the team has been practicing Scrum for a little while (I'd use a rule of thumb of maybe 4 - 5 sprints), the sprint goal should be front and center in every day's conversation. The backlog items will take care of themselves.

This list is by no means comprehensive. The problem you describe is incredibly common and these are the most frequent causes I encounter.

Seeing things like "Ready for UAT" and "UAT" in a workflow always raises a concern for me. UAT is almost always outside of the control of the development team, and often even outside the control of the development organization. These activities shouldn't be part of a team's workflow if they are beyond the control of the team.

I'd recommend making sure that your internal processes about development and testing that is within the team are sufficient to minimize the likelihood of showstopping issues being found during UAT. It's normal for feedback, but whenever the team says that it is done with the work, the work should be able to proceed all the way to production with minimal issues.

I'd also recommend performing UAT in batches. Rather than having users test and accept individual units of work, have them test and accept in a batch. This is very natural in something like Scrum, where you have fixed iterations with a regular review on a cadence. If you're doing something like Kanban, with a continuous flow, the process itself doesn't present a good opportunity, but you can define it on your own.

If UAT is finding problems that prevent acceptance, use that to fix the process. Really, UAT needs to be a formality. If you aren't producing a product that is acceptable to your users, something upstream is wrong. You don't understand what they want or need, you aren't building what they need, your tests aren't finding problems. Make it the formality that it should be.

Two options I see:

A) Split your stories into smaller stories. B) Make your Sprints longer.

If you're unable to get your stories done in a single Sprint, then either your stories need to be shorter (note the 'S' in INVEST) or your Sprints longer. Or both.

As always, since you're doing Scrum, bring it up in the Retrospective. State the issue, hear opinions, hear others' proposed solutions, ex[plain your own, then pick one.