These 2 talks explained practical experiences with a project using Scrum.

Tip for (at least one of) the speakers: don't read your text from a piece of paper.

Having had some Scrum experiences myself, I'll stick to the things that were worthwhile writing down here:

• Achievement is not the same as activity (personally I prefer "doing your best is not the same as having success", but I guess that's a matter of personal flavor
• Sprint backlog with 4 cols: todo, in progress, funct test, done (we didn't use the functional test stage)
• use a burndown graph to maeasure progress
• determine your velocity to  estimate/ follow progress
• organize sprint retrospective meeting (no more than 90 min)
• do the scrum meeting standing (some people aren't gonna like this one ;-)
• Play planning poker to estimate, using the technique of story points and only fibonacci numbers (are a perhaps a variation?)
• If you can't estimate (SPIKE requirements): organize a poc to be able to estimate afterwards
• try to automate functional tests (Selenium framework for web apps - I'm definitily going to try this)
• non-dedicated resources decreases efficiency (I've this happening too often...)
• scrum master does the fire fighting, especially in the first sprints (well, what should I say - if it's only a few sprints, that's GOOD)
• Putthe team together (I agree, this really works)
• SCRUM does not solve your problems, it only makes them visible (but you must be willing to see)
• Scrum doesn't mean you don't document, it means documenting in a smart way
• Empower the team and take a distance (beware: the team must be ready for this)