I also cordially suggest that "Scrum is a guideline, not a religion." It lays out a practical vision and blueprint for short-iterative project execution which is to be executed as a series of "Sprints." The objective is both to help determine (and, limit) what the team should set out to do in each iteration, and to quickly bring the product itself back to a "theoretically, at least, deliverable" state. During the sprint, parts will be carefully laid out across the garage floor, but at its conclusion you should be able to once again start the engine and drive. The team should learn how to parse off the right amount of work, then to achieve it with high quality without "bustin' themselves," and then how to repeat that again and again. At the end of each cycle, the product [more or less] "works," and the team can see it growing according to their plan.
Now, in every case that I've yet worked with, what the team(s) actually did, never was actually "pure, by-the-book methodology," but [I say ...] who cares. They all seemed to benefit positively from trying to apply the books' core principles to the dispatching, execution, and quality-assurance of their work. These principles really do work in a majority of cases, even if a team does not follow them exactly.