How do I assign the right number of Test Analysts to a scrum team?

In each scrum team, there are 5 Developers to 1 QA, and he is overwhelmed with work! Invariably the team are waiting for him to complete the QA, and he constantly feels under pressure.

Why aren't they self-organizing as a team? They currently sound like a silo of individuals and I am going to assume they aren't working towards a Sprint Goal, right?

They use story points to estimate the effort for each Story/Sprint, so perhaps they need to increase the number of story points to more accurately reflect the testing effort. But that alone wont eliminate the pressure for my QA Analyst. If 5 developers all finish their work in parallel, he is still under pressure to complete the testing to meet the Sprint end date.

You're right, making adjustments in story points won't help. Perhaps the Development Team need to consider improving their engineering practices such that testing can be done along with development rather than dumping all the testing towards the end (hint hint waterfall)

Hope that helps.

I am a Test Manager who has recently taken over a team of Agile Quality Assurance analysts.

What can you do to change the organizational culture which underlies this very practice, and promote self-managing Scrum Teams instead?

What am I missing here? I can assign more QA's but I want to be sure each one is fully utilised.

What benefit does it serve anyone to maximize utilization?

Imagine going into a shop to buy groceries, and you want the process to be as easy and quick as possible. Would you prefer that every checkout operator is 100% utilized, and there is a queue for each one; or would you prefer that there are enough staff to cope with the current demand, meaning there is no queue, and that you are able to pay instantly?

As a Test Manager, if you focus on utilization, you will cause bottlenecks.

Personally I have rarely seen it work effectively when testing is the exclusive responsibility of just some team members. As a Test Manager, you (and your team) may want to transfer into more of a servant-leadership role.

For instance, where I work, we had a very talented QA engineer who successfully stepped aside from his role as the sole tester in one team, and with the help of our other QA engineer, he led an effort to train all software developers in writing automated tests, coached them in various ways, helped them understand when testing manually might be a better option, and took responsibility for observing general quality trends (e.g. common causes of bugs, or gaps in our core test cases).

There were lots of benefits of this; but the main one we seemed to find was that there were fewer bugs introduced. Our theory is that this is a result of the people coding already spotting mistakes, because they've been conscious of testing throughout their own development effort.

If you are courageous (and courage is one of the Scrum Values), you might want to expose that QA is the bottleneck (I mean the act of ensuring quality, not individual people).

You might then use this as an opportunity to support Development Teams in taking collective responsibility for quality.

Some interesting discussions might arise from this. Are non-QA developers interested in being responsible for the quality of what they develop? If so, what help do they need? If not, why not, and is such an attitude appreciated in your organization?

I have done similar activities that @Simon Mayer described.  I've been a QA Engineer/Manager for a large part of my career.  The most success I have ever had was when the developers were responsible for testing their own code  They could pair with others, they could write automaton, they could manually validate but in the end it was the developers responsibility to ensure that the work they did was high quality.  

I would bet that the job description for your Test Engineers include phrases such as "ensure that defects are found", "ensure quality products are released", "coordinate with developers to find and fix defects".  None of those statements say that the Test Engineer has to do all the work, just that the Test Engineer is responsible for it being done.  They can be responsible but have others do the work.  I would also bet that similar phrases can be found in a Developer's job description. So why would you not hold the developer's accountable for those activities?