Getting Un-stuck in TDD
A small variant of something Esther Derby said is responsible for the "most interesting" item on the list. She suggested a retrospective leader asking the team what they have the energy to do. That hit me. There is nothing wrong with picking the test you can most easily pour your energy into.
Writing the assertion and function name first has been greatly effective for me. Sometimes I leave the name as something generic until I can write an assertion that is meaningful, then I revisit the test name. If I have an assertion the ("check"), I know where I want to go. I can perform the setup (build) and the key method call (operate) . The Build/Operate/Check method also gives me more readable tests in addition to helping me maintain some semblance of flow.
Renaming and refactoring are helpful, even if the naming is not all that it could possibly be. This is because your eyes can become "stale": you don't really read the code your eyes pass over. One solution to this is to cause something about the code to be "new". Furthermore, if you increase readability then you may reach a state where wrong code looks wrong.
Reading the code for obvious flaws is another way to make the code new by changing perspectives. This can have a good effect, since a change is as good as a rest.
The best and most reliable way to break your writers' block is to change partners. If neither you nor your pair programming partner is able to easily think of the next test to write, it is possible that you are done or that you have both gone stale. Changing partners will give you a whole new set of eyes and a whole new perspective on the readability of the code.
There is a missing element here which will be considered elsewhere -- "reduce your scope".