Not all necessarily "Scrum Specific" but keep in mind Scrum is a framework, and not a substitute for good Project Management practice :-)
I'd suggest:
Features added/demo'ed since last report - Very compelling to tell stakeholders what is already part of the product!
Defects that "slip" out of the iteration - this is the rate of defects that get added to the system. Ideally, it will be zero, indicating that both testing is happening before existing the iteration boundary and any tech debt that either the product owner has accepted as part of the iteration or has crept into the system as tech debt. Hard to measure this and "fake it"
Team's definition of done - report any changes the team makes as they progress the sprint. This is less "number-y" but is a good indication that a Scrum team is learning as they develop the product and are adjusting their way of working. Less "intrusive" than asking for a report of "what went well/what needs to change"
Burndown against backlog for the release - Picture a stacked area chart (in Excel) the number of points the release starts with might be 100, and each sprint 10 (for example) get closed and maybe 5 get added. I like about 5-6 stacked areas : Accepted (closed), Removed (closed), Original (open), New-missed (open), New-from customers (open). Show this each iteration and you'll rapidly see how the team is doing.
Risk board - always always always report on the top risks the team identifies. I like showing the Top 5 risks in a quadrant view - http://yfrog.com/g0qy8p
Projected ship date - Prep the stakeholders that the first 2-3 iterations are going to have wide swings until the team settles on a velocity.
hth