This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Scrum methodology

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)

Product owner as pig

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

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)

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 metaphor

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)

CAUTION section removed

I'm putting it here, so you don't have to dig through 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.

Cleanup: Reflex vs. Cognate

Technically, a word like scrimmage and scrummage are reflexes. —Preceding unsigned comment added by Fatherlinux (talk • contribs) 18:17, 6 May 2010 (UTC)

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.

I worked at Easel Coperation together with Jeff Sutherland. The first Scrum Team was definitly build in 1993 (even when it was not called scrum) and was used for a Project called Synchrony/Synchonicity the later called "Object Modeling Tool" of Easel based on Enfin-Smalltalk. Beside Scrum for project management - the guys developed with XP. The guys where: Tom Krauss, John Scumniotales, Jeff McKenna, Gerd Eisenmann and some others. —Preceding unsigned comment added by JPB24 (talk • contribs) 16:26, 25 June 2010 (UTC)

Interesting you should say that. Do you have any WP:V proof of the names or just your word that 1) you worked there and 2) those were the people on the project? I'm not doubting you. Wikipedia on the otherhand does need proof. --Walter Görlitz (talk) 17:52, 25 June 2010 (UTC)

Sorry I don't have any proof on that but If you ask Jeff Sutherland he could confirm it. -- JPB24 (talk 20_02, 25 June 2010 (UTC)

It seems the entire section is in question and should be marked as such. --Walter Görlitz (talk) 18:34, 25 June 2010 (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

A sprint could consist on mostly fat tasks, taking up the better part of the sprint period. While this isn't optimal, there might be a reason for this (task might be so complex and prone to mutual dependencies in their parts that can't be broken down further). In that case, while everybody is busy tackling their big task, the burndown chart remains flat. When we're approaching the end of the sprint, everybody commits their big tasks and the burndown drops suddenly. The project was always on time, but the nature of the tasks hid it from the chart.

Signaleleven (talk) 20:03, 27 July 2010 (UTC)

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)

Today's version is still wrong, "they are people for whom the software is being built." [1]. The definition matches that of "product owner" a group listed under the "pigs" section, so this is logically inconsistent. The "customer" could be in the pig role if failure means losing their jobs or business. The "customer" (voice of the customer, product owner, whatever) could also be in the "chicken role" if the project isn't critical to their success. Typically, customers are in the chicken role. Rklawton (talk) 18:23, 10 August 2010 (UTC)

Redundancy

I think there is too much redundancy in this article. For instance the section "Terminology" repeats what has already been described previously.

ScrumMaster is defined in three slightly different ways in sections "Characteristics", "Roles" and "Terminology".

--Mortense (talk) 11:05, 19 May 2010 (UTC)

So fix it. By the way, it is considered incorrect to reformat others' edits on talk pages. --Walter Görlitz (talk) 14:00, 19 May 2010 (UTC)

Yes, the section is redundant. I've fixed it. Rklawton (talk) 18:28, 10 August 2010 (UTC)

How to

Yes, this is a hot topic in software development circles. However, we're writing for an encyclopedia, so we must be very careful not to turn this article into a "how to" for Scrum. I've removed one offending section already. The section explained in detail the formats and content of various types of meetings. Rklawton (talk) 18:30, 10 August 2010 (UTC)

I just restored the sections you labelled as "how to" and then deleted. They're not how-to sections, they're descriptive. If you don't think that the material is sufficiently formal or encyclopedic, it would be better to add a tag to the section and request improvement. --Walter Görlitz (talk) 18:55, 10 August 2010 (UTC)

You also restored redundant sections without explanation. If you wish to undo other people's work, please discuss your ideas on the talk page - as I did. Rklawton (talk) 19:08, 10 August 2010 (UTC)

Feel free to remove the redundant. WP:OWNERSHIP discusses the "please discuss your ideas on the talk page" argument. I restored the sections because you deleted them as "how to" sections when they're not how-to sections. Unfortunately they couldn't be be undone cleanly as a result of intervening edits so the restoration was a bit messy. I also plan to clean-up the citations now that i see how badly formed they are. --Walter Görlitz (talk) 19:16, 10 August 2010 (UTC)

Etymology

Based on its use in sports, in rugby to be specific (maybe elsewhere), its seems likely the meaning of the word within Software Development can be defined most objectively by examining its use in sports -- or in Rugby, specifically. Within the context of Rugby its use seems to be more specific -- better defined. In SW Dev the definitions I've been given are based on someone's familiarity with their group's use of the term. Then again, maybe this suggestion belongs in Wiktionary.

Kernel.package (talk) 08:09, 12 December 2010 (UTC)

The etymology of Scrum (development) is well-recorded. It's deliberately based on a rugby analogy. The fact that a scrum in rugby bears no relation to the claimed function was just a mis-understanding of how rugby is played. Andy Dingley (talk) 11:50, 12 December 2010 (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)

5. SCRUM doesnot address design level issue. Developer mostly focuses on task at hand and how quickly it can be moved out of his/her queue. This results in poor overall product quality.

6. SCRUM at the end becomes a number game where members churning out more defects gets more visibility with the stake holder. This need not necessarily be resulting to a good product. - Vijay Choudhury —Preceding unsigned comment added by 12.106.254.66 (talk) 13:43, 7 January 2011 (UTC)

I fully agree. I have never used Scrum but have heard bad reports of it and this article reads too much like an advert, especially when you consider that a lot of information on the web (and directed to in this article) is related to selling Scrum training. What we need are some links to good sources of the criticisms you point out that can be cited in the article. In the meantime I suggest a template be added warning readers that the article is biased or reads too much like an advertisement. I will add this shortly unless anyone has a good reason not to. Dwellings (talk) 09:33, 9 July 2010 (UTC)

You have heard bad reports? Selling training? What are you on about? --Walter Görlitz (talk) 13:50, 9 July 2010 (UTC)

Having now fully read what Dwellings has written I agree that a criticisms section is needed, but this article does not read like an advertisement. Any additions should be cited and should be NPOV. This is not the case with the anon who started this section. Sections 1, 2, and 4 are all incorrect. In fact scrum is the opposite of micromanagement in that the participants in scrum decide on what they're doing and attempt to achieve the goal. The conclusions in 3 are incorrect. --Walter Görlitz (talk) 16:18, 9 July 2010 (UTC)

Walter Görlitz - do you have any comments for 5th and 6th point. —Preceding unsigned comment added by 12.106.254.66 (talk) 13:49, 7 January 2011 (UTC)

My comments on the entire this is that it's utter nonsense. --Walter Görlitz (talk) 15:33, 7 January 2011 (UTC)

It would be strange to assume that Scrum is beyond criticism! I haven't looked for sources, but there certainly are problems with the incorrect use of Scrum (ask about my very reasonable consultancy rates on just this topic 8-) ) and many people see these as being an inherent failing of Scrum itself. Pretending they don't exist is just as bad as extrapolating "We used Scrum and we failed" into "Scrum is bad". Andy Dingley (talk) 15:51, 7 January 2011 (UTC)

It definitely would be strange to assume it's beyond criticism. There are complaints about it, but it's primarily the point of view of the observer. I haven't seen any negative articles about it, but then I don't seek them out either. There are shortcomings, but the ones listed above are not based on fact but are based on "this isn't the way we've done things" so it can't work. The only way to verify the information above is through good metrics, which I haven't seen. --Walter Görlitz (talk) 16:32, 7 January 2011 (UTC)

Metrics aren't illustrative here. Scrum is excellent at metrics - by Thatcher's Law (You deliver what you measure for), any methodology that is focussed on metrics will of course deliver exceptional results, when measured by those same metrics. My own experience of Scrum (which counts for nothing on WP, but is enough to allow me to charge money for its benefit) is that Scrum is the best method I've yet seen for building code — yet the code it can build, even in a correctly-run Scrum project, isn't always of good architectural quality, in a way that's outside of Scrum's measurements. This also has a causation that's directly related to the use of Scrum, and yet a solution that can be applied still within the Scrum framework. Andy Dingley (talk) 17:32, 7 January 2011 (UTC)

Those aren't the type of metrics I was suggesting. We need to look at how Scrum did a better job at a similar task to any one of the traditional development methodologies. I know that some exist but can't remember which conference I heard about them. Just to air grievances and ideas that in some circumstances this may have happened isn't criticism, it's suspicion. I suppose what needs to happen is that WP:V WP:RS that discuss the shortcomings be introduced into the article. Points 1 through 4 and 6 are just plain wrong. Point 5 is also misguided in that scrum, like all agile approaches, doesn't say anything about avoiding or working-on design-level issues. They are usually addressed like any other task. --Walter Görlitz (talk) 18:05, 7 January 2011 (UTC)

Point 5, as stated, is misguided — Agile approaches shouldn't constrain design. However Scrum has a tendency to do just this, and what's worse, to do it on the quiet.

The planning and task decomposition phase often silently implies architectural choices, in a way that's unclear and usually overlooked by those who should be controlling it. In particular there's a tendency to place a couple of coders with a task which they can't complete without first choosing some 3rd party UI component framework, an idiom for communication with exernal systems, a schema language for describing messages, or some other meta-task of that order. It's crucial that such decisions (not merely their outcomes, but the fact that a decision needing to be made even exists here) are identified before task plannng is finalised. Typically though they aren't, and what may in hindsight turn out to be a crucial choice is instead devolved to inexperienced coders under the usual task time pressure, with neither the long- or short-term experience to make the choice, or the time to research it carefully. Andy Dingley (talk) 19:36, 7 January 2011 (UTC)

Is this personal experience or universal practise? Again, I see a lot of conditional terms in your comment (usually, tendency, typically, may) and unless those are qualified in a WP:RS are meaningless in Wikipedia.

Again, I'm not saying that Scrum is perfect, we just can't make wild claims of criticism because that's what we think. --Walter Görlitz (talk) 19:50, 7 January 2011 (UTC)

Let me give a view of one project that i worked on. We started of with a semi-finished product which was not maintenable . Now management had decided to adopt SCRUM to complete the pending work.we started implemening SCRUM from March 2009 and according to metrics, it was supposed to be over by August 2009 which was calculated based on work backlog. Now it is January 2011 and the project still did not see light of the day and there are discussions that the project will again get an extention.Problem was the moment we fix one defect there was one defect raising in some other part of the application.What i feel(my personal opinion) is Refactoring the code and making the code more maintenable was better option then directly fixing the defect. How can anybody justify refactoring as a task in SCRUM model, specially when we need a large scale refactoring which may take months together. - Vijay Choudhury.

Thanks. Now we have to compare a team that was working on the same project using a different approach. Alternately, we have to look at a team working on a similar project, say the one you were working on before it started, and compare metrics. Anecdotal information is not a metric. Your situation sounds like a death march independent of the development approach. --Walter Görlitz (talk) 15:22, 10 January 2011 (UTC)

I'm sure we could all swap Scrum anecdotes (or if they're printed neatly and we're getting paid, we call them "case studies") until Walter reminds us that it's RS or nothing. None of that would really change the article. However we ought to recognise that Scrum can have criticisms applied to it, the mis-understanding of Scrum and mis-application of parts of it is absolutely rife, and that (subject to the usual editing quality standards), a section on criticisms is entirely appropriate. Andy Dingley (talk) 16:08, 10 January 2011 (UTC)

I'm just saying no matter what approch you follow unless the design is good and to the spec. All the approches will work fine. Further more, I will really appreciate, if there is a clear guide line as to when to implement and when not to implement. I surely belief that SCRUM is not a Silver Bullet for all the problems. —Preceding unsigned comment added by 12.106.254.66 (talk) 05:46, 11 January 2011 (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. --Firi e n § 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 • contribs) 20:30, January 24, 2007

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)

Reducing the focus on chickens and pigs

This is my reasoning for restructuring the Roles section.

The article presented the roles on a Scrum project as either chicken or pig. This is becoming increasingly disused and disliked by scrum practitioners and teachers alike, for a number of reasons:

while product owners do have 'skin in the game' and in some cases are able to commit themselves 100% to the development, this is often rare, and it is more often to find the interests of the product owner and product management community represented through another role, e.g. a business analyst
in strict terms, a project manager would not be a 'pig' role, but they clearly have a significant role in the project
some cultures are averse to porcine references, and would not appreciate their role being described as a pig
see also the criticism section on the Chicken and Pig article

Greyskinnedboy Talk 20:23, 9 February 2011 (UTC)

This page as been vandalized

This page should be reverted, some "funny guy" seems to have switched a lot of references to the word "scrum" by the word "scum".

10:22, 20 May 2011 (UTC) —Preceding unsigned comment added by 87.194.4.54 (talk)

Saw it. Reverted. --Walter Görlitz (talk) 14:05, 20 May 2011 (UTC)

Outside of software development?

Is this development/management model used at all outside of software development? --216.241.98.171 (talk) 21:02, 6 June 2011 (UTC)

Not much, but it can be.

The point about Scrum is that it relies on the team - a cross-functional team of peers. This is a relatively unusual organisation in business. Many businesses are instead tied to production machines rather than people, they ask similar rote roles from their workers and so their management is simpler anyway, or else they already have a dominating hierarchical management structure right down inside the team level. Only in processes like a software team do they have the same problem, so only there is Scrum needed, so only there - if anywhere - is it really useful to apply it. This can certainly be used with good effect across a range of 'design' processes, such as magazine production, graphic design generally and architecture.

You can incidentally do single-user Scrum, all on your own (daily standups get a bit introspective), where the task breakdown & planning approaches are still useful. Andy Dingley (talk) 21:46, 6 June 2011 (UTC)

Where did this come from?

Adaptive project management

The following are some general practices of Scrum:
* "Working more hours" does not necessarily mean "producing more output"
* "A happy team makes a tough task look simple"

And they are not "practices". Perhaps "principles"?
—DIV (138.194.11.244 (talk) 06:49, 9 June 2011 (UTC))

Meaning of scrum in rugby context

I removed the use of scrum in the first paragraph of the history section, as it was nonsensical. "Scrum" in rugby does not refer to the whole team; only 8 of the 15 players (the forwards) are actually engaged in a scrum, so to use the word interchangeably with "whole team" is incorrect. Also, while it could be used to refer to the players involved in a limited way, it only applies as long as the players are engaged in a scrum. Once the scrum is over, one would not refer to the forwards as the "scrum".199.46.200.233 (talk) 22:10, 27 July 2011 (UTC)

Scrum in the rugby sense is important here, because this is the term on which the development methodology was based. It's a misunderstanding of rugby, true enough, but that's still where it came from. Andy Dingley (talk) 22:23, 27 July 2011 (UTC)

Right. The point of my edit was to remove an incorrect application of the word scrum where it was used with respect to rugby, in order to make the fact that using the word "scrum" is a bit of a bastardization of the original "rugby concept" more clear. This helps to highlight the misunderstanding of rugby implicit in the original application of the term. Perhaps it would be useful to further modify to add that "scrum" refers to a part of the game of rugby, to tie the history together a little better, in the next paragraph where it discusses the original usage of scrum in this context. Surely we can tie the term to rugby without needing to misuse it.199.46.200.233 (talk) 22:34, 27 July 2011 (UTC)

Critique of Scrum

This article really needs a discussion of the shortcomings or downside of using scrum. —Preceding unsigned comment added by 120.17.181.113 (talk) 16:01, 19 May 2011 (UTC)

Sure. If you can find a WP:RS that offers information, feel free to add it. --Walter Görlitz (talk) 16:11, 19 May 2011 (UTC)

I agree. Unfortunately, I do not know Scrum and its critics well enough to write such a section itself, but I do know that criticisms do exist and ought to be represented here. As it is, the article is not NPOV. Kwertii (talk) 20:49, 3 August 2011 (UTC)

Mostly howto content

This page is mostly howto content; a basic overview of how to use Scrum. That's not very encyclopedic. How about getting rid of most of the Howto stuff and talking more about how and where Scrum has been used in the real world, perhaps list some major projects where it's been used, an overview of any academic studies that have been undertaken, and any criticisms that have been levelled against it. Kwertii (talk) 20:51, 3 August 2011 (UTC)

From a Scrum masters perspective, this page is actually a very good introduction to scrum. In fact, it is mandatory reading for interns and new employees at our firm. This is because we at least do not percieve it to be a Howto but a pretty good basic overview of what scrum is and what roles, meetings, artifacts etc are involved, nothing more. I would agree on adding content on real world applications, studies, criticisms and the like, but as an addition to the current text as opposed to a replacement. 82.176.103.57 (talk) 07:48, 9 September 2011 (UTC)

From the perspective of someone who has never used Scrum before, I find this article to be an excellent introduction. I just learned a tremendous amount about Scrum in a very short period of time. Why would we want to prevent others from doing the same? Perhaps it seems like "howto stuff" because it's an article about a process. I can think of two groups that would want to get rid of most of this article for less-than-honorable reasons: people who don't like Scrum and people who make money by selling information about it (e.g. books, training, etc.). If we applied the standard of "appearance in academic studies" to every such article, we'd have a much smaller (and less useful) Wikipedia. 70.125.66.239 (talk) 12:55, 14 October 2011 (UTC)

Please please replace (all) relative time references with absolute ones.

The last paragraph in the Scrum-ban section says "Since Scrum-ban is such a new development model"...

"New" is a relative term so it would be helpful if some sort of more absolute time-reference could be employed, such as "... new (as of YEAR) ...". Perhaps if enough data has been collected since that paragraph was written (Scrum-ban is no longer "new") the whole paragraph could be updated.

The same paragraph also refers to Kanban being 'more established' (my words) because it has been used by Microsoft and Corbis, but how long (since when) has that been? Again, please provide a time-reference.

Relative-time references may exist elsewhere in the article, but I wasn't looking for them.

I'm sorry I don't have a dates for YEAR or for Kanban usage. I just came here to get the basics of what Scrum is about. PReinie (talk) 15:04, 19 September 2011 (UTC)

Feel free to do so. --Walter Görlitz (talk) 16:57, 19 September 2011 (UTC)

Controversy section

In my opinion the controversy section is terrible. Except for the citation needed, there is an obvouis lack of understanding of scrum by the author. It's basicly a misinformed opinion. From my experience as a scrum master I would argue that the most common critisism would be the lack of support for lang-term planning, the implied "equality" of team members in skillset, responsibility and/or seniority and the lack of well-defined roles for team members. In this sense RUP would be a candidate for comparison, to higlight the differences. The comparison that was made with Kaizen holds no ground as both methods can co-exist without any problems (and do at our firm). I can not name a single resource on Scrum, nor can I come up with a real-life implementation, that mentions or requires "strong leadership" for scrum teams. In fact, the "self organizing team" is a core concept of scrum, hierarchy within a scrum team is discouraged sooner than encouraged or even required. — Preceding unsigned comment added by 82.176.103.57 (talk) 12:59, 20 October 2011 (UTC)

Could it be that your experience as a scrum master has created a point of view on your point that doesn't make it possible to see the criticism as accurate? You could indicate that the section has its own POV, but you would need to correct the POV rather than indicate that POV is not correct. --Walter Görlitz (talk) 14:03, 20 October 2011 (UTC)

Pretty much the whole article is unreferenced crap, but if you change anything, it just gets reverted as WP:OR. This fossilises the article as the even less accurate "grandfathered OR".

I would incidentally agree on the issues you raise here, particularly about planning. Mind you, I'm a CSM so I guess my experience has created a POV and I ought to be topic banned from yet another article on the grounds of knowing too much about it. Andy Dingley (talk) 21:49, 20 October 2011 (UTC)

Not necessarily grandfathered, it's reached a stage of WP:CONSENSUS. If you would like to make changes, or challenge material, that's fine, but the changes should be referenced. And it's one thing to know about a subject, it's another to be able to offer references for that knowledge. --Walter Görlitz (talk) 22:16, 20 October 2011 (UTC)

"WP:CONSENSUS" - You mean "Walter likes it" Andy Dingley (talk) 22:39, 20 October 2011 (UTC)

Very clever. Illiterate but clever. Go read what the term means and if you have something useful to add I'll listen to you, otherwise I'll point you to WP:CIVIL and leave it at that. --Walter Görlitz (talk) 23:16, 20 October 2011 (UTC)

I'll point you to WP:OWN. It has needed doing for some time. Andy Dingley (talk) 23:25, 20 October 2011 (UTC)

Quite familiar with it, thanks. Now if you have something to add to the article that's worthwhile add it. If not why are you being antagonistic? I take you still haven't read WP:CONSENSUS and have no intention of doing so either. --Walter Görlitz (talk) 23:40, 20 October 2011 (UTC)

Why scrum?

This article does not explain why someone would go to all the meetings and learn all the jargon. Is Scrum providing a solution that the Agile/Extreme Programming people missed? Is it an independent development that does the same thing as other Agile/Extreme Programming solutions?

I suppose I would call this design philosophy or something. That is where I might start in improving the article. Fotoguzzi (talk) 22:18, 22 August 2011 (UTC)

On one hand, you go through the training process because your boss tells you to. You boss sends you (and pays), because Scrum offers big advantages to managers, in terms of a more controlled software construction with much better reliability, better visibility and (best of all) a "fail fast" tendency that highlights problems at a sprint-length timescale, rather than getting to release day and finding it's all now an unrecoverable failure. Most of Scrum's virtues are upwards.

Agile doesn't do anything of itself, or require you to do things by a particular process. It's principles, but not a methodology. You can't "do" Agile.

XP is compatible with Scrum, and pair programming is especially compatible with Scrum. They both work at a lower level than Scrum though, and are more about design practices than Scrum, which is more about time & task management. I wouldn't call Scrum a "deisgn philosophy". It's focussed on task management, rather than approaches to design. It's also a concrete set of practices, not just a conceptual philosophy (Agile is a philosophy, Scrum is more). Andy Dingley (talk) 14:58, 23 August 2011 (UTC)

I added a section "Evaluation". I'm a bit disappointed that it was edited by Mr Görlitz to render only a list of potential drawbacks. I think we all agree that SCRUM can be useful. Rather than going back and forth between my version and his (a struggle I will lose), I would like to point out that, IMO, there just has to be a section like this. And we have to start somewhere. I fully agree there is a lack of references, please step up because I cannot remember where I read things to save my life (not a researcher, obviously).

The problem with the page without an 'Evaluation' section is that looks like a text straight from a commercial white paper! That is not a good idea. Does anyone disagree that a section like this is badly needed? I can see others having the same opinion. Let's start now.BertBril (talk) 07:11, 4 November 2011 (UTC)

I'm disappointed that you added that. First, it doesn't discuss the evaluation of Scrum, it simply lists criticisms of it. It's completely biased, essay-like, unreferenced and likely placed undue weight on your opinion. If I hadn't edited it, someone would have had the right to remove it completely. If you want to write about how to evaluate Scrum, you should write it. If you want to write about its criticisms, you should write that. However, what you wrote wasn't particularly helpful. --Walter Görlitz (talk) 07:25, 4 November 2011 (UTC)

The problem with this page imho is that it is excellent where it is factual, describing the roles and artifacts involved in scrum etc, but it goes downhill fast when subjects like evaluation/critisism/controversy are touched. I think the main cause of this is the lack of good resources. I could give you the strengths and weaknesses of scrum from my own experience but that would be original research at best, an opinion at worst. Maybe it's better to simply state that there is a lack of good resources on these subjects and refrain from adding mere opinion just because "there has to be an evaluation". — Preceding unsigned comment added by 82.176.32.221 (talk • contribs)

OK, I get the picture. Shoo shoo! You're on the wrong track because I am sure I know better. Good way to lose input. BertBril (talk) 08:22, 4 November 2011 (UTC)

I don't think you read what I wrote. I didn't ask you to leave, I asked you to write more clearly and with better content. I didn't say I know better, I said that what you wrote wasn't very good. --Walter Görlitz (talk) 14:06, 4 November 2011 (UTC)

Upper case?

The word "scrum" is capitalized everywhere in the article, but it should not be. It does not meet any of the MoS criteria for capitalization: it is not a proper noun, title or religion, name of a week day, name of a month, celestial body, scientific name for a generum, or a direction. -Pgan002 (talk) 10:10, 3 January 2012 (UTC)

There's a referenced statement in the article "Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title." --Walter Görlitz (talk) 14:56, 3 January 2012 (UTC)

A reiteration of the intro problem. Hack it into 2 parts for now.

I know you all are working on this page as well as you can. But from my point of view as a software engineer of 20+ years I still don't see why the intro stands at all. It would be better to leave it at the first sentence for now, and then have folks flesh it out. The remainder of the paragraph should be a new paragraph rather than have folks attempt to work around something that shouldn't be in the first paragraph at all.

Here's the current rendition of the intro:

Scrum is a form of agile project management. Although the Scrum approach was originally suggested for controlling manufacturing, its use has shifted on the management of other projects, and it can be used to run manufacturing maintenance groups or as a general restaurant management type daily chore with a repeated machine driven effort that does not require any creativity or intelligence.

...ok. So what is it?Tgm1024 (talk) 14:28, 5 February 2012 (UTC)

In my opinion (working in an agile team for 3 years now) this page, including the intro, was made incorrect earlier this year. This is the last version that is correct in my opinion: [[2]] — Preceding unsigned comment added by 87.194.162.3 (talk) 22:46, 19 February 2012 (UTC)

Too Many Meetings

Do you have any problems that would prevent you from accomplishing your goal? Yes, the Daily Scrum

The biggest negative I can see with Scrum is all the meetings required, especially the daily meetings. Getting managers into a daily meeting at a set time is difficult in and of itself. Getting all the programmers to get there on time is another problem. Keeping the meeting short is nearly impossible. Our programmer meetings rarely are under one hour long. When a programmer gets in for the day, rather than concentrating on programming his project, he will be focused on preparing to give a status for the daily scrum. — Preceding unsigned comment added by Kurrgo master of planet x (talk • contribs) 21:28, 1 November 2011 (UTC)

As far as i know this page is for discussion of the article, not the subject of the article. My personal experience is that daily's take under ten minutes for an eight person team, management doesn't need to attend every single meeting and when a programmer needs to prepare to give a status he or she has poor insight in his or her workflow, wich is exactly what scrum tries to iron out. However, both our opinions can not be generalized to be of any use to this article and therefore further discussion has little merit. — Preceding unsigned comment added by 82.176.32.221 (talk) 14:49, 6 November 2011 (UTC)

It's a valid complaint but daily stand-ups don't usually cause a problem and keep the project moving forward and alerts the Scrum Master and other members to potential problems. This avoids breaking "Rule 4 - Don't go dark". Google it. You'll figure it out. --Walter Görlitz (talk) 15:05, 6 November 2011 (UTC)

Kurrgo, I've heard this as a very common complaint from all levels of experience. Without direct experience of my own on the issue, I can say that in general the proponents of scrum that I've spoken to are largely claiming words to the effect of "if you don't like it, you are not doing it right". I understand that phenomenon as I'm guilty of this same posture myself regarding object oriented (vs. procedural) programming. But I have to wonder: can you cite any cogent arguments against scrum? If so, then the fact that they exist would very much belong in the article.Tgm1024 (talk) 14:40, 5 February 2012 (UTC)

Scrum slows down the development process. Overall, I'm seeing about a 50% decline in productivity. This is due to breakup of items into smaller pieces (more overhead per piece). More meetings. etc. If you say anything, the proponents jump up and point fingers and say "you're not doing it right", but I've seen teams "do it right" and take 4 times longer to get things done. — Preceding unsigned comment added by 216.116.87.110 (talk) 21:21, 23 March 2012 (UTC)

When compared to what? And anecdotal evidence doesn't really count. --Walter Görlitz (talk) 21:41, 23 March 2012 (UTC)

Lack of balance, opposing views, evidence of usefullness

While a very good overview of the SCRUM method, there is no opposing points of view identified (i.e. the article is very one-sided in its treatment of the topic). SCRUM has been shown to "work" in a number of domains but what is its overall long and short term efficiency compared to other development methods (there is no such evidence identified)? Are there any side-by-side statistically significant supporting material that can be used to support this method as any better or worse than other software development methods? If so, it would be very useful to include that information at some point in the article. — Preceding unsigned comment added by 24.147.40.101 (talk) 22:10, 1 April 2012 (UTC)

Agile project management with scrum

I have a serious problem with the sentence "Scrum has not only reinforced the interest in project management, but also challenged the conventional ideas about such management" in this section. While I think that the second part of the sentence is trivially true, I find it hard to swallow the claim in the first half ("Scrum has not only reinforced the interest in project management"), and it is certainly not supported by the source at the end of the section (Schwaber's Agile Project Management with Scrum). If someone feels it is supported by the source, please direct me to the part of the book where Schwaber goes into how scrum has reinfored the interest in project management. --Kristjan Wager (talk) 19:09, 12 April 2012 (UTC)

I have not read the reference at the end of the paragraph. --Walter Görlitz (talk) 19:28, 12 April 2012 (UTC)

Proposal to retrospective meeting section.

It is good thing to keep friendly atmosphere with coffee and cookies during retrospective meeting. — Preceding unsigned comment added by 178.252.127.253 (talk) 15:30, 22 April 2012 (UTC)

Lack of critique and too much focus on the pursuit of efficiency

The comment above mentions that what is needed is an idea of "long and short term efficiency compared to other development methods". There is more to that, actually, because efficiency is only one of the many goals that may be pursued by a team or an organization. Arguably, the sole pursuit of efficiency has its shortcomings, because it discredits other values and goals which may actually be more valuable to the organization. What is needed is a critical overview of all outcomes of SCRUM, an deep examination of it's benefits and shortcomings of any sort, not only efficiency-wise. Wadim.grasza (talk) 07:52, 26 May 2012 (UTC)

Backlog grooming

Which backlog is being groomed ? The product or the sprint backlog ? I guess the product backlog, because the sprint backlog is "frozen". 109.91.255.70 (talk) 14:31, 24 May 2012 (UTC)

"Team"

The article says "(1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog"

I guess "Team" is referring to the "Development Team". Is that correct ?

109.91.255.70 (talk) 14:53, 24 May 2012 (UTC)

Team refers to all members of the team. --Walter Görlitz (talk) 15:03, 24 May 2012 (UTC)

Follow-up

The short story:

It´s either "Scrum team" or "Development team".

It´s not "Team" or "Team only". These terms aren´t defined.

The long story:

The article defines

"

a) Scrum teams consist of three core roles and a range of ancillary roles.

b) The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint.

c) (1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog

d) (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog

"

a) and b) are definitions, but c) and d) aren´t consistent with these definitions.

In c) What is the word "Team" in the term "Product Owner + Team" conveying ?

If "Team" comprises all roles defined in a), then "Product Owner" is redundant. The correct term instead of "Product Owner + Team" is "Scrum team".

If "Team" means "Development Team" defined in b), then the term "Development Team" has to be used. The correct term instead of "Product Owner + Team" is "Product owner and Development team".

In d) What is the word "Team" in the term "Team only" conveying ?

If "Team" comprises all roles defined in a), then the word "only" has no meaning. The correct term instead of "Team only" is "Scrum team".

If "Team" means "Development Team" defined in b), then the word "only" has no meaning. The correct term instead of "Team only" is "Development Team".

109.91.255.70 (talk) 15:57, 24 May 2012 (UTC)

Per the article. "the whole process is performed by one cross-functional team across multiple overlapping phases". So in context it is understood. --Walter Görlitz (talk) 16:41, 24 May 2012 (UTC)

No source for sprint backlog being frozen

In the Sprint section the article states "During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint." However the Scrum Guide mentions changing the sprint backlog more than once, e.g. under the Sprint Backlog section "The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal." Where does the idea of the sprint backlog being frozen come from? Maltiriel (talk) 16:44, 30 May 2012 (UTC)

The sentence "During a sprint ..." is not good. It says "no one is allowed to change the sprint backlog" = "requirements are frozen". The sprint backlog contains more than requirements, see in the section "Sprint Backlog": "Tasks on the sprint backlog are never assigned". So the Sprint Backlog at least contains the tasks.

I´d change the sentence to either "The requirements are frozen for the sprint." or better - to be less metaphorical and more precise/technical-: "Nobody is allowed to change the requirements in the sprint backlog."

Acontrib (talk) 16:30, 11 June 2012 (UTC)

It's pigs vs chickens (possibly the only time this inane phrases makes a difference). There are two backlogs: Product Backlog and Sprint Backlog. The Product Backlog is owned by the Lead Chicken. Grooming (aka gardening) this backlog is a major task for the Product Owner (basically the only thing that they do, or (more generously) the single document representing what it is that they've done). It represents management's wishlist of features. Traditionally the last on the list will be something like "dancing penguins" or "...and a pony". They can fiddle with this as much and as often as they like, but no-one has to listen to them.

Then there is the Sprint Backlog. This is copied from the Product Backlog during the initial sprint planning meetings, with substantial horse-trading and pruning. After this though it remains static throughout the Sprint. This is the fundamental basis of Scrum: management wishlists don't mess with the dev team while they are busy doing useful work. If you aren't doing this, then you aren't doing Scrum, you're doing reactive arse-kissing and cat herding. There are two ways to work the Sprint Backlog during a sprint - either don't mess with it at all, or (more flexibly) allow the Lord of the Flies (Lead Pig) to change it - often this is solely by removing tasks from it. It's a bit dogmatic to say that it can't ever be changed, but if the chickens get to change it rather than the pigs alone, then you've stopped doing Scrum.

If you have to make such changes that they're outside this scope, then it's best to abandon that sprint rapidly (some tasks might still be worth completing cleanly), because if you have to re-jig the Sprint Backlog to track a changed Product Backlog (for either scope of change, or their urgency), then it's crucial that you go through the sprint planning step again.

(As an aside, most problems I've ever seen with Scrum are from failing to appreciate the importance of the sprint planning, or failing to realise how many technical design decisions are made silently, implicitly and frequently badly during it.) Andy Dingley (talk) (Certified Scrum Master) 16:54, 11 June 2012 (UTC)

This still seems to contradict what the Scrum Guide says. "The Development Team modifies Sprint Backlog throughout the Sprint" seems pretty clear. It says in "The Sprint" section that "No changes are made that would affect the Sprint Goal" however. Just going from the guide there's more emphasis on the sprint goal being unchangeable, whereas the sprint backlog may change to support the goal. The idea that the sprint backlog isn't supposed to be changed is all over the web in discussions, but I can't find a more authoritative source for this idea. If it's going to appear in this article, doesn't it need a real source? Maltiriel (talk) 17:16, 11 June 2012 (UTC)

The crucial point is not whether it's changed or not (people do work both ways), but that it's not changed by the whim of the chickens. That much is consistent. Andy Dingley (talk) 17:48, 11 June 2012 (UTC)

I would argue that the crucial point for this particular discussion IS whether or not the sprint backlog is allowed to be changed; right now the article states that changes are not allowed by anyone and doesn't have any disclaimers or further explanation. If it is allowed to be changed by the development team, the article should say that, perhaps emphasizing that changes are only made in order to support the sprint goal. As it stands now it's highly confusing to someone like me trying to learn about scrum; this point pretty clearly contradicts the Scrum Guide, so if nothing else there should be clarification on why it contradicts the guide and where the idea comes from.

To be clear, I am in fact confused on this point and have been seeking clarification but finding none. This confusion is the sole reason I finally signed up for an account on wikipedia. The article in its current state only adds to the confusion. Maltiriel (talk) 18:03, 11 June 2012 (UTC)

The issue of "Can it be changed by anyone?" is relatively unimportant, because Scrum allows it to happen either way, and both of these approaches are still consistent with Scrum. Scrum cares that the chickens can't change it. This seemingly trivial point is actually at the core of Scrum's key principle, let the developers get one with things undisturbed. Andy Dingley (talk) 18:44, 11 June 2012 (UTC)

That's fine, but we're not supposed to be discussing scrum in general (it even says this at the top of the talk page, right? I'm new here but I'm trying to follow the rules), we're supposed to be discussing what this particular article says, and whether or not it's true that the sprint backlog can never be changed, and where the assertion that the sprint backlog can't be changed comes from. The relative importance of changing the sprint backlog to scrum in general is off-topic to this particular discussion. The point of the discussion is simply whether or not it is allowed and if it isn't, what sources say that. Maltiriel (talk) 19:52, 11 June 2012 (UTC)

"we're not supposed to be discussing scrum in general"

That's the sort of dogma that has brought the article to the unambiguous pinnacle of clarity it is today. Enjoy. Andy Dingley (talk) 21:43, 11 June 2012 (UTC)

Sashimi definition incorrect

The current page defines Sashimi as:

A report that something is "done". The definition of "done" may vary from one Scrum team to another, but must be consistent within one team.

Defining "done" is really important, but Sashimi is not "a report that something is done". Sashimi is an approach to accomplishing "doneness" in a short-term, purposely iterative manner. For example, one way to practice Sashimi during development is to divide a story into tasks that can be accomplished in less than a day, ensuring that there are daily: unit tests coded, VCS commits, CI builds, and (opportunities for) code reviews. In this case, once could say that "slices of sashimi result in reports of things that are 'done' at the daily scrum". Sashimi can be practiced at various levels (epic, story, iteration) to accomplish goals for full or partially completed (yet fully integrated) functionality. Sources:

http://spemarti.googlecode.com/files/Schwaber2004.pdf (page 60 and elsewhere)
http://jeffsutherland.com/scrumhandbook.pdf (page 39)
http://msdn.microsoft.com/en-us/architecture/ff476940.aspx ("Sashimi" section)

MKC (talk) 16:44, 19 October 2012 (UTC)

Question about the reversion of a link on the Scum (development) page

I wanted to ask why the link I added was marked as spam? It is a article which talks about what the product backlog is in factual terms and attempts (I think well) to educate people in more detail than the wiki page could and should go into. For this reason I though it was useful (and yes, I'm the author). If you still think it is spam, what would make this page be considered a valid link?

Thanks

mark at stateofflux.com — Preceding unsigned comment added by Markmansouraustralia (talk • contribs) 03:28, 14 November 2012 (UTC)

http://agilebench.com/blog/the-product-backlog-for-agile-teams is not just an article that talks about what the product backlog is in factual terms, it's a company website that is trying to sell a product and there's a "Star a free trial now" link at the bottom of the article. WP:SPAMLINK states "Adding external links to an article or user page for the purpose of promoting a website or a product is not allowed, and is considered to be spam." If it wasn't for the free trial link at the bottom, it likely would have withstood the test. But hey, I'm just one editor and have been known to be wrong in the past, so it's good that you asked. We'll let other editors here discuss if the link is SPAM or not. --Walter Görlitz (talk) 05:37, 14 November 2012 (UTC)

Thanks for the clear and straighforward reply. I've love to hear what another editor thinks. — Preceding unsigned comment added by Markmansouraustralia (talk • contribs) 05:41, 14 November 2012 (UTC)

Scrum Master

This section made no sense to me: The Scrum Master differs from that of a the Project Manager in that the latter may also have people management responsibilities in addition to the role of a Scrum Master. The Scrum Master role excludes any such additional people responsibilities.

I thought it might have meant: The Scrum Master differs from that of a the Project Manager in that while the latter may also have people management responsibilities, the Scrum Master role excludes any such additional people responsibilities.

However, I wasn't at all sure and decided not to edit it. Having worked with Scrum for 3 years, I fail to see why a scrum master cannot have people management responsibilities. I would have thought the position ideally suited to see the strengths and weaknesses in the team. However, it would depend on culture, if the team is of mixed ability and has a hierarchical structure I can see how the above might be true. Fortunately I do not work in such an environment. JCastle4 (talk) 16:43, 30 December 2012 (UTC)

Arbitrary timeboxes

In the meetings sections there are a lot of suggested timebox durations. These seem particularly pointless to me. A suitable duration for a meeting will depend on many things. E.g. the sprint planning meeting will be primarily determined by your sprint duration. However, it will also depend on the people. Scrum teams self organise and over time any rules get thrown out the window, so you have to know the fundamental things that make scrum work. Actually, I'm not sure that the self organising aspect of scrum comes across in this article. JCastle4 (talk) 16:48, 30 December 2012 (UTC)

This page sucks

This page sucks, it goes into lots of inane details and names without providing a comprehensive description of the core ideas, the improvements compared to previous processes and most importantly the rationale behind them. — Preceding unsigned comment added by 2.235.152.186 (talk) 20:38, 17 October 2012 (UTC)

It explains what needs to be explained. If you want to address some of what you see as shortcomings, feel free to. --Walter Görlitz (talk) 17:44, 15 November 2012 (UTC)

Frankly, it explains nothing. Re-read the introduction. "Scrum is a radically new approach making everyone happy. It concentrates on being superior and solving everyone's problems".. I wonder if there's even a single word related to *what Scrum actually is*/ I agree with 2.235, article sucks. -- 176.109.79.241 (talk) 12:34, 28 December 2012 (UTC)

As the initial definition of scrum did not specify how requirements have to be specified, I'd suggest either removing the '(typically user stories)' or clarify that best practices have shown, that user stories work well with scrum (citation needed of course). — Preceding unsigned comment added by 217.196.66.222 (talk) 15:53, 15 November 2012 (UTC)

That's because Scrum doesn't address requirements gathering. Agile itself doesn't say how requirements are to be gathered either. However, user stories and use cases are the most common forms of requirements gathering. --Walter Görlitz (talk) 17:44, 15 November 2012 (UTC)

I agree, there is something fundamental lacking here. It describes the effects of scrums and how it is implemented leaving aside the goal of scrum. I looked for the presence of something in here saying the objective is to produce fully functional, working software, ready to release to customers and failed to find it. It's buried in implementation detail. Yet this is the objective of a sprint and at the heart of what scrum is. A cross functional team trying to produce working software within a timebox. JCastle4 (talk) 16:38, 30 December 2012 (UTC)

I think that's not the problem here. This article simply lacks a clean explanation of what scrum is. Not what it tries to be, not how it wants to be named, not what objectives it has. What it IS. Compare "The dog is an animal of such and such species which looks like this" and "The dog is unique in that everyone loves it. It's objective is to find food and procreate and it aims to be the best at that." -- 176.109.79.241 (talk) 20:47, 6 January 2013 (UTC)

I mean, look at the introduction. If you leave only the informative parts, what it says is: Scrum is an iterative and incremental agile software development framework which uses mechanisms of empirical process control. That doesn't explain much. There's something about bringing decision-making authority to the level of operation properties and certainties, but I'm not sure that even those who wrote that understood that they were trying to say. What exactly ARE "operation properties and certainties"? Anything call be called a property. And how do you "bring" the "decision-making authority" to the "level of it"? -- 176.109.79.241 (talk) 20:47, 6 January 2013 (UTC)