If I read this correctly, you are asking about your board / workflow design rather than the overall circumstances in Scrum, so I'll focus my answer on that.
First, when designing a workflow, especially more complicated ones like this, the benefit comes from matching your process. Since I don't know your process, I don't know how closely this matches it so I can't say if it succeeds in that regard. I can, however, identify a few common patterns I've seen elsewhere that you should consider.
As a rule, queuing stages are problematic because no one is doing anything in them. A big red flag that something is a queueing stage is that it starts with "Ready For". When we have queueing stages in our system, this means that either we want things to sit around with no one working on them (pretty rare), or we're trying to hide a bottleneck.
As an example here, you have a development stage followed by a testing stage. No action happens between the two so there should be no stage between the two. Typically when I see this in boards, it is so the developers can move faster than the testers, which is local optimization at the expense of global sub-optimization (or to take the jargon out, we slow down the actual completion of work to make ourselves look better).
If I want a visual indicator that something is ready to be pulled to the next stage, I usually recommend changing the card color or adding an icon in electronic tools and just a magnet or sticker on a physical board. Or, to be a bit more pedantic, team members could just talk to each other.
I'll pick on estimation for this one. I'd be curious what value you get out of the estimation stage. Usually estimation is a quick conversation and when I see these in other teams, a lot of times the team is done with the task before they even remember to move the card. For most teams, "Work must be estimated" could just be a policy for a card to move from Draft to Ready. Of course, I could be completely wrong. It isn't common, but some teams benefit from robust estimation techniques that warrant this being its own stage. Your team needs to make that decision for themselves.
Testing Failed and Cancelled
These just feel odd to me. They feel like information more than workflow. I feel like I could just put a red dot on the card and completely eliminate the need for these stages entirely. My biggest concern when I see stages like this is that they are often used to set aside cards that would otherwise "look bad" on the board. Again, decide for yourself if these add value.
I feel like this board could be:
Draft - Development - Testing - Deploying - Done
and you could use other visual indicators to show the extra information. But, it's your board and you know what really happens in your team. When I coach teams, I usually say that I'll never tell them their board is wrong, but they should always ask themselves if visualizing their work in a certain way teaches them something they can use to improve how they work. If so, it is doing its job.