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.