These small tasks can be finished by one developer. There is usually no need for handovers or reassigning. User stories in turn need to fit within one sprint (<= 4 weeks). When they are done, there should be no reason why you need to come back to it trying to figure out who did what. This, of course, assumes you have a Defintion of Done and a test suite that make sure tasks are really done.

Scrum is not an excuse to not document any issues you came across during development. It is a common misconception that Scrum teams don't document what they are doing. The idea is to get rid of all the handover (sign-off) documents and the ones that no-one ever reads. That doesn't mean the team can't produce any documentation. I personally prefer keeping things in a project wiki. It's easy to access and share.

Status report. In my opinion that is one of the big advantages of a visual task board consisting of the user stories and tasks for the current sprint plus a burndown chart Have a look at this http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf. It's pretty much exactly the task board we use. By having the board an the wall where the team sits the status report for the current sprint is right in front of them (and everyone else who walks around the office). No need to open a tool and run report. It's right there. All the time. You may call it a continuous status report. Again, this assumes co-location of the team. For a status of the current release we just use a burndown chart of the sprints within the release created with Excell. I understand that many companies will need a more sophisticated way of doing this. Or at least they think they do.

I am always open for a bit of a discussion. So don't feel bad about it. If everyone just nods there is no discussion and no improvement. Looking forward to your response.