I finally finished Mike Cohn's book, Agile Estimating and Planning.  It has been on my reading list for quite a while, but I just finished it last week.  In short I found it to be very helpful.  To understand how, I'll note some of my background in Scrum.

When I first read Agile Project Management with ScrumI was very intrigued.  I found that Scrum melded well with the mostly engineering-focused XP practices that I had previously adopted.

I then took the Certified ScrumMaster course, and I was even more impressed.  The problem, though, was that the course is only 3 days.  3 Days just isn't enough time to consider anyone a "master" of scrum.  It takes years of attempts, trying different things, failing, and overcoming those failures to eventually become  a "master."  But that's a topic for another day.  My point is, that there was still a lot for me to learn.

I gave some internal training on scrum and noticed that there were a lot of questions that I didn't have the answer to (how absurd of me to think that I had all the answers!).  Some of them were practical questions... like what's the best way to determine your iteration size, or how to effectively do release planning.  I knew the concepts, and I knew their purpose, but I struggled with the actual implementation.

After reading Agile Estimating and Planning, I am much more prepared to answer those questions (and implement them in my daily work).  Mike talks in depth about why fixed iteration length is important (which is a question that has come up twice in my project).  He also outlines how to effectively plan an iteration, and what to do if you have too much work planned. 

A co-worker called me once and asked me, "What happens if you partially implement a story during a sprint?" -- the answer came directly out of this book.  The short answer is that you can either move the entire story over to the next iteration (because it isn't done) or you can decide to split the story in two (however this method doesn't work if you implemented functionality but didn't test, for example).

While reading this book I have cracked it open three or four more times to refer to specific advice, which is why I think so highly of this book.  Once you understand the Scrum principles and have a healthy bank of questions about its implementation, turn to this book to get some concrete answers.  Not all of the advice is solid gold, mind you... but I think it's an excellent resource for a team that is new to Scrum.