Scrum is an Empirical Process (as opposed to a Defined Process) that uses two Inspect And Adapt cycles to manage product development. Scrum is great for software projects. Scrum software teams produce working software every 30 days. However, Scrum can also be used for non-software projects.
Ken Schwaber and Mike Beedle, two of the creators of Scrum, have written the Scrum Book, a powerful introduction to the process.
<hr>
To learn more about Scrum, take a look at the Scrum Overview, or visit some of these Scrum links:
www.controlchaos.com 
- Advanced Development Methods, Inc., the home of Scrum
implementingscrum.com - Comic Strips and Blog Entries from a Certified Scrum Trainer (Michael Vizdos)
<hr>
People who are certified in Scrum are called Certified Scrum Masters. The Scrum Master Certification program is the best way to learn Scrum.
<hr>
Scrum Is Not An Acronym: please use Scrum or Scrum<b></b>Process instead of SCRUM. (Even if Jeff Sutherland does it on his SCRUM log)
<hr>
The starting point on Wiki for Scrum used to be Scrum Methodology. The authors of Scrum call it the Scrum Development Process. The author(s) of this page prefer the word process as well, because it avoids the Method Or Methodology debate.
<hr>
Content moved from Scrum Methodology:
One of many Agile Processes, Scrum focuses on Project Management without dictating Software Development practices, although it has been very successfully used in conjunction with Extreme Programming (see www.xbreed.net ).
The Scrum Process is a formal RAD method especially suitable for quickly developing enhancements to an existing system which is experiencing frequent shifts in requirements. Its name derives from the "Scrum" (yes, from Rugby), which are <30 day "all in" development periods during which requirements DO NOT CHANGE and managers (by definition not part of the Scrum team) act only to remove obstacles. (called "Scrum Sprints") It was developed and is taught by a consultant house. See the home page at www.controlchaos.com . -- Mark Swanson
<hr>
All right, I'm going to give into the temptation to ask this here instead of going immediately to the tome, but I'm lazy and didn't want to get off track (just read a pattern about that somewhere here...)
Alexander says that interesting requirements emerge from within the system itself as it takes shape, which is one explanation of why purely requirements-driven methods falter. This realization came to him during his work on Ba Rt? (<i>as in Bay Area Rapid Transit?</i>), and was one of the transforming ideas that took him from a misfits philosophy to a pattern philosophy.
I'm not blaming Scrum as being one way or the other, but want to ask a clarifying question that may be open-ended:
During the one-month interval, does Scrum shut off only changes in external requirements, or does it ignore the requirements that emerge from within the system itself, too?
Whatever the answer, what is the rationale for treating these two cases as is done?
I've heard a lot about Scrum (the best kind of compliments - "oh, that's just my idea X by another name" - the sure sign of a good thing) but the above characterization, if true, worried me a bit.
-- Jim Coplien
Great question, Jim. Scrum shuts off only changes to external requirements but **strongly** encourages resolution of the "generated requirements" for the scheduled functionality.
Therefore, it encourages the resolution of forces through customer feedback for a given functionality to the nth degree - as much as the time-box allows.
-- Mike Beedle
<hr>
One reason this happens is explained in this example: A Product Backlog item X was "guesstimated" at, say, 40 hours, and the team holds that Sprint Backlog items should be <16 hours. So during Sprint Planning, Product Backlog item X will be scinded into 6 separate Sprint Backlog items X1 to X6. And, while discussing this, a new item Y is discovered (that should have been, but was not, on the Product Backlog).
Eschewing Big Design Up Front, Scrum acknowledges that it's more efficient to allow such items to emerge during Sprint Planning. Now, if item Y is estimated at 300 hours, and it's essential to the Sprint Goal, I'd guess the Scrum Master would call for Scrum Sprint Abnormal Termination. On the other hand, if it's 300 hours and not essential, I believe Y could be pitched back onto the Product Backlog.
-- Deb Hartmann July 7, 2003
<hr>
I think this is one of the great strengths of Scrum, specifically of the Scrum Sprint. It allows you to ignore the chaos from outside ("changes in external requirements") and focus on the chaos from inside ("requirements that emerge from within the system itself").
The above description of Scrum is a bit simplistic. Actually, Scrum is a collection of many practices (not just the one mentioned above) that seem to fit well together. A Pattern Language maybe?
<hr>
Rugby players <i>scrum</i> when they surround the ball and move it forward together. The word has been borrowed to describe a collective form of software development that is claimed to be distinctly different from traditional processes including waterfall, spiral and iterative development.
<hr>
A scrum is a set play where the two teams forwards pack down and attempt to shove each other off the ball. Surround the ball to move it forward is <i>mauling</i> - generally one player takes the ball, burrows through or around a few paces, turns and sets so that his colleages can bind around him, then another player takes the ball and so on. Mauls generally end in one of three ways - the ball goes to ground, turning it into a ruck, the ball is passed out to the backs who run it (or not), or by some kind of infringement of the rule (offside, not joining the maul properly, etc, etc, etc).
Quite how this maps to software development, I'm not quite sure.
<hr>
In Canadian politics a <i>scrum</i> is when a senior minister leaves the House of Commons and is surrounded in the hallway by the news media shoving their microphones forward and shouting out their questions. It is quite chaotic and unlike the structure Q&A found in a press conference.
There certainly is a scrum-like style of software development that is used successfully in developing a lot of open-source software like FreeBSD, Linux, the Apache webserver, and so on (see The Cathedral And The Bazaar). It often ends up with one or a few people dominating the process and giving structure to the process but this structure is self-organizing out of chaos, not imposed from above.
I would have to say that this is definitely quite unlike the managed processes characterized by the waterfall, spiral and iterative processes.
I see some echoes of Extreme Programming here. My understanding is that Extreme Programming was not a <i>designed</i> methodology but one that emerged from the personal experiences of a few people applying some techniques which were known to work. I know that I have been using some of the techniques of Extreme Programming for a number of years such as The Source Code Is The Design and You Arent Gonna Need It in developing business applications using a 4GL RDBMS environment called Progress. -- Michael Dillon (In fact, some of XP was derived from Scrum.)
<hr>
This method does appear to some value (daily 15-minute meetings, adaptable, etc) on smaller, enhancement-type projects, but clearly would not work on multimillion dollar, highly complex, cross-functional, mission-critical custom development projects. These kinds of projects require the process-centric controls provided as part of PMI's PMBOK, IEEE's SWBOK, etc. -- Rick Woods, MBA, PMP, CCP
"Multimillion dollar, highly complex, cross-functional, mission-critical custom development projects." Which are like, 1% of all development projects? -- Paul Eipper
Having worked on a Scrum Process project which certainly was multi-million dollar, more complex than the engineering team on staff could handle, and was positively cross-functional, <i>and with great success,</i> I call into question Mr. Woods' (MBA, PMP, CCP, and whatever other credentials he feels like waving around) thesis. I would have preferred if we used Extreme Programming instead, but I'll take what I can get, and Scrum has definitely vindicated itself. Without a precise definition of what <i>each</i> of these terms mean, in full isolation of each other, his statement is nothing but a troll. This is particularly true for that omnivacuous term, <i>Mission Critical.</i> --Samuel A. Falvo II
I used Extreme Programming (the real thing, not lip service) on a multimillion dollar, highly complex, cross-functional, mission-critical custom development project to rewrite, improve and integrate the entire police service and courts systems with one country to another. We delivered far more functionality than originally required and several months earlier than the deadline. It was a resounding success and the specs changed more times than you could count. I doubt using Scrum instead Extreme Programming would have killed the project, I bet it would be just as good. We of course didn't tell the client about pair programming or he would've flipped.
<hr>
<hr>
Contributors (of this and incorporated pages): Mike Beedle, Deb Hartmann, Michael Ivey
<hr>
See original on c2.com