I am very proud to have been one of the subjects for Christoph Johann Szczecina's Masters thesis entitled "Communication Technology and Structures in Scrum Driven Projects" which has now been published. Available at http://www.szczecina.org/resources the study looks at the usage of communication and collaborative software in Scrum-driven software development teams. Christoph has a good writing style making his thesis easy to read, so I recommend that you go and have a peruse. A certain other Brighton-based company is also featured, but I won't give away their name unless they want to do it themselves.
Christoph is from the Norwegian University of Science and Technology based in Trondheim. He found me through my various Scrum/Agile photos on Flickr and some blog posts here. Another great example of how the interwebs has brought people closer together.
I agree with the conclusions of the study in that the best Scrum software aids area currently source control, IM, Skype, and Outlook Calendar; also that the usage requirements are dependent on team size and physical (co)location; and that not quite enough documentation and planning is created.
My personal comment to Scrum teams would be that if anything appears to be missing from your output (e.g. doing enough testing, writing enough documentation, publicising your work widely enough) then adapt the process so that it is a natural outcome of your work. In this way it will not feel like a chore. E.g. we found that proper testing was being left until the end of the sprint, risking overrun if something bad was discovered. So, we changed the process so that a Developer marks a story with a square to indicate 'finished coding and written an automated test' in order for another Developer to check that it does indeed work, at which point it can be marked as 'done' and the affect the burndown chart. The results were:
testing was checked as soon as possible because otherwise the burndown chart looked bad mistakes were caught early and could be remedied without adversely affecting the sprint knowledge of new features was shared between Devs tests were written better as Devs knew that one of their peers would be running it testing became a natural part of the process and not a chore to be performed in retrospect