Talk:Scrum (software development)

Scrum methodology is mostly used for pure service oriented ogranizations that works very closely with clients. Daily validations with the client is practically not possible. —Preceding unsigned comment added by 125.16.30.178 (talk) 12:47, 22 April 2010 (UTC)

OK, I started cleaning up the Scrum page. It is starting to make more sense, but definitely needs additional work. rnd 12:38 AM 7/01/07

Correct me if I'm wrong, but I believe the product owner is not a 'pig'. While invited to the daily scrum meetings, the product owner cannot speak, as the sprint has started and no changes are allowed. (I'm anonymous, but a ceritfied scrum master for over a year). —Preceding unsigned comment added by 208.102.57.190 (talk) 19:50, 12 April 2008 (UTC)

If the product owner is not committed, the likelihood of the team succeeding in their sprint diminishes rapidly. The team needs constant access to the customer to clarify stories and ensure that expectations are met with minimal rework. This also reinforces the customer's commitment to the success of the project/release/sprint as they have skin in the game by committing a resource to the Scrum team (the product owner). 205.142.227.100 (talk) 17:20, 1 July 2009 (UTC) John Scumniotales 10:19 AM 07/01/09

Confusing timeline

Second paragraph: Scrum was first applied in 1993 at Easel .... These principles later became some of the basics of Scrum. ... These projects were observed and the results were published ... (January-February 1986)

Something in that paragraph needs a change to clarify the timeline.

Object Oriented

I don't think Scrum specifies an object oriented approach. In fact, it leaves it up to the developers to decide the approach that best works for them. It's often used with XP, with Test Driven Development, which would lend itself to a highly modular (not necessarily OO) design, but I don't think it should be listed as a characteristic of Scrum.

Will remove if no one objects. Mutant 21:20, 21 September 2006 (UTC)

• Objection raised. Object orientated in this context refers to the processes described within the methodology. Each iterative item can be described as an object and thus doesn't in any way refer to the IT term. Instead the terms draws you to the implication which, in my understanding, means a semi-independent item within a whole. Maxwellvz 14:11, 25 September 2006 (UTC)

I haven't heard that term used in this context before. It also seems to me to be rather ambiguous. If that is the term in common use, then fair enough, but I think some sort of explanation (along the lines of what you've already given) is in order. Mutant 21:39, 26 September 2006 (UTC)

Ken Schwaber's SCRUM Development Process describes how an object orientated approach can be used with SCRUM. Maxwellvz

• Object orientated approach is taught in respect to System Engineering in many universities, including my 210 course at the University of Aucklands Faculty of Science. —Preceding unsigned comment added by 125.238.247.83 (talk) 04:40, 2 June 2009 (UTC)

Article misses the point

This article, especially the bizarre diagrams, completely miss the point that Scrum is a simple framework. It's really just three roles (Product Owner, ScrumMaster, Team), four meetings (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), fixed (typically 30 day) iterations, and demonstrable increments every iteration (Sprint).

I suggest we overhaul this entire article, deleting most of it and bringing it up to date with the simple "Scrum Rules" appendix in Ken Schwaber's gray book.

--mj (ScrumMaster, Scrum Practitioner, and Scrum Trainer) Michael98101 17:30, 10 June 2007 (UTC)

Very much in agreement. This needs a total overhaul. The diagrams completely confuse the issue. - rnd (CSM, CSP, Agile Consultant)

Totally agreed. 201.9.41.169 12:57, 24 June 2007 (UTC)

I agree. This article is confusing and incomplete. It completely fails to explain agile principles and Scrum as a Framework. 81.171.156.97 14:42, 26 June 2007 (UTC)

Why was the content of this article removed? Gmazeroff 19:21, 10 June 2007 (UTC) gmazeroff

Strongly agree. I barely recognize the described process as Scrum. This article used to be clear and concise, but I think it was polluted during the merge of the Scrum development and business process articles. Runtime 08:16, 29 June 2007 (UTC)

Strongly agree. Perhaps I'm simply procrastinating here, but the part about standing for a scrum, not being able to speak and punishments for being late? Completely unfamiliar territory than I've ever experienced. Scottdavies (talk) 13:07, 30 April 2008 (UTC)

Agree. IME, over-complication of the process is encouraged by consultants and "ScrumMasters" seeking to increase their value. It's not inherent to it. Also, listing your company's interpretation of the process is original research. This should and must be avoided, lest this article become a focus for defining rather than documenting the process. Let's get eliding. Rogerborg (talk) 10:12, 9 November 2009 (UTC)

Talk:Scrum (management)

Very Badly Needed Criticism Section

I've had profoundly negative experiences with SCRUM. Many other developers and contractors I have worked with and talked with feel that SCRUM is a scam. Can we have a criticism section that addresses the brokenness of this methodology? Can somebody iterate a criticism for me? I'm too lazy to plan it.

All right. I'll give in. Here's some fatal flaws of SCRUM:

1. SCRUM is an empirical process, which means that the measure of success is the end result - not all the stuff that goes into it. If all that matters is the end results, then the process shouldn't matter. So SCRUM shouldn't matter. A contradiction in terms.

2. SCRUM doesn't just say that requirements definition is hard, SCRUM says it shouldn't even be attempted. SCRUM views requirement changes as inevitable and expected. Everybody seems to agree that customers often don't know what they need, but to say that requirements definition is futile is equivalent to saying that not only are customers incapable of articulating their needs, developers are incapable of meeting them. Do you want to work under a methodology that believes you cannot successfully communicate with your customer?

3. Allowing customers to "change their minds" means that software development outfits are expected to incur the cost of the unlimited wants of consumers. If customers cannot articulate their needs, they probably cannot distinguish between a "need" and a "want", but will expect you to foot the bill just the same. Unlimited wants combined with limited means is the classic "economizing problem" - and the resource that gets used up first is "time" --- how much "time" will it take", how much "time" do we have, how much "time" until we demo.

4. And most importantly, SCRUM is micromanagement. It does not respect programmers as professionals - it treats them like assembly line workers. —Preceding unsigned comment added by 96.227.250.101 (talk) 04:33, 3 February 2010 (UTC)

—Preceding unsigned comment added by 144.26.117.1 (talk) 22:35, 8 December 2009 (UTC)

Living backlog

What is a living backlog? Is it just a master list of things to do which is updated regularily. If yes, what is special about this? Hasn't this been used all the time? --Hirzel 21:49 10 Jul 2003 (UTC)

It's nothing revolutionary, no. There are two backlogs, for the Sprint and Product. The Sprint backlog is the todo list of the current monthly iteration, and the Product backlog a list of everything anyone has requested.

Developers should update the Sprint backlog daily, with an estimate of how much work is remaining on each of their tasks. This is maybe what is meant by "living" - you always have an idea how much work is left to do, and as the backlog is essential to the scrum process, you can be sure it's going to be up to date.

Anyone (really, anyone) can add requests to the Product backlog. As such, it is the one place that captures all ideas about the product/project. Even stuff that might not be possible now - "I want a man on Mars!" can be added. Once a month, the business owner (product owner in scrum parlance) puts the list in order or priority to the business. Again, the fact that anyone can add to it, at any time and anyone can see it and the current priorities at any time make it a key document, and the focus of a lot of attention.

If you have a short term todo list (sprint backlog) and a long term todo list (product backlog), and review it frequently/daily with everyone involved in the project and are constantly keeping it up to date, and use these 2 documents as the central point to capture ALL requests, then you more or less have a backlog. Murray 20 Jan 2004

Removed a chunk of unsubstantiated, unencyclopaedic content

The following chunk was in the article, unreferenced, and with a very "how-to" feel to it. I've put it here in case someone can pull something useful out of it. -Kieran 10:29, 25 October 2005 (UTC)

Begin chunk:

---

In the recent times most of the managers have recognized the value of the people centric management practices against the process centric practices. In an environment of the constantly changing requirements & stakeholders, it is not logical to control the project on the process level. In simple terms "a rigid process cannot help in adopting to the customer's needs".

For the Software projects its is very meaningful to combine the SCRUM with Extreme Programming and Test-driven development. This helps to have a systematic and disciplined practices with respect to the management, code, and testing practices.

---

End chunk

Removed link to the word "deliver": why?

I removed the link to the word deliver because it links to page that defines the word in the traditional sense (e.g. trucks and warehouses) while the word is used on this page in the software sense of "completion". It didn't seem helpful to me to link from here to that page. Dave Menconi

Comment on simplified scrum description

Under "simplified Scrum" it says

   * Schedule a demo of the software with the customer/client a month from now

This sounds a lot like the horrible practice of picking dates out of thin air and then whipping the team to meet the date (I could tell you such stories...). It's not clear from this discussion how the scrum version would differ.

On the other hand, this is just an example of a way to implement a lite version of scrum and it might complicate this overmuch to explain how you pick the date.

Still if *I* had this reaction maybe others would too; if so Scrum would be painted with a negative reaction because of an example.

Dave Menconi

I think the main difference is that you plan a demo, but then the team decides on what the demo will include. In that way, managers or leaders aren't pushing irrational timelines on the team, as the team decides what can be done in that timeline. I think you're right in thinking that people will cringe at this. Regarding this section, I think we need to cite something directly here, I'm pretty sure that some of the official material on Scrum has examples of how Scrum can be "stealthily" applied to an existing process without crediting it to "one wiki writer"Endasil 15:59, 7 July 2007 (UTC)

Adaptive Project Management Comments

The paragraph at the top of this section is not crystal clear. It has a lot of good information but it's like a bunch of ideas are all jostling to be presented.

The rest of the section was good, imho

Dave Menconi

Please say more about the significance of 1 month

In two places it's mentioned that things are done monthly (here in the dicussion when explaining about backlogs and in the simplified scrum). Are sprints usually month long? Or is monthly just an example of a "short period of time".

This is kind of significant because having monthly deliverables (if indeed that's one of the features) would be one of the most obvious and significant difference between scrum and other more traditional software development methodologies (the other big one, I think, is the daily meeting). Many of the features look, at first glance the same -- for example, I've always done software iteratively(in 3-18 month iterations) and we always have a list of tasks (controlled by the leader) and so on -- but take on a different tone when the time scale of things is taken into account.

Stephiee01 19:42, 16 August 2006 (UTC) Sprints/interations ideally should not be more that 1 month in duration without reconvening with stakeholders and product sponsors to review the sprint accomplishments in the event that changes should be made, or priorities have changed. With longer iterations, teams typically loose focus of their sprint deliverables, and the "pressure" to get the job done is eased quite a bit. In other instances, there is the concept of mini-sprints, which are shorter interations, usually a week to 2 weeks in duration. Also, typical 30 sprints can be broken down into "mini sprints" with weekly/semi goals to reach the end of sprint goals identified at during sprint planning.

Please keep in mind that following scrum to the letter does not determine success. Rather, scrum is a practice that should be altered to fit your best business practices and own processes and procedures. Scrum should be used as a framework and adapted within current successful practices. As more project are developed using the scrum methodology, you will begin to see what aspect(s) fit and which ones don't, and you can begin to build around the key principles of scrum.

The following discussion is an archived debate of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the debate was merge.--Jorfer 21:40, 10 June 2007 (UTC)

Merge with Scrum (development)

Is there a difference between Scrum Development and Scrum Management. It seems that these two articles should be merged.

• I agree. There is a lot of overlap between these two entries. Winterstein 10:29, 19 July 2006 (UTC)
• Agree. A lot of info to merge together though - possibly merge the pertinent bits of (management) into (development) and then move the latter into the former - (development) certainly seems more well set out. --Firien § 12:16, 10 August 2006 (UTC)
• I too Agree. Scrum Management and Scrum Development are processes of the Scrum Methodology. Its nearly impossible to peform one process without the other. They work hand-in-hand to the overarching Methodology...Scrum. Stephiee01 19:22, 16 August 2006 (UTC)
• I do not agree with this proposal. Although Scrum is very much driven by the development team, the management of Scrum is a global perspective of the project requirements and the iterative components. Applying the two different categories to Scrum would help define these perspectives. I do think though that the definition and goals for management and development need to be more clearly defined. Maxwellvz 13:29, 25 September 2006 (UTC)
• Agree. Scrum messaging is unclear as it is, no need to confuse it even further.
• I disagree. Scrum development is a different process than project management. The different PM tasks should be compared in the project managemnt section. If someone does not understand the processes, then they need to get some real experience. Can you say Beck?
• I agree: Scrum is described by Ken Schwaber (in 'Agile Software Development with Scrum') as something wrapping developmental practices which preexist or which are designed specifically for the project. It does not focus on the developmental practices at all - only mentions which practices could be good to use when you set yourself the goal to deliver something working every month. On the other hand, the management aspects are taking gantt charts or similar and reformat them into a backlog ('cutting through complexity'). Scrum is the glue between development and management, in my eyes, and should not be split into the management and the development aspect. That, indeed, would revert the biggest benefit of Scrum.84.75.128.192
• I agree. Scrum is an approach to software development, so it is product-oriented. It is not meant to be a project management methodology. Eric
• I agree. Concerns about keeping the two Scrum sections in Wikipedia. It is a method of managing a project and details can be given by updating this area. Perhaps the sections when merged should just be called SCRUM and not Scrum (Development).
• I don't agree. Agile Scrum can be used for any project with deliverables, and it should be separate. Jcposey 01:54, 17 February 2007 (UTC)
• What other non-software development kinds of projects use SCRUB? I can't see a construction or oil-drilling project use SCRUB, so I wonder what other domains do? [Michael]71.202.149.150 06:49, 26 February 2007 (UTC)
  • I'm using it right now in a software implementation - it's an entirely different field. Dibbler5 11:30, 26 March 2007 (UTC)
• I think both articles should be merged, but under the title of Scrum (methodology), as opposed to either Scrum (development) or Scrum (management). There is a certain amount that is common to both methods, and this should be highlighted. Other project management methodologies have begun life in the software development world and moved to other fields. (I'm particularly thinking of PRINCE2 here.) Dibbler5 11:30, 26 March 2007 (UTC)
• I do not agree. This article gives a "light" overview of Scrum which is just right IMO. I suspect the majority of people are after this level of detail when searching in Wikipedia. They have the bigger article if they need more info on the history. From another viewpoint, I am a software engineer in the fast-moving world of web development who wishes to use Scrum and this article gives me pretty much all I need to get started. This reflects a general shift towards simplification in the software world eg. Redhat have recently reduced their support service agreement from 9 pages to just 1 page. A lightweight methodology like Scrum is best suited to a lightweight article. ImranC 14:55, 4 April 2007 (UTC)
• Do not merge. This page is a good liteweight ;) description of the principles while Scrum (development) has become very specific to software projects. That's good. Someone wishing further detail on software Scrum can go there. In fact, I note this page is missing a disambiguation link to it, so I think I'll add one. So there. David Spalding (☎ ✉ ✍) 19:59, 25 April 2007 (UTC)
• strongly agree- There are no 2 distinct Scrum methods. It can be applied to development or management, but the METHOD IS THE SAME!! Having 2 articles only confuse it. Why not merging and leaving a section explaining its distinct uses? Leaving as 2 articles has no sense!!! Also, note that the 2 articles are talking the same thing. You people are talking in leaving 2 articles talking about the same thing!!! SSPecter ^talk ♠ _{23:05, 22 May 2007 (UTC)}.

Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Advantages and Disadvantages

This article practically tells us the advantages of SCRUM. Wouldn't it be nice to have some disadvantages of SCRUM listed or at least some negative opinions of SCRUM? SCRUM can't be all good right? — Preceding unsigned comment added by 12.160.172.2 (talk) 20:30, January 24, 2007 (UTC)

This article is completely biased. Nothing against the methodology is given. —Preceding unsigned comment added by 61.88.131.94 (talk) 01:11, 29 September 2008 (UTC)

Agree - a lot of us in the software industry avoid "Agile" development, precisely because it comes with a lot of overhead that could be spent as productive work hours, provided you have competent tech-management. You can "timebox" something for 15 minutes if you like, but in practice, in many cases, these meetings run considerably longer, and long meetings can negatively impact employee focus and morale. Of course, you can always throw back "then you're doing it wrong", to a criticism like this, but I still think the article should reflect criticisms that are made.

It would be nice if you guys & gals started signing your comments. Until then, we should take their absence as a sign that you yourselves (subconsciously) consider the comments worthless, whatever the comments are. -- Iterator12n ^Talk 00:37, 2 December 2008 (UTC)

Having a post marked with an IP is no more anonymous than using a random login. Sign with your real name if you want to complain about us anonymous commenters. Anyway. Maybe we're doing it wrong, but from my perspective Scrum is nothing more than new-agey development hoodoo in which we seemingly spend more time in meetings at butt-ugly-thirty in the morning talking about our feelings and singing Kumbaya. The only organization that makes money off the implementation of such methodologies are the consultants that teach the classes, and the authors that write the books. (Same can be said of 6S, but that's another story.) —Preceding unsigned comment added by 216.207.242.34 (talk) 16:35, 11 March 2009 (UTC)

Inaccurate Link - please correct

The link title "Agile Values" links to the Agile Alliance. These are two different things, and should probably both be represented:

Agile Values and Principles: www.agilemanifesto.org Agile Alliance: www.agilealliance.org

thanks, Deborah Hartmann deborah.hartmann.net

NPOV and Cleanup tags

The article uses first-person pronouns in a few points, and as such doesn't have the proper tone. Additionally, the feeling I got from reading the article is that Scrum is the best methodology for developing software, with no flaws. Unless it really is the holy grail, there are probably are some flaws, so I've added the NPOV tag. Obonicus 20:55, 3 July 2007 (UTC)

I would agree. Flaws I can think of include: (1) potentially messy code due to unplanned features layered over prior code that wasn't flexible enough to allow elegant extension. And messy code can lead to more bugs, etc. (2) Higher initial number of bugs due to an insufficient time frame for testing and/or inadequate specifications from the user.

This is of course not to say that the advantages of Scrum don't outweigh these potential disadvantages (I think Scrum or Agile development in general is a good idea for many projects). Just my two cents. -pgentry 198.81.125.18 16:35, 2 August 2007 (UTC)

I believe that Scrum/Agile is the way to go for for experimental projects with less clearly defined requirements and technology while more traditional methods work best when the domain is well understood and predictable. -Jesse

I've wrote down a few known (or alleged) disadvantages, so that there are now less reason for NPOV tag. -Humu —Preceding unsigned comment added by Humu (talk • contribs) 12:37, August 27, 2007 (UTC)

Scrum Background

I think some of the part about the OOPSLA paper might be incorrect. I checked the ACM Digital library, they have the proceedings for the OOPSLA conference, and there is no _paper_ listed by Jeff and Ken. There is a mention of Jeff being on a _panel_ discussion. Also thats for OOPSLA '95 not '96. Also the scrumalliance.org web page that has Jeff's profile says that he worked with Ken to formalize scrum. It does not say he presented a paper there.

---

Ken presented the paper at the OOPSLA'95 Business Object and Design Workshop. Workshop summaries are published in the OOPSLA addendum. The full text of the article was published in the proceedings from the 1995 workshop in a 1997 book by Springer:

K. Schwaber, "Scrum Development Process," in OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, D. Patel, C. Casanave, J. Miller, and G. Hollowell, Eds. London: Springer, 1997. —Preceding unsigned comment added by Jeffsutherland (talk • contribs) 20:32, 7 October 2007 (UTC)

---

The very first paragraph states:

Despite the fact that "Scrum" is not an acronym, some companies implementing the process have been known to adhere to an all capital letter expression of the word, i.e. SCRUM. This may be due to one of Ken Schwaber's early papers capitalizing SCRUM in the title.[1]

although the paper referenced here [1] is not that early paper (it is a book, which doesn't appear to capitalise Scrum -- except in some editorial bumph on the back cover).

The quote is rather a strange thing to put at the top of the page on Scrum (development), but if it does go in (and, in any case) it should have a link to the Schwaber paper/article which is mentioned immediately prior to this note. By the way, the reference should capitalise the word Scrum (viz. SCRUM). Zteve (talk) 14:52, 18 May 2009 (UTC)

"fundamentally empirical challenges"

A key principle of Scrum is its recognition that fundamentally empirical challenges cannot be addressed successfully in a traditional predictive or planned manner.

The statement is problematic in a few ways. It's an unsourced assertion, and it's possibly an unverifiable assertion.

What is a "fundamentally empirical challenge?" Are there other kinds of empirical challenges for which a "traditional predictive or planned manner" is supposed to be suitable after all? Or are all development efforts assumed to be fundamentally empirical challenges? If so, what are the sources for such an assertion (that aren't just restatements of the assertion)?

Is there really a black-and-white distinction between challenges that can be approached with a Scrum method and challenges that cannot? The use of "cannot" in the quoted statement is a very strong claim. Saying a method works well for particular classes of problems is still a strong statement, but easier to justify. Saying one method works better than other methods for certain classes of problems is a stronger statement, and needs verification in comparative studies. Saying that one method works and other widely used methods "cannot" work is highly questionable.

--Jim Becker 22:48, 12 October 2007 (UTC)

Bang to rights, my friend. (I appreciate this isn't the most helpful addition, but really, the whole article could do with the help of a gallon of napalm, a box of matches, and a couple of oxygen cylinders. When I tell a customer he's a chicken (or a pig), I'll know it's time to go and listen out for that tree falling in the woods.) —Preceding unsigned comment added by 193.129.10.246 (talk) 10:09, 21 November 2007 (UTC)

Scrum and the rugby metaphore

I rephrased the section claiming that Takeuchi and Nonaka compared the high-performing teams to the scrum formation. It is wrong! Here is what they say in "The New New Product Development Game":

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method—as in rugby, the ball gets passed within the team as it moves as a unit up the field.

no it doesn't. it's kick to touch, lineout, knock on, scrum, unknown infringement, penalty, 3 points. repeated ad nauseum for 80 minutes

First of all: They don't mention scrum and you can't pass a ball within scrum, its OK within a team. Then, there are plenty of ways to move up a team; rucks, mauls, open play, chase a kick. Scrum is mentionned in the article, but seldom as a descriptive term. "Rugby approach" is mentionned a lot more.

I really like Scrum as name for the development framework, but saying it reminds of a rugby scrum is really weak. Comparing it to a rugby team is so much better, especially if you know the game.

--Eirik.midttun (talk) 21:42, 12 December 2007 (UTC)

Wait...you can't mention a joke about a pig and a chicken and then not tell the joke....that's just wrong. —Preceding unsigned comment added by 70.115.240.66 (talk) 04:02, 7 March 2008 (UTC)

External links

As I saw comment "NoMoreLinks" in “External links” section, therefore I suggest here one more useful link http://www.mountaingoatsoftware.com/scrum and suggest remove duplicate video link: http://video.google.co.uk/videoplay?docid=-7230144396191025011 Prusac (talk) 11:47, 25 March 2008 (UTC)

I think http://video.google.co.uk/videoplay?docid=-7230144396191025011 is too long and pretty complex (for people like me who's English isn't their first language). Moreover even subtitles appear too late. But this http://www.youtube.com/watch?v=vmGMpME_phg may be useful. It's short, gives an overview and easy to understand. Rryk (talk) 18:40, 5 October 2008 (UTC)

I would like to suggest to add the following link. Its a quick overview of Scrum and helpful while introducing Scrum. Scrum Cheat Sheet Teckmx5 (talk) 14:09, 26 September 2008 (UTC)

Oppose - Instead of linking to the particular site, extract whatever sourced ideas are found on the website and incorporate the ideas (if they aren't already present) in the body of the article. -- Iterator12n ^Talk 21:36, 26 September 2008 (UTC)

Suggesting a link to a new HD Video on Scrum Fundamentals: http://www.youtube.com/watch?v=Q5k7a9YEoUI&fmt=22 —Preceding unsigned comment added by 72.201.134.212 (talk) 04:24, 10 December 2008 (UTC)

Solo Scrum

I think there should be something in the references or links to justify the 'Solo Scrum' section. I did a Google on Solo Scrum, and didn't find anything official, just various posts by people saying they were going to try to do scrum in a team of one. —Preceding unsigned comment added by 82.163.39.121 (talk) 21:59, 2 April 2008 (UTC)

Strongly agree. Solo Scrum is nothing official, just an article on somobody's blog. It doesn't deserve a separate section on Wikipedia. —Preceding unsigned comment added by 81.219.244.145 (talk) 07:33, 20 May 2008 (UTC)

What is Scrum?

The first paragraph should answer this question. Some quotations from the Web:

Scrum is an Agile process that can be used to manage and control complex software and product development using iterative, incremental practices.

- (Company where Ken Scwaber works www.controlchaos.com)

SCRUM is a loose set of guidelines that govern the development process of a product, from its design stages to its completion.

- (Marc Clifton, J. Dunlap) http://www.codeproject.com/KB/architecture/scrum.aspx

Scrum is a simple set of practices and rules that encompasses the transparency, inspection, and adaptation requirements inherent in empirical process control.

- (Ken Schwaber) http://www.scrumalliance.org/system/resource/file/275/whatIsScrum.pdf

Scrum, an Agile approach, is an iterative, incremental process for developing products and managing projects.

- Conchago http://www.scrum-master.com/agile/whatisscrum.asp

Scrum is an Agile Software Development Process

- Jeff Sutherland http://jeffsutherland.com/scrum/index.html

Scrum is an agile methodology that focuses on a subset of project management and requirements management.

- Scott W. Ambler http://www.ddj.com/architect/207100381

Faller (talk) 09:11, 10 April 2008 (UTC)

The current description seems to be mildly misleading - Scrum isn't really a full process; it's not limited to software development projects; it's focussed on the management aspects of projects; "using it with" Agile Software Development doesn't have any meaning to me. What about

"Scrum is a framework for iterative and incremental project management. It is most commonly used for software development projects, and part of the Agile Software Development movement."

--IljaPreuss (talk) 07:03, 7 July 2008 (UTC)

article rename

The article seems to be slightly misnamed, since "development" doesn't really capture the proper flavor. I am a software developer, but I would not say I'm a developer. That could mean business development, media development, maturation development, etc., etc. Normally, I would just rename the article, but an article merge occurred not long ago. I suggest a better name would be Scrum (engineering). —EncMstr (talk) 22:17, 13 June 2008 (UTC)

I think that name is too scientific for this article. This article needs a broad title that includes all applications as you find in the extended usage of Scrum section.--Jorfer (talk) 02:35, 14 June 2008 (UTC)

Question

I am translating this article into chinese, but I have a question on burn down chart, the sentence in article below:

A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule.

My question is why the project could on schedule when the burn down chart is flat, can anyone give me a example to illustrate this? Thanks in advance. --用心阁 (talk) 16:17, 27 August 2008 (UTC)

The burndown chart represents the current sprint - the project consists of a number of sprints. It's possible, although a little ridiculous, for nothing to be developed during a sprint because it's already been developed. That would result in a flat graph, and an 'on-schedule' project. jjozolins

CAUTION section removed

I'm putting it here, so you don't have to dig thru the history. I find it badly written and only contributes to FUD. --Jordo ex (talk) 00:20, 10 April 2009 (UTC)

CAUTION: Nothing in this article has addressed the testing methodology of this development style, especially since this method is "adaptive" and done in sprints. Test cases designed during the beginning of the project may need to be totally redesigned and then must be run again each time something is new is created or added to the existing code --- creating the very possible cost-overrun potenial as well as added time-delay in product completion. (Testing must also be completed when any "fix" or "patch" is created.) Note: This development process will also require regression test development and testing (in addition to use-case scenario / requirements testing) to ensure that the new/additional code added to the product does not affect the integrity of previously tested code.

The following discussion is an archived debate of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the debate was do not merge. Jheiv (talk) 05:48, 23 October 2008 (UTC)

Stand-up meeting merge

Hello all. I was looking through the article (which is quite good thanks to some good effort from contributors) and noticed the "Stand-up meeting merge" notice. Since I didn't see anything already posted, I thought I'd put in my $0.02 to not merge that into this article. The reason being that stand-up meetings are useful in any development methodology, whether it be scrum, XP, RUP, traditional waterfall, or "custom blend #1". I'm certain that the "stand-up meeting" article can be easily generalized to apply to any type of methodology. Bdevoe (talk) 19:41, 29 September 2008 (UTC)

I agree with Bdevoe. Stand-up meetings are used in a wide variety of methodologies, and are not particular to (and did not originate in) Scrum. JPPrewitt (talk) 04:05, 13 October 2008 (UTC)

• I also agree that they should not be merged. I made a small change to stand up meeting so generalize it and it seems more neutral now. While Scrum development may use stand-up meetings, they are not one in the same and thus should not be merged.Jheiv (talk) 22:55, 22 October 2008 (UTC)

Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Videos

The Videos section seems to violate WP:LAYOUT. I've moved the section to what I consider a more appropriate part of the article based on WP:FURTHER. However, I think the links in there really belong in the External Links section rather than having their own section. Even better, relevant information would be placed in the article and the videos used as references, with less substantial videos simply removed.

Cleanup of '"Chicken" roles' section needed

Section currently has: "Chicken roles are not part of the actual Scrum process, but must be taken into account. An : People the software is being built for."

This paragraph was mangled back in this edit, and it is not clear what the editor was trying to accomplish. Oswald Glinkmeyer (talk) 17:17, 10 July 2009 (UTC)

This was fixed in this edit, thanks. Oswald Glinkmeyer (talk) 14:09, 22 July 2009 (UTC)

Cleanup: Reflex vs. Cognate

• Technically, a word like scrimmage and scrummage are reflexes.