The "take a break" thing is crucial, IMO. I know it's only an analogy, but think about it... in "real life" you can't sprint, sprint, sprint, sprint, sprint, sprint, ... forever and ever. You have to stop and take a breather every now and then.<p>Personally I don't even like the term "sprint" in Agile methodologies and try not to use it. I prefer "iteration" anyway, because it doesn't carry the same connotation of absolute, balls-out, do-or-die effort, which can actually be harmful.<p>But regardless of what you call the time-boxed increments, I prefer to never have more than three in a row that are done in full-on "sprint" style. Ideally, every 4th iteration or so, would be a "light" iteration that A. lets everyone catch their breathe, and B. gives some time for taking care of the "loose ends" that otherwise fall through the cracks. Stop (or at least slow down), look at the big picture, look at paying down technical debt, and don't work yourself into an early grave. If you're a team leader, take one day off during the iteration and take the whole team out to see a movie or something.
I think the sprinting analogy is a good one. I think the biggest piece to take into account is that the harder you sprint, the longer you need to rest. I think just like a good coach, a PM needs to play with the sprint/rest/slow cycles until they get to a cadence that pushes, but does not hurt the team. Also, as with running, as the team adapts, the cadence can and should change to better suit their progress.