Talk:Scrum (software development)/Archive 3

Archive 1

Archive 2

Archive 3

Project management tools that support scrum

Updated section by correcting spelling mistakes, updating links, and adding newer tools to section, as well as added a section on an emerging feature that several of the tools are recently integrating into their feature set. Jeff Nailen (Talk 22:31, 27 February 2013 (UTC)

Request to rename article to Scrum (software development)

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: Move. Nathan Johnson (talk) 18:57, 25 May 2013 (UTC)

---

Scrum (development) → Scrum (software development) –

The word Scrum is used with reference to Software Development, just like Sprint, since that page uses the article name - Sprint (Software_Development), i would suggest that even this page should use a similar syntax/nomenclature policy and get renamed to Scrum (Software_Development). I think i should consider public opinion and hence posted this here. If consensus is not reached or no opinions turn up, i shall myself blank the current page and create a new one as i mention. Agile Editing! Compfreak7 (talk) 14:00, 9 May 2013 (UTC)

Makes sense. Walter Görlitz (talk) 14:10, 9 May 2013 (UTC)

Oppose Weak oppose. If anything, I'd suggest moving Sprint (software development) to Sprint (development). There's no need for the longer disambiguation. (Updated per ongoing discussions below. —me_and 09:51, 10 May 2013 (UTC))

For future reference, you may want to take a look at WP:MOVE for the standard process for proposing a page move and making the move. In particular, blanking a page and copying the content is frowned upon, as the edit history gets left behind.

—me_and 15:06, 9 May 2013 (UTC)

I was actually looking for something like a simple MOVE button that allows users to place a request to move a page or rename, since I m very well aware that page history is always retained and people who dont agree with my(our) views (as per the consensus) will simply come and revert back. Maybe my wikipedia theme/skin hides it somewhere i havent explored. I will try doing what WP:MOVE says as i understand it. Thanks :-) Compfreak7 (talk) 15:11, 9 May 2013 (UTC)

WP:RM now lists the page move action for users to review [support/oppose]. Btw, me,imho, if you like to move Sprint as you mentioned, then you should do the same them on that page too. Do I/We have to really wait for 7 days to get this simple name changed? Compfreak7 (talk) 15:22, 9 May 2013 (UTC)

I don't feel strongly enough to propose a move; the status quo seems fine to me.

If there's a clear consensus, it's not always necessary to wait for the full 7 days, but I don't think that applies here. This isn't critical to Wikipedia, there's no rush, we can afford to take our time to make sure we make the right decisions :)

—me_and 16:29, 9 May 2013 (UTC)

• Support I hadn't thought about it, but it does make sense, for WP:PRECISION. Whomever created the dab title as 'development' was clearly a software developer, because only we think of that word as being exclusive to software. Software development is much more explicit and clear. §FreeRangeFrog^croak 16:31, 9 May 2013 (UTC)

I'd be curious why me_and would like to see the other article moved to development only. The term is too vague. A "development" also a construction project. I had a friend working in "development" for the UN between the civil war in Sierra Leone. My son's best friend, a young hockey player, attends "development" camps and in his spare time, he works on the "development" of his muscles. While I understand that you want a generic term since both Scrum and Sprints are not simply used in Software Development, they are used in the computer industry outside of that, but here "software" is a generic term to help clarify what sort of development is happening. I would strongly oppose a more vague move as you suggest so perhaps a better adjective that software could be found. Would computer development be objectionable? Perhaps another term? Walter Görlitz (talk) 17:39, 9 May 2013 (UTC)

I am equally curious to know why the Sprint link should be changed. For both scrum and sprint, as described in the article, are both strongly related to software development. Here generics, in my opinion, doesnt apply or cant be applied. — Preceding unsigned comment added by Compfreak7 (talk • contribs) 17:52, 9 May 2013 (UTC)

Perhaps "computing" is the preferable adjective. Walter Görlitz (talk) 19:20, 9 May 2013 (UTC)

"Computing" would be fine too. It's "development" on its own that's a bit vague. §FreeRangeFrog^croak 23:27, 9 May 2013 (UTC)

I'd prefer the more general term for two reasons: first, I can see how sprints and Scrum and so forth could be applied to certain kinds of development other than software development (things that jump to mind are primarily things like graphic design), and second because there's no need to disambiguate between, for example, Scrum (software development) and Scrum (muscle development). I don't feel particularly strongly, though; I've updated my !vote accordingly. —me_and 09:51, 10 May 2013 (UTC)

• Support, for better precision and consistency with the titling of other related subjects. ╠╣uw [talk] 10:24, 25 May 2013 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.

Project management tools that support scrum — licenses

It this section the word commercial is used in place of “not Free Software”/“not Open Source”. Commercial is not the opposite as software can be Free, Open Source and commercial(be sold etc). A better word is proprietary. — Preceding unsigned comment added by 82.144.244.99 (talk) 13:06, 26 September 2013 (UTC)

There are a few problems. You're assuming that it's about license, when clearly it was about methodology. Do I have access to the code or is it a proprietary system? Also FOSS is a redirect. At least you could avoid that. Finally, none of it, including the previous information, needed to be capitalized. Walter Görlitz (talk) 14:11, 26 September 2013 (UTC)

Backlogs in scrum

A note on backlogs: On the wikipedia page, 2 backlogs are described: product and sprint backlog. In (many?) cases, scrum works with 3 backlogs, also the release backlog. This is a backlog in between the product backlog and sprint backlog and everything in this release backlog will be finished at one release date. A release backlog is usually broken up into mulitple sprints (again, with individual sprint backlogs...). (86.62.179.210 (talk) 07:18, 20 June 2013 (UTC))

Actually, the terminology product backlog and sprint backlog is in conformance with the the Scrum Guide. Scrum does not define a release backlog (though a release burndown chart is a commonly used artefact). Peterstev (talk) 15:19, 1 October 2013 (UTC)

Scrum Roles includes many roles that are not defined in Scrum.

Hi everyone, I'm new to this section, but I read the page on Scrum and felt the need to get involved.

The definition of Scrum Master, Product Owner and Development Team are largely correct, but the discussion of other roles, i.e. "Project Manager, The Project Executive and Project Board, Project Assurance, Managers, Stakeholders" does not belong here. Those may be Prince2 roles, but they are not Scrum roles.

Scrum defines three roles, and no others. The words "project manager", or even just "manager" do not appear in the Scrum Guide (either 2011 or 2013 versions).

In particular, the reference to "Project Manager" as "The individual responsible for the success of the project" is particularly inappropriate, because a Scrum project does not have a project manager. — Preceding unsigned comment added by Peterstev (talk • contribs) 07:10, 1 October 2013 (UTC)

Be bold and make the changes.LLeave edit summaries as you go. Ideally provide references too. Walter Görlitz (talk) 14:05, 1 October 2013 (UTC)

I've never seen a Scrum project that didn't have a project manager (and I'm a trained CSM). A hang-over from past practices maybe, but these pointy-haired dinosaurs are still around and they still have that title and responsibility. Rather than deleting it from this article, I'd rather see it explained that Scrum doesn't need such a role, who does it instead (a role-based and clearly-defined split between PO and CM) and that a legacy PM will, if anything, be the person who instigates Scrum for a project and then leaves it to go ahead in a Scrum-based manner. It would probably be OR to say that they're an interfering skeuomorph who just overlaps with the PO, argues with the SM and consumes space at the daily standup.

In practice, I've not seen much trouble from these surplus PMs. They're normally happy to look out of the windows, or else they're trying desperately to catch up on some PRINCE2 report whilst the Scrum races past them. Andy Dingley (talk) 14:24, 1 October 2013 (UTC)

I've never seen a Scrum project that didn't have one either, but Peterstev is not incorrect in stating that they are not defined in Scrum. It's the difference between the definition and practice. Walter Görlitz (talk) 14:27, 1 October 2013 (UTC)

Thanks for your encouragement. I have deleted the Prince 2 related passages. I like the idea of explaining why Scrum doesn't need a project leader (or more generally, how it is different from the approaches beforehand. I will come up with some references (that I did not myself write) and suggest some text.Peterstev (talk) 15:35, 1 October 2013 (UTC)

Doesn't Scrum still recognise stakeholders though, even if not specifying their behaviour as a role. These are the people whom the PO represents by proxy. Andy Dingley (talk) 15:53, 1 October 2013 (UTC)

Scrum Meeting Picture

Hello! I feel that the picture has zero significance for Scrum. I may be wrong, but it looks simply like any other group meeting and not particularly like Scrum. 85.178.225.75 (talk) 19:12, 2 October 2013 (UTC)

Move Scrum-ban to a different article

Some Scrum folks believe Kanban is a reaction by people who do not understand Scrum. It is not part of Scrum and should be moved to it's own page (and referenced from this page). Gr8ful (talk) 04:45, 10 January 2014 (UTC)

Missing an essential topic!

The page on TSP makes it clear TSP requires training before using it.

One thing I've heard over and over is that "Scrum is easy to understand, but difficult to implement."

I'd like to suggest the article be updated to make it clear that training AND leveraging experienced professionals is essential to success with Scrum. I've seen many people attempt Scrum on their own, after reading about it, and it rarely succeeds. Gr8ful (talk) 04:59, 10 January 2014 (UTC)

Lip-Service Scrum: should it be covered?

The sentiment where I live (Chicago) is the majority of companies that claim to do Scrum are not really doing Scrum. (Some call this "lip service" Scrum).

I've personally worked with several companies that claim to be doing Scrum yet I find few, if any, Scrum practices. They use Scrum terminology but do not change their processes.

For example, at one client, instead of a Scrum meeting, they hold a status meeting. They assign work to the team, skip the retrospective, etc. In fact I could not find a single Scrum practice.

I think this is important enough to include in the article. I have no idea how, but it should be.

Scrum has become very popular, yet when CIO's do not see expected benefits, it will fail.

Yes, good topic. It could be called Scrumbut, False Scrum or Pseudo Scrum. There has already been some explanations of Scrumbut in the terminology section, from which a new section (e.g. Pseudo Scrum or Pitfalls...) could be added and expanded. Softzen (talk) 12:36, 13 January 2014 (UTC)

Agreed, however it won't last five minutes here. This article is currently unrealistically thin about Scrum, because anything that isn't simplistically sourced gets removed forthwith. So over-promotional advertorial is OK, as is trivial news reporting, but anything from real Scrum practitioners gets deleted as "blogs".

Scrum has long suffered from one of its more obvious advantages: it's possible to explain Scrum in a short elevator pitch. Of course, it's not possible to explain Scrum correctly in such a short form, but it does lead managers to think that they know Scrum and to impose their "pigs and chickens" version of it, with poor results. We all know this. We could even identify common characteristics of this "failed Scrum" and certainly the ways in which "failed Scrum" is different from real Scrum. However I don't think it's possible to make such an addition stick in this article, it would be removed immediately. Andy Dingley (talk) 14:49, 13 January 2014 (UTC)

If it's unrealistically thin then find WP:RSes to support expanding it. Walter Görlitz (talk) 14:53, 13 January 2014 (UTC)

However I don't think it's possible to make such an addition stick in this article, it would be removed immediately. —— I'm a new comer. Let's have a try. This should be prevented. Softzen (talk) 03:45, 14 January 2014 (UTC)

Scrum has long suffered from one of its more obvious advantages: it's possible to explain Scrum in a short elevator pitch. Of course, it's not possible to explain Scrum correctly in such a short form, but it does lead managers to think that they know Scrum and to impose their "pigs and chickens" version of it, with poor results. We all know this. —— Great comments from fields! Aren't these the results of Certification Syndromes? Softzen (talk) 03:55, 14 January 2014 (UTC)

I've not seen Certification Syndrome around Scrum – although I know it well from most of the other certification mills. Maybe I was lucky, when I was trained on Scrum (CSM), one of the last gasps of our freshly-swallowed small software house was to spend on decent Scrum training for the whole team of us (literally, a whole dev team, all of whom became CSMs). This wasn't just a certificate mill, it was from one of the best trainers I've ever met and someone who certainly knew their Scrum - Nigel Baker at AgileBear. This lasted a year or two, before our new lords and masters (who had a classic case of Failed Scrum, up at Head Office) outsourced the lot to Bulgaria. Shame, that was certainly the best run and most efficient software dev shop I've ever worked in, and one of the best I've ever heard of.

My beef with Scrum (and again, this is something that won't stick in the article here) is that competent Scrum is an efficient production process, but it also has poorly understood weaknesses that have a tendency to produce poor architectures. A lot of major architectural decision making is being made implicitly during the Sprint planning, and many choices are made by teams or pairs working on not-obviously critical tasks within that Sprint. Often major decisions are made in passing, rather than being pulled out and studied carefully by the experienced team members or the overall architect.

Andy, have you tried other valuable practices (e.g. a design workshop, a designated architect, an architecture document) beyond Scrum+XP, which are literally not architecture focused? Sprint planning is mainly a project management practice, not enough and a ideal venue for discussing detailed designs and techniques for complex system architectures. Scrum can not be used alone. As a compact framework, it's devised deliberately to exclude almost all the engineering practices. Some see this as a weakness, some as a merit. However, coping with architectures implicitly is often risky, and it's all well and justified to include and apply necessary practices to mitigate architectural risks, which conforms well to Scrum's inspect-and-adapt spirit. Softzen (talk) 09:56, 17 January 2014 (UTC)

Lots of practices can fix problems that you know are there and need addressing. The risk is when there are unanticipated problems, so that no-one is taking the steps to resolve them specifically. This is a problem for Scrum for a couple of reasons: firstly the sheer speed of a Sprint. Team members are given time-pressured tasks to complete, so they will work primarily to complete them. Issues outside of a task are not the team member's problem (the Scrum Master usually encourages this focus). The tasks of other team members are not their issue either. Secondly, the simple speed of progress with Scrum means that anything not on the task board doesn't have time to be looked at. Architects don't have time to scrutinise the team members' output tasks, there are just too many.

As with all problems within a Scrum, everything boils down to that vital task planning step at the start. New Scrum teams just don't realise (because no-one tells them) that tasks can create widespread knock-on consequences beyond the obvious scope of the task. A good task planning needs to anticipate these, pull them out as distinct tasks and make sure they're then managed appropriately. It's not hard to do these, it's just hard to notice that they need to be done. Andy Dingley (talk) 11:28, 17 January 2014 (UTC)

It's common to see Scrum teams make a major platform choice to the wrong answer, and on investigation it turns out to be that Fred had a one day task to implement the date picker dialog, chose RubbishFaces as a UI toolkit to do so because he worked with it once before (it picks dates OK, but it's a resource hog and the free-text editor is broken), then the rest of the team are stuck using RubbishFaces forever because it's impossible to backtrack and change it (Scrum doesn't like backtracking and makes it very difficult: you can't backtrack within a Sprint, and who gets the time budget to backtrack a whole Sprint in a following Sprint?) Andy Dingley (talk) 10:51, 14 January 2014 (UTC)

ScrumMaster

I recently reverted the edits of an anon who was claiming the opposite of this article: http://www.agileconnection.com/article/scrummaster-role-or-title Now that I've found it, I'll let others decide if my revert needs to be reverted or not. Walter Görlitz (talk) 02:44, 21 January 2014 (UTC)

Product Backlog Items Aren't Needs

The section on the Product Backlog refers to backlog items as "requirements" and says a minimum viable product "needs" (all of) them. This is an overstatement; at most, every item in the backlog is thought to have some value to some customer or stakeholder. It is quite common for a product to be successful at the same time that items in the backlog either remain unimplemented or are dropped from the backlog altogether.

Would anyone like to take a crack at rewording the paragraph? 72.61.58.177 (talk) 19:29, 6 March 2014 (UTC)

Product Owner representing stakeholders

On 18 May, user Mvaraujo edited the description of Product Owner to counter the assertion that "the Product Owner represents the stakeholders and is the voice of the customer" with "(note: this shall be incorrect as stakeholder is anyone with action in the project)", citing the Wikipedia entry for Stakeholder (corporate) to support this assertion.

In fact, that Wikipedia entry states that a stakeholder is any "person or organization that has a legitimate interest in a project", not action as they mentioned.

The prime source of reference for anything to do with Scrum should be the Scrum Guide, published by the founders of Scrum (Ken Schwaber and Jeff Sutherland). In this guide, the Product Owner is described thus (my emphasis):

"The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says."

Under this definition, we can clearly see that the intention is that the Product Owner is meant to be the single point of contact between the development team and the rest of the organisation, and hence represent all stakeholders. Davidjcmorris  Talk  23:22, 17 May 2014 (UTC)

merge SCRUM in Marketing Department into this article

Absolutely. SCRUM in Marketing Department is poorly written, doesn't follow MoS. At the very least it should be cleaned-up. Walter Görlitz (talk) 05:40, 17 May 2014 (UTC)

Merge "SCRUM in Marketing Department" into "Scrum (software development)"? At the very least they should both be merged into something like "Scrum (development process)" 130.195.253.6 (talk) 03:38, 4 June 2014 (UTC)

Support - Was just going to AfD the other one when I saw the merge proposal. If you feel like something from that completely unsourced yet text-heavy article can be salvaged to move over here (or, as above, an alternative combined name), more power to you :) --— Rhododendrites ^talk |  01:13, 5 June 2014 (UTC)

Agile project managers

I have moved this clause here for further discussion:

—however, it is possible for scrum teams to work effectively with agile project managers, especially on large-scale programs.

References

What the sources says is "Agile project management divides responsibility among more than one team member. In the case of Scrum, it’s a project's product owner, ScrumMaster and the rest of the team." Which does not support the idea of "agile project managers". On the contrary it supports the idea that traditional project management functions are spread across some or all of the scrum team, rather than being invested in a project manager. -- PBS (talk) 15:23, 29 September 2015 (UTC)

The statement itself is correct, but the source does not appear to support it. Walter Görlitz (talk) 15:34, 29 September 2015 (UTC)

Scrum Master Role

I would like to suggest some modifications to the Scrum Master role...some of the statements that are currently included in this definition represent an opinion that is not necessarily true in all circumstances. Here are my suggested changes:

The statement "In fact, there is no role of project manager in Scrum at all, because none is needed." is not necessarily true in all situations and represents someone's opinion. This statement is NORMALLY true at the team level in Scrum but Scrum is intended to be used as a general framework in many different situations and there are certainly some situations where there might be a need for a project manager. For example, there are many situations where Scrum might be used in large, complex enterprise-level projects that might require some level of project management. I have personally used Scrum as a framework for a government contracting project consisting of three Scrum teams and there certainly was a need for a project manager in that situation. I suggest deleting this statement.

I suggest deleting the last sentence in this section "Practicing Scrum with the addition of a project manager indicates a fundamental misunderstanding of Scrum, and typically results in conflicting responsibilities, unclear authority, and sub-optimal results" for the same reason.

Scrum is intended to be a general framework and the spirit behind it is to take an adaptive approach to adapt the process to each particular process as necessary. I think these two statements that imply that it is NEVER appropriate to use a project manager in a Scrum project are overly prescriptive and not consistent with that spirit. — Preceding unsigned comment added by Chuckcobb3 (talk • contribs) 14:28, 4 October 2014 (UTC)

I deleted many of these sentences because they violated copyright. This deletion also had the side effect of toning down the emphasis that the above commenter was worried about. --Officiallyover (talk) 01:59, 28 October 2014 (UTC)

I also found the diff. I or others very much ought to check other contributions around that time for direct quotes that aren't identified as such. --Officiallyover (talk) 02:15, 28 October 2014 (UTC)

Gender-neutral term for Scrum Master

Is there a common or suggested gender-neutral term for scrum master that would be worth mentioning on this article? Farzaneh (talk) 14:23, 16 September 2015 (UTC)

In my my dialect of English, at least, the word "master" has pretty much totally lost any gender-specific connotations. It never even occured to me until I read your question that some English speakers might find it strange to refer to a woman as a master of something. Burtonlang (talk) 20:49, 2 December 2015 (UTC)

A quick search for sources suggests that related to Scrum it's mostly treated as a gender neutral title (job listings, etc.), however I found some examples of "Scrum Mistress" as well. Most of those were tongue-in-cheek, but not all of them. There are also plenty of examples of people complaining about how dated/cheesy/suggestive "Scrum Master" is, as well. I didn't find any sources that rise to the level of inclusion, though. Grayfell (talk) 00:09, 3 December 2015 (UTC)

Capitalization of Scrum terms

There are many terms in this article to which most authors would give initial capitals, but that over time have been shifted to all lowercase on this Wikipedia page. I recently updated the page, capitalizing the term Scrum, as the eponymous subject, and now feel strongly that all terms specific to Scrum should be capitalized as they are in the Scrum Guide itself, as well as the other leading sources (Scrum inc, Scrum.org, Scrum Alliance, etc.).

• Product Owner
• Development Team
• Scrum Master
• Scrum Team
• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
• Product Backlog
• Sprint Backlog
• Product Backlog Item
• Product Increment

I will make the change and ask that people join a discussion here to resolve how this should be handled. Davidjcmorris  Talk  20:43, 22 July 2016 (UTC)

Following a recent edit to the page to revert the first rounds of capitalization, I refer editors to the Wikipedia Manual of Style section on capitalization: "words and phrases that are consistently capitalized in sources are treated as proper names and capitalized in Wikipedia". Davidjcmorris  Talk  21:32, 22 July 2016 (UTC)

I'm surprised I missed that bit of MOS after all these years. I'll revert my last change to "scrum", at least pending this discussion. I'm not familiar with all the sources to know if the phrases listed are all consistency capitalized; I'll leave the details to others. (It's odd that "agile" seems to have switched to lower-case, AFAIK.) --A D Monroe III (talk) 21:43, 22 July 2016 (UTC)

Thanks for responding so agreeably and promptly. It does appear contradictory. The key difference being that the term agile is an umbrella terms still used primarily as an adjective, whereas Scrum refers to a specific framework, as do the terms within it. The sources I mention are cited in the article itself, the Scrum Guide, Scrum.org, Scrum Inc, and the Scrum Alliance (who all feel some degree of ownership of the framework I would suggest). But then reviewing articles by leading writers in the space also follow suit, viz. Mike Cohn (MountainGoatSoftware.com), Scott Ambler (ambysoft.com), Alistair Cockburn (alistair.cockburn.us), to name but three. Davidjcmorris  Talk  21:53, 22 July 2016 (UTC)

I would quibble with the reasoning that "agile" is used as a generic adjective (if I replaced it with "flexible and responsive", it would have the same technical grammatical meaning, but lose all meaning in the article), but our reasoning doesn't matter. In the sources, it's "agile" and "Scrum"; the sources are all that matters, regardless of any reasons. So be it. --A D Monroe III (talk) 13:24, 24 July 2016 (UTC)

I suppose we have a disagreement between MOS:CAPS and WP:COMMONNAME. The latter usually only applies to article names though. A subsection of the former, MOS:JOBTITLES, makes it clear that common nouns should not be capitalized. That seems to apply here. The change should not have been made and should have waited until the discussed was completed. Walter Görlitz (talk) 14:35, 25 July 2016 (UTC)

I think we're mostly following BRD; we can make fairly bold changes and then discuss, just not contentious changes. Here, I don't think it was obviously contentious beforehand. Sources like to use capitals for their favored subjects; I think it makes them Feel Very Important. This article, which relies on primary sources, is following those sources for Capitals. I tend to think that it makes the article look promotional. Maybe readers will take this as a hint that they shouldn't believe everything they read here. Given the current state of this article, that may be a good thing. Once we use more sources that call it "a scrum" instead of "The Scrum", we can change the capitalization accordingly. --A D Monroe III (talk) 18:55, 26 July 2016 (UTC)

I agree that we don't want to capitalise terms in a vain effort to "feel very important", but we also don't want to put terms in lowercase in reaction to over-capitalisation by others. The terms that User:Davidjcmorris listed all have very specific meanings within the context of the Agile Scrum methodology that are different than the plain English reading of those terms. While the meanings are often quite similar, they are different and capitalisation of the terms serves to make it clear which meaning is meant.

Regarding the discussion of conforming to sources... the volume of sources on its own is not material: authoritative sources should guide capitalisation here. Authors too lazy to press the shift key should not override the authoritative sources that under-gird a WP article's accuracy. Christopher Rath (talk) 21:46, 26 July 2016 (UTC)

Just to be clear, this isn't about how WP should capitalize based on what's Right or Wrong, or even Accurate, however well-reasoned; we follow the sources' way of capitalizing, regardless of any reasoning (even if the reason is laziness). So any very specific meaning claim is meaningless. BTW, according to the sources, it's currently not "Agile Scrum", but "agile Scrum", since agile sources have transitioned away from capitalizing in the past decade, and Scrum sources have not. We follow the sources, even if they don't make sense. --A D Monroe III (talk) 20:02, 27 July 2016 (UTC)

I checked all the article's references that have online content. If you open the references, you will immediately be struck by their rather commercial quality: many of the references exist solely to allow a commercial firm to "hook" into the article. That objection aside, here's what I found: 8 references are to books and I cannot check those. Of the remaining 33 references, 1 uses the term "agile Scrum", 2 use all lowercase for all terms (but they are firms selling their services and probably shouldn't be used as sources), a 1 can't make up its mind and capitalises both ways (probably a sign that the article needs copy editing). All the rest use Agile and/or Scrum (they don't all reference both terms). So, based on the references, there is no question that this article should capitalise both Agile and Scrum. — Preceding unsigned comment added by Crath (talk • contribs) 04:14, 28 July 2016 (UTC)

In our article Agile software development: although originally abbreviated as Agile (with a capital A) this is progressively becoming deprecated, and it uses "agile" except for some proper nouns like "Agile Manifesto". If that's somehow wrong, then our Agile article must be fixed first before we fix it here. --A D Monroe III (talk) 18:49, 28 July 2016 (UTC)

WP:OSE If you want to address the issues at that article, do so there, not here. Don't make its lack of compliance to the capitalization guideline a key argument in why this should not follow the guideline. Ever. Walter Görlitz (talk) 05:51, 29 July 2016 (UTC)

Just to be clear, this actually is about how WP should capitalize based on editing guidelines. We don't follow sources' way of capitalizing. If a band titles their song "The End Of Reason", we capitalize it "The End of Reason". If a publisher prints a book The End Of Religion, The End of Religion is our title. If a film titles itself From Here To Eternity, we title it From Here to Eternity. So sorry, A D Monroe III, we follow a specific set of capitalization rules. Walter Görlitz (talk) 05:11, 28 July 2016 (UTC)

As noted in the first comment here, quoting MOS: words and phrases that are consistently capitalized in sources are treated as proper names and capitalized in Wikipedia. Doesn't that mean we do follow the sources' way of capitalizing? --A D Monroe III (talk) 18:44, 28 July 2016 (UTC)

As noted above, it's not consistently capitalized in source. Let me know when you think you're out of legs to stand on. We'll be in the same place then. Walter Görlitz (talk) 05:51, 29 July 2016 (UTC)

One of the original creators of Scrum wrote it as SCRUM (in error) so some early references have it fully capitalised, and some more recent writers have used all lower case. So, while it is true to say that it is not entirely consistent, I would say that title capitalisation predominates. I have also seen the role Scrum Master written variously as ScrumMaster and Scrum-Master. My understanding is that to be encyclopaedic we don't respond wholesale to the latest trend, we rely on key sources and if any of the variations are notable, then we would call that out too. This would be why the all-caps SCRUM has a specific mention in the article. Davidjcmorris  Talk  06:55, 29 July 2016 (UTC)

vis-a-vis the alleged over-reliance on primary sources; please note that I have counted up and categorised the sources now and would claim that just under half are primary (authors who are involved directly with Scrum in some way), roughly the same being secondary (authors who are writing about the primary sources, impact on current practice, etc), with the balance being tertiary (reputable articles in peer-reviewed journals, etc.). Davidjcmorris  Talk  06:44, 29 July 2016 (UTC)

Just under half being primary is poor -- it should be near none, and should only use primaries to reference speaking in the voice of the primary source, not in WP's voice. The article has gotten better, but still has a long way to go. --A D Monroe III (talk) 18:10, 29 July 2016 (UTC)

• "Agile" is an adjective. There is no 'Agile methodology'. There is an Agile Manifesto, and in that solitary case, it's a proper noun phrase. For anything else though, agile is only ever an adjective. Andy Dingley (talk) 21:05, 28 July 2016 (UTC)

Well, not always. There are uses like "the state of agile", "adopting agile", "focus on agile", etc., with no noun for it to be an adjective of. Besides, if it were just an adjective, some editor could replace every instance of "agile" with "flexible" or some such and claim they've improved the article. Regardless, that's a debate for talk on Agile software development. We should follow what that article uses for "agile", as that article should follow our use of "Scrum" here, all based on sources. --A D Monroe III (talk) 21:57, 28 July 2016 (UTC)

According to Kent Beck, there is no "Agile". There had been a slide towards behaving as if there was, but this was recognised as A Bad Thing a few years ago and should now be actively resisted. I can't find a source for that offhand, but here's one in similar vein https://www.rallydev.com/blog/engineering/agile-capital-vs-agile-lowercase

The problem is that agile (which doesn't exist as an entity, let alone one with a proper name) is deliberately not a thing, not a single thing, and not a commercially ownable or tradeable thing. All there is is a Manifesto, an adjective, criteria as an expression of meeting the Manifesto, and some instances of real concrete methodologies (such as Scrum) which are agile and can rightly attract the adjective. So things can be judged "to be agile" but nothing should be allowed that claims it is Agile. Andy Dingley (talk) 22:23, 28 July 2016 (UTC)

I agree it's agile, but I buy none of those arguments as to why, since they don't agree with how people use it, but so what? Our reasoning matters not -- only sources. Sources used to say Agile, and WP did as well. Some years ago, sources started switching to agile, and WP did as well. Nothing of our logic, grammar, consistency, or doing what we should allow was involved, then or now. But, hey, why not bring this up at the appropriate page? We can't change it here if the main article doesn't. --A D Monroe III (talk) 00:04, 29 July 2016 (UTC)

Why would anybody want to capitalize these words, if even the names of music genres aren't capitalized in the English language? — Preceding unsigned comment added by 212.101.26.186 (talk) 09:56, 10 August 2016 (UTC)

Sprint definition

The word is used here:

Team members individually commit to achieving their team goals, each and every Sprint.

befroe it has been defined.

109.145.108.154 (talk) 19:23, 15 September 2016 (UTC)

It's also discussed without a definition a few bullets later. Do you have a solution to the problem? Walter Görlitz (talk) 06:00, 16 September 2016 (UTC)

< a development team works as a unit to reach a common goal >

(Sarcasm alert) Is this really a new concept? (/Sarcasm off) 109.145.108.154 (talk) 19:35, 15 September 2016 (UTC)

If you've ever worked on a waterfall project, you'd know that it is a new concept. In waterfall, each person is assigned to a specific task and that person continues to work on that task until it is completed at which time that person is assigned another task. In scrum, if a task is not going to be completed within the sprint, others join in to assist to make it happen. Walter Görlitz (talk) 06:00, 16 September 2016 (UTC)

Comparison with alternatives

Somewhere in an article of this length there ought to be some comment as to how this method is claimed to be better than what came before, and whether those claims are achieved in practice. Otherwise people might be forgiven for thinking Scrum is merely the fad du jour.

109.145.108.154 (talk) 19:35, 15 September 2016 (UTC)

Where would you suggest? Walter Görlitz (talk) 06:00, 16 September 2016 (UTC)

Your suggestion is well-intentioned and welcome, but several practical difficulties immediately present themselves to me:

1. If it is too early in the article, readers who are not familiar with Scrum (i.e. typical readers) will not understand the points being made. If it is too late, many readers may never reach it.
2. Comparing it with Waterfall, because there is a wide variation in how Waterfall is actually implemented, risks allegations that "Waterfall projects aren't really like that" and endless no-true-Scotsman arguments about Waterfall
3. Comparing it with both Waterfall and the similar V Method, risks confusion due to there being 3 methodologies to compare, at least one of which will be unfamiliar to most readers
4. In any case, finding reliable sources to reference for the points to be made in this comparison may be difficult. Private sector project postmortems are rarely written up, and public sector projects are rarely written up in sufficient detail, from a front-line software developer's point of view. A lot of this knowledge comes from experience and word of mouth.--greenrd (talk) 18:46, 31 December 2016 (UTC)

Citations

@Mauricio.aiello: We need to discuss the {{citation needed}} templates that you removed. It's my opinion that they should only be removed if a reference is applied or a valid reason, such as, the reference in the next sentence supports this, or it's sufficiently common knowledge. That they were originally applied means that they were not sufficiently common knowledge for at least one editor, so that last option may be a hard sell. Ideally, each removal should be manual, rather than reverting everything at once, and a reason should be supplied for each. I have commented that I won't revert you if you revert, but I will escalate either to WP:ANI or another forum. My promise does not prevent others from reverting you. Walter Görlitz (talk) 05:15, 22 March 2017 (UTC)

@Walter Görlitz: Sorry, my mistake, go ahead with your changes. — Preceding unsigned comment added by Mauricio.aiello (talk • contribs) 20:45, 22 March 2017 (UTC)

Thanks. With that said, the other changes were good. Do you have and additional references for the article? Walter Görlitz (talk) 01:58, 23 March 2017 (UTC)

Repeated and ridiculous over-templating

Per this edit and its restoration the next day, it's overkill and wrong.

First, {{Use mdy dates}} isn't a warning so when I saw that, I knew that JesseRafe wasn't really an experienced editor. It's designed to tell some bots how to apply dates. It's also designed to tell that to editors, but most don't bother to look at it and apply their own formats.

I would argue that {{cleanup-reorganize}} could be valid. Others have suggested similar. See above. However, it is sufficiently well written so that it appears to be a {{manual}}. So only one of those applies. I would be interested in how the article violates WP:NOTHOWTO though.

{{peacock}} isn't really evident. At all. Please demonstrate with phrases that employ peacock terms.

When you look at {{confusing}} and {{technical}} they are essentially saying the same thing. If it's confusing the editor, it may be that the content is too technical. If the editor understand the technical, it's clear it's not too confusing. I understand the topic and it is neither too technical nor confusing. It's also not an {{advert}}, as there's no product to sell. Again, please demonstrate which portions are either confusing, technical or an advert.

I see a lot of ISBN numbers and reliable, WP:SECONDARY sources in the list of 46 references, so which are {{self-published}}? Perhaps directly tagging the suspect references with {{self-published inline|date=May 2024}} instead is in order. The same applies {{unreliable sources}} where using {{unreliable source|date=May 2024}} inline with each suspected reference. I believe they go after the content and before the </ref> tag, but check the documentation to be sure.

Finally, which certain ideas, incidents or controversies have been given {{undue}} emphasis?

Both @Izno: and @William Avery: thanked me for my revert, so I assume they think it was overkill, but I will let them voice their own opinions. Walter Görlitz (talk) 05:33, 20 January 2017 (UTC)

That covers many points with which I agree, very well. I'd just like to follow through with a few observations on why one might be wrongly tempted to add one or two of those tags. Firstly, an important aspect of scrum has been the development of an agreed specialist (and largely metaphorical) vocabulary which can appear technical, confusing, or downright peacockish to the uninitiated, but which forms a set of practical terms of art. The jargon is an essential part of the practice. Unfortunately I can't point to a reliable source for this observation, but I think it triggers some readers. Alongside that, the subject of the article is a methodology, so deals with a way of going about a task, and thus easily attracts accusations of being a "how-to". Lastly, there are some substantial commercial brands in play in this area, just as there are with persona (e.g. Alan Cooper) and structured programming (e.g. Jackson Structured Programming). So one might harbour suspicions regarding reference spam and undue emphasis on approaches favoured by these branded players. However, terms coined by these branded commercial actors have become part of the general jargon, so they cannot be avoided. Incidentally, I imagine the audience for this article are mainly looking for a bluffer's guide, or an overview to supplement training they have had in a specific role; but it should probably also cater for the end user who is puzzled that the erstwhile Development Team Leader now calls himself a Scrum Master, and is outraged that, instead of a bug being raised, his problem has been "added to the backlog". William Avery (talk) 12:31, 20 January 2017 (UTC)

The page right now does look like a how to; even if it is a methodology, the wrong WP:WEIGHT is assigned to that methodology. A lot of the problem, however, is that a lot of what is written down in what we might consider WP:RS about scrum comes from proponents (largely due to the proprietary process barrier making it difficult to compare/contrast between methodologies), so that makes it hard to balance the article correctly. --Izno (talk) 13:02, 20 January 2017 (UTC)

The article as it stands makes me feel queasy, but I can't get a vision of the correct approach. With the commercial/proprietary incentive, proponents publish a ton professionally and there's comparatively little funding and exposure for naysayers. Google turns up personal blogs on why scrum in general is a bad idea, plus more professionally produced material that might be characterised as "why scrum is a bad idea when its done their way, so you ought to do it our way". William Avery (talk) 14:37, 20 January 2017 (UTC)

Yes, I agree that the 10 or so templates added were overkill, though a few of them looked merited. --Izno (talk) 13:02, 20 January 2017 (UTC)

Each of these issue tags in isolation is appropriate. This article is unreadable and doesn't have a lede that explains what it is about and summarizes its many sections. I heard of Scrum because I got unsolicited spam email about it to sell me whatever this product is via hundred dollar seminars. When I googled it, I saw all the sales pitches from various websites and the Wikipedia article. Like the farm animals at the end of Animal Farm, I looked over the sales material, the email I received and the supposedly neutral Wikipedia page and I could not tell the difference. Maybe there's a good faith bias here amongst the many of you as you are adherents to this program or methodology or practice, but that is not what Wikipedia is about.

What caught my eye, instead of just giving up, was the overuse of capital letters for common words, something that I see very often in Wikipedia articles were non-disinterested editors try to make something seem more important or when COI editors are using company-specific language rather than normal English. These are peacocking terms, that somehow being a "Product Owner" is different than being a "product owner" is absurd and fawning to the source rather than being objective and neutral. On top of the use of all this jargon and esoteric Scrum-related phrases, I saw that (as I said in my edit summary) almost every single source has Scrum in its title or URL. How is this objective? It would seem these are not good sources as they are for the product itself and in that fashion both an advert for the product and a manual in how to use it. If that is not the case, then the article has to be convincing otherwise, don't both to explain it to me.

And Walter Görlitz, please discuss the edits, not the editor. I have over a decade of experience on here, and I moved the mdy dates template because it was in brackets next to the primary sources template, and I was just making a good faith effort to move all the previous issue tags into the multi-issues template without memorizing how many their were or double-checking. It's called a mistake; they're something that humans do. JesseRafe (talk) 15:19, 20 January 2017 (UTC)

Jesse Rafe, regarding your comment on the "overuse of capital letters for common words": the whole point of using capital letters is to communicate that these are technical terms that are part of the Scrum methodology. If they were not capitalised then they would have their common meanings, which would not be correct.Christopher Rath (talk) 04:52, 11 February 2017 (UTC)

There were no personal attacks and you did not supply any of the examples I requested. You will have to explain each to prove they're valid. Walter Görlitz (talk) 05:11, 21 January 2017 (UTC)

I did write about an assumption I made as to why you had made some edits, but that was not an attack. If you feel it was an attack and I slighted you, by all means feel free to follow dispute resolution. I am trying to understand why you over-templated the article and makking allowance for the behaviour, not turning the talk page into a battleground. Walter Görlitz (talk) 02:23, 22 January 2017 (UTC)

I've answered your questions with the examples and reasoning you requested and did not claim you made an attack, but said, literally "discuss the edits, not the editor" because you literally discussed the editor. This should not be confusing. The article still reads like spam and this Talk discussion is going nowhere, templates need to be restored. JesseRafe (talk) 16:28, 23 January 2017 (UTC)

Maintenance templates aren't a badge of shame - if you aren't willing to discuss specifics and help resolve the problems, you should not apply them to an article. - MrOllie (talk) 16:33, 23 January 2017 (UTC)

I agree they are not a badge of shame, that is not a logical stance from someone who is removing them without discussion -- that seems like someone who thinks they are a badge of shame. I have discussed the problems, this page is confusing, reads like both a manual and spam for the product, doesn't lay out exactly what it is, has way too many sections, pays deference to the subject in its use of Capital Letters for what are common nouns which makes it read like an advertisement and as weasel words. It's too technical as well as confusing both in its prose and its layout. It needs maintenance. It's tremendously unfair to insinuate I am not willing to discuss specifics. JesseRafe (talk) 16:38, 23 January 2017 (UTC)

• I have protected the article to stop the edit war and to save anyone from being blocked. Please, discuss it here, reach a consensus, and then (and only then) change the article again. If the edit warring continues (from whichever side) after the protection expires, blocks will be the next move. Boing! said Zebedee (talk) 17:27, 23 January 2017 (UTC)

Thanks BSZ. I’m surprised that JesseRafe reverted without further discussion. I honestly have not seen any specific proof to support the claims. Should I create sub-sections so that the claims can be supported with specifics? Walter Görlitz (talk) 05:30, 24 January 2017 (UTC)

That might be an idea - a discussion for each tag separately. Boing! said Zebedee (talk) 09:21, 24 January 2017 (UTC)

Actually, thinking a little more, if a tag is added and reverted, the onus is on the person who wishes to add it to provide justification here on the talk page and seek consensus. So if, for example, someone wants to add an NPOV tag, they should explain here what specifically is NPOV in the article. For the record, I have not read the article and do not intend to - I'm staying clear of the content itself. Boing! said Zebedee (talk) 10:32, 24 January 2017 (UTC)

Right. WP:BRD. That didn't happen. I had to start the dialogue to avoid the edit war. Walter Görlitz (talk) 14:25, 24 January 2017 (UTC)

right, that didn't happen because there was ZERO response to the concerns laid out above. JesseRafe (talk) 14:45, 24 January 2017 (UTC)

Perhaps, but the answer to that should not be to engage in an edit war. What you should instead do is raise one specific problem associated with one specific tag at a time, present the details here on this page so that others know exactly what you think the is problem (what section, what wording, what's wrong with it) and seek a consensus that it is a problem and that it needs fixing or tagging. Boing! said Zebedee (talk) 14:52, 24 January 2017 (UTC)

(response to JesseRafe) You're missing the point. BRD is editor 1 is bold, editor 2 reverts, and editor 1 then discusses. What has happened here is editor 1 was bold, editor 2 reverted, editor 1 revert, editor 2 reverted and started the discussion. As editor 2, I still don't have a clear idea which phases or sections or sources or whatever is a problem. Walter Görlitz (talk) 14:57, 24 January 2017 (UTC)

It's right here in plain English, in this thread... which you've already responded to, do I have to copy and paste or can you scroll up? JesseRafe (talk) 19:21, 10 February 2017 (UTC)

I am also struggling to see what the specific problems are. It looks like your main complaints are that capitalisation is peacocking (I disagree, it is simply a convention); that the description of Scrum in this article sounds very similar to how it is presented by commercial Scrum coaches; and that the sources are biased in favour of Scrum. The second problem might not be a real problem if the commercial Scrum coaches or training websites cited do in fact describe it accurately, which I think is the case - Scrum is primarily a set of instructions, and only secondarily an assertion about how well following those instructions works in practice. The third problem might be an issue; however, I am not aware of many criticisms of Scrum published in reliable sources. We can't include original research or criticisms that appear "below the line" in blog comments, for example. Under my understanding of Wikipedia policies, if (hypothetically) no criticism of a subject exists in reliable sources, it would be OK not to include any criticisms.--greenrd (talk) 23:16, 11 February 2017 (UTC)

I think it may be a case that everyone involved is an experienced adherent and this contributes to the article being incomprehensible to someone that does not use Scrum. The capitalization which you call a convention is something that I see in articles all the time as a form of subject-aggrandizing which always raises red flags for me, and as an avid Wikipedia reader makes me think that everything in an article that has this deferential capitalization paradigm is going to be deferential and fawning to the subject in every other case. I'm not asking for criticism, but that when I looked at the list of refs they were all scrum-based or seemed to be. I don't really care, I was using the tags to hopefully get some disinterested editors' take on this issue rather than just its passionate devotees. I think my point still stands, this article is terrible and uniformative(-able) unless you already know what Scrum is and are just reading things you're familiar with. JesseRafe (talk) 16:09, 12 February 2017 (UTC)

I will make you an offer - in case it's helpful. I have plenty of free time over the next 2 weeks and I would be happy to discuss Scrum with you over a Skype call (or instant messaging or whatever) so that you can understand it better. Then maybe you could suggest specific points in the article that could be improved or rewritten to make it more approachable to outsiders. As it stands, criticism like "the article is terrible and needs to be rewritten", which is what I'm hearing from you, isn't terribly informative. Which is ironic, because you're saying the article isn't very informative, but your criticism itself doesn't come across as very informative.--greenrd (talk) 16:37, 12 February 2017 (UTC)

I just reverted an edit made, as this used a script to automatically convert the capitalised words into sentence case. Unfortunately it led to what I believe to be the unintended corruption caused by the script used. A whole section of the planning topic got moved to the end, which left me unsure what else had been corrupted. This reversion was not against removing the capitalisation. I have a view on that, and am happy with the discussion that has taken place so far here on that. However, the corruption had to be undone and the de-capitalisation was incomplete, as there were still examples of the terms that were capitalised. I reverted the change and posted a comment explaining this to the user's talk page. Although I did that and indicated the reason for the revert in the edit summary, the user simply undid the reversion point me to this discussion. Irrelevant to the point of the reversion. I have now had to revert that once more. Not a step I took lightly. I trust that we can follow due process on this. Davidjcmorris  Talk  07:08, 10 May 2017 (UTC)

Just a comment from an uninvolved third party. Walter's editing history demands a lot of respect, but on this occasion he has made a mistake, and I think he should admit it frankly. If he has used a script that lower-cases the word "I", as it seems he has, then he needs to question why he using a broken tool. It's not my area, but if there isn't an {{UnusualCapitalisation}} template to warn tools and bots not to go changing the capitalisation of an article, then perhaps there should be. Philip Trueman (talk) 07:24, 10 May 2017 (UTC)

OK. I don't know why it happened and it would have been easier to fix the order than to redo the capitalization, but fine, I redid the work. I removed the unusual italicization as well as updated capitalization on the following:

• Daily Scrum
• Development Team
• Product Backlog
• Product Backlog Items
• Product Owner
• Scrum Master
• Scrum Team
• Scrum of Scrums
• Sprint
• Sprint Backlog
• Sprint Planning
• Sprint Retrospective
• Sprint Review

I did not change the capitalization of "Scrum" when it stood by itself. There may be other things that need to have their capitalization revisited. Walter Görlitz (talk) 14:55, 10 May 2017 (UTC)

Thank you. That is better, although there are still quite a few examples of that form of capitalization in place. If we are going to go down that route, then let's do it consistently. There are also some quotations where the errant capitalization should stand, as that is how the author wrote it (unless I am misunderstanding Wikipedia policy in that regard). I'll do some further edits to help with that. I do think this warrants a note in the article itself to point out that the capitalization that people will have seen elsewhere is not repeated in this article as it would challenge the encyclopedic nature. Davidjcmorris  Talk  19:41, 10 May 2017 (UTC)

You may be correct. WP:SIC: "In direct quotations, retain dialectal and archaic spellings, including capitalization (but not archaic glyphs and ligatures, as detailed below)". Feel free to add those capitalizations back, bit don't revert the whole thing. I'm not sure how you would like to add said note. Walter Görlitz (talk) 19:56, 10 May 2017 (UTC)

Done. I have further de-capitalised (e.g. Product Increment) and added a note to explain why. Thanks. Good to work with you. Davidjcmorris  Talk  20:43, 10 May 2017 (UTC)

I saw. Good work, and thanks. Walter Görlitz (talk) 23:54, 11 May 2017 (UTC)

Things to improve

Having seen that JesseRafe opened a discussion on WP:RSN, I had a look at the article. I can't find cause for concern with claims that it too promotional or written with any kind of agenda. I have added a few references to some reliable sources. There's plenty of stuff in the article that needs referencing, but it seems pretty trivial to find those references. There's lots of books and articles from reliable sources that back that stuff up.

Rather than edit warring over which warning templates the article should have, perhaps instead, it'd be better to have the issues laid out here. I'd invite JesseRafe and anybody else to post below so any issues can be productively addressed. —Tom Morris (talk) 14:41, 24 January 2017 (UTC)

Any criticism, drawbacks or problems - just to make this article a bit more objective? Yogurt (talk) 19:10, 10 February 2017 (UTC)

I don't see any advocacy or anything like that in any kind of tone here, but the concept of "Agile" and "Scrum" is something of a cult, and when describing Scrum to software engineers who have never heard of it before, at times I've been asked whether I was joking or whether who ever came up with the process was joking. So there are people out there who see a bit of a religious taint to the process, complete with redefined words and many other aspects of cult behavior. I myself am not convinced that Scrum is actually useful, I don't see that is provides any benefit other than the typical "Waterfall" approach to product development. :) However for purposes of the extant article, I don't see advocacy, religious recruitment, or anything like that. Damotclese (talk) 17:57, 6 June 2017 (UTC)

One unsupported claim could be removed

In the extant text there is the claim From a business perspective, Scrum has many virtues, one of which is that it is designed to yield the best business solutions which is not supported by references or citations, though one could also suggest that the tone here is non NPOV and perhaps contains a hint of advocacy. Instead of saying the best that rhetoric should be toned down some. Perhaps it should say "is designed to yield good business solutions" which is more truthful. Damotclese (talk) 18:28, 6 June 2017 (UTC)

Agree with the suggestion and that citations are still required or perhaps it should be removed. Davidjcmorris  Talk  06:09, 7 June 2017 (UTC)

New Lede

I've written an entirely new lede. It has significantly more details. Power~enwiki (talk) 23:32, 14 July 2017 (UTC)

Rating

Yup, uppercase "High" fixed parsing by assisted script. Widefox; talk 02:14, 2 November 2017 (UTC)

Where's the criticism?

Why doesn't this article approach any of the criticism of the methodology?

Ex: the (somewhat common) criticism that this methodology is usually unintentionally analyzed as infallible: When a scrum project succeeds it is usually regarded a a proof of scrum's success; When a scrum project fails the failure is usually attributed to the people or to only an incomplete implementation of scrum (cherry-picked tips and bits) or to a too-strict implementation of scrum (blindly following scrum without adapting to circumstances).

Two points.

1. We are strongly discouraged from including separate criticism sections, as this is more likely to lead to a polarisation of views and is not encyclopedic. It is far better to distribute alternate views for balance in the right context. For example, if there is a criticism on retrospectives, this is best included in the section on retrospectives. There is some of this, but if you want to add the one you included above, and can provide references, then please go ahead and add it in an appropriate spot.

2. There is also a section on the limitations of Scrum.

18:57, 17 January 2018 (UTC) — Preceding unsigned comment added by Davidjcmorris (talk • contribs) 18:57, 17 January 2018 (UTC)

It would be easy enough to merge the criticism into the article. There are several guidelines that suggest not having one. It should be as well-sourced to reliable sources as the rest of the content in the article. Walter Görlitz (talk) 19:18, 17 January 2018 (UTC)

Capitalization of the name is not a "Key Idea"

This rather lawyerly aside probably should be kept, but should be moved. — Preceding unsigned comment added by 194.39.218.10 (talk) 08:36, 22 November 2018 (UTC)

Original research tag

In the Roles section a user recently made some significant changes in wording; given their dubious track record hopefully someone familiar with the subject or with the time to read the sources can verify or just revert this and remove the tag. 9³ (talk) 08:40, 2 April 2019 (UTC)

Not being an acronym needs a citation?

An anon editor who doesn't want to discuss it has been repeatedly ignoring WP:BRD and tagging the phrase that scrim is not an acronym and it likely arose... I'm not sure what the anon would actually like cited there. The references which he claims to have read, ISBN 978-0-7356-1993-7 and http://www.jeffsutherland.org/oopsla/schwapub.pdf . The second capitalizes scrum but never claims it's an acronym, and I assume that the former capitalizes and does not claim to be an acronym either. At best the section needs {{Original research inline}}, not a CN tag. Walter Görlitz (talk) 23:42, 18 April 2019 (UTC)

Nonsense paragraph

This paragraph doesn't seem to make any sense:

"Ken and Jeff worked together to integrate their ideas into a single framework, Scrum. They tested Scrum and continually improved it, leading to the 1995 paper, the Agile Manifesto [15] in 2001, and the worldwide spread and use of Scrum since 2002."

And the proceeding paragraphs seem to explain it better anyway. — Preceding unsigned comment added by Rkedge (talk • contribs) 17:41, 31 October 2019 (UTC)

After my edit was reverted, I re-read the paragraph a few more times. I finally get the meaning now. The offending bit is this: "... the 1995 paper, the Agile Manifesto in 2001..." I was reading it as a parenthetical and not a list. Rkedge (talk) 19:16, 7 November 2019 (UTC)

Capitalization of "Daily Scrum"?

In the article, section Scrum#Name, it states: However, to maintain an encyclopedic tone, this article uses normal sentence case for these terms (e.g., scrum master, daily scrum) – unless they are recognized marks (such as Certified Scrum Master).

In accordance with this, in the lede sentence track progress and re-plan in 15-minute time-boxed daily meetings, called Daily Scrums, I changed "Daily Scrums" to "daily scrums". Walter Görlitz reverted this, with the comment WP:COMMONNAME as detailed in the name section. As noted, the section appears to contradict this revert. If COMMONNAME applies and supports capitalization (which is not in evidence), then the section first needs to be corrected to allow this revert.

Or am I missing something? --A D Monroe III^(talk) 21:42, 8 January 2020 (UTC)

It's gone back-and-forth and I misread the current comment. I will self-revert. Walter Görlitz (talk) 22:03, 8 January 2020 (UTC)

Okay. My big complaint against "Agile" et al is the appropriation of common nouns as Their own Proper Nouns. How is it supposed to Organize Software Development when it can't even follow Basic Grammar? --A D Monroe III^(talk) 23:19, 9 January 2020 (UTC)

It's not a problem with Agile, per se, but with developers and software engineers in general. They did not specialize in grammar, which is why most of them are in a field that does not require writing in prose. Walter Görlitz (talk) 23:35, 9 January 2020 (UTC)

Scrum as software development

I recognize that the scrum framework is more popular in software development; but given that it wasn't born out of software development, is still used outside of software development, and is not defined as a software development framework in its own documents (see Scrum Guide), then should the title and lead of the article be altered? It seems like it would be relatively simple to define and describe it in the lead, and then mention that it's become associated with software development due to the framework's popularity in that industry. The title could be changed to something like "Scrum (product development)" or "Scrum (agile framework)" (I know these aren't perfect, either, but they're more broad than "software development," which is a very limiting title.) Canute (talk) 14:15, 14 January 2020 (UTC)

Good suggestion. Make a move proposal. Walter Görlitz (talk) 18:11, 14 January 2020 (UTC)

Meta information in the article

Consider:

"...to maintain an encyclopedic tone, this article uses normal sentence case for these terms (e.g., scrum master, daily scrum) — unless they are recognized marks"

Does this meta information belong in the article itself?

--Mortense (talk) 12:43, 16 August 2019 (UTC)

No. And we should follow MOS:CAPS instead. Walter Görlitz (talk) 15:02, 16 August 2019 (UTC)

The terms Scrum Master, Daily Scrum etc. are used as names for roles and events in the framework and are often referred like an individual name like "I am the Product Owner, i own the product." Oliver Emmler, Heidelberg (talk) 06:29, 27 January 2020 (UTC)

No section on the criticism of SCRUM

Sadly and deplorably, a section on SCRUM criticism is missing. I suggest to start one based on, e.g., Aaron Gray's excellent article. Ant 222 (talk) 15:21, 20 March 2020 (UTC)

No, we add criticism inline and do not create separate criticism sections. Wikipedia:Criticism is an essay that details the rationale behind this. If the content of criticism becomes overwhelming, a separate section could be added. Walter Görlitz (talk) 15:36, 20 March 2020 (UTC)

So, in order to incorporate some new criticism I have to find a suitalbe place in the description of SCRUM? Ant 222 (talk) 12:29, 23 March 2020 (UTC)

I have read the article about criticism and withdraw my question. Ant 222 (talk) 12:49, 23 March 2020 (UTC)

Adjustment in Adaptations Section - Add Nexus, another scaling framework

In the Adaptations section, Nexus should be added as it is another framework for scaling Scrum similar to LeSS and Scrum of Scrums, which are both currently included on this page. Below is the description we would like to add and reference links are here:

Nexus is a framework for developing and sustaining scaled product and software delivery initiatives. It uses Scrum as its building block and augments Scrum minimally. Nexus is consistent with Scrum and its parts will be familiar to those who have used Scrum. The difference is that more attention is paid to dependencies and interoperation between Scrum Teams, delivering at least one “Done” Integrated Increment every Sprint. Nexus consists of roles, events, artifacts, and rules that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal. The Nexus Framework was created by Scrum co-creator Ken Schwaber. Lvelecina (talk) 15:34, 22 January 2020 (UTC)

Can someone please review this request? 24.102.255.92 (talk) 15:50, 23 March 2020 (UTC)

It needs reworded. Those first two sentences are awfully close paraphrasings of the Scrum website. —C.Fred (talk) 16:25, 23 March 2020 (UTC)

Sure. Does this work?

Nexus is a framework for enabling Scrum to scale from a single team to many teams working together to deliver a product. The framework was created by Scrum co-creator Ken Schwaber.

24.102.255.92 (talk) 19:58, 30 March 2020 (UTC)Lvelecina (talk) 14:00, 31 March 2020 (UTC)

References

Biased

I am missing a criticisms section.

E.g., why isn't Scrum But (may or may not to be the same as the party line "ScrumBut") and Dark Scrum described here?

--Mortense (talk) 14:52, 23 May 2020 (UTC)

See discussion just above. --A D Monroe III^(talk) 02:32, 24 May 2020 (UTC)

That blog isn't a reliable source. Jeffries blog isn't much more notable. Walter Görlitz (talk) 05:45, 24 May 2020 (UTC)

Definition of "Done" is included in The Scrum Guide, not an extension

While most tools & techniques have been removed from The Scrum Guide over the years, Definition of "Done" is not one of them. It is an intrinsic part of Scrum: without the DoD the idea of the "potentially releasable increment" cannot be sustained. Even if DoD is a verbal agreement or a per se. If an increment is not expected to be released, the transparency of the product development process would be still impacted by the removal of DoD. In contrast, the Definition of "Ready" is not a mandatory part of Scrum, just an arbitrary technique to mark product backlog items whether they are good enough for sprint planning. So that is rightfully listed as an extension. I suggest moving Definition of "Done" from the Extensions section to a subsection of Increment, where it belongs to. --Agile-enthusiast (talk) 03:02, 29 June 2020 (UTC)

If it's part of the guide, then I agree. Walter Görlitz (talk) 17:20, 30 June 2020 (UTC)

SCRUM vs Scrum

The article mentions that it is occasionally written SCRUM, and the source it cites is a post on StackOverflow asserting that they have seen people do that. In that same post, they are corrected and explained that it should be written Scrum. I think it would be better to treat SCRUM as simply a misspelling, and there's no need to call out that sometimes people misspell it in this particular way. — Preceding unsigned comment added by 74.62.98.178 (talk) 18:10, 22 September 2020 (UTC)

Scrum Guide 2020

I made some updates in line with the latest version of the Guide. Mainly removing references to development team and the assumption that the backlog will be estimated. Oradium (talk) 18:16, 28 November 2020 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

• Scrum Agile events.png

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 20:37, 16 March 2022 (UTC)

Criticism has biased wording

The criticism section does not appear to be an unbiased assessment. Instead, it reads as a defense of Scrum. For instance, the opening sentence is:

Scrum has come under fire many times, mainly by those applying concepts poorly yet expecting the same results, or misunderstanding cultural changes that scrum requires

This indicates that much of the criticism is from people who don't understand Scrum. As a result, the remainder of the criticism section may be read as suspect. I'm not sure, but I believe this section needs to be rewritten or a warning added. — Preceding unsigned comment added by Screenmutt (talk • contribs) 14:48, 22 December 2021 (UTC)

@Screenmutt: WP:SOFIXIT. Walter Görlitz (talk) 19:43, 22 December 2021 (UTC)

Indeed, the section seems very pro-Scrum. 137.79.152.241 (talk) 00:33, 2 June 2022 (UTC)

The entire section is lacking when it comes to citation. There are only a few references, and one of them (one of the so-called criticisms) is from a co-founder of Scrum! I would suggest that if you want to make this section less biased, then consider whether the entire section needs to be re-written using only good sources. And by good sources, I mean published criticisms of the Scrum framework, not random blog posts. If we can't do that, then I have to question whether we even need this section. Everything has critics, but not all criticisms are encyclopedic. Canute (talk) 15:43, 2 June 2022 (UTC)

Scrum etymology

This might be of interest: "Scrum is not an acronym. It’s an event in the game of Rugby, where likeminded people get together and politely discuss ownership of a ball. — Ken Schwaber (Google Tech Talks, september ‘06) From this source, on page 3: 20080116-kort-om-scrum.pdf Sauer202 (talk) 12:47, 22 January 2022 (UTC)

I have just done an edit where I removed the ", or SCRUM" from the intro paragraph. I then reverted that change as I saw the paragraph of "Scrum is occasionally seen written in all-capitals, as SCRUM.". The reference note literally links to a stackexchange.com question with the only response being one of "It should not be written as SCRUM" (paraphrased).

In my view Scrum should only ever be written as such - try and find it written as SCRUM by Ken or Jeff or on scrum.org etc. Hashbangdevil (talk) 09:29, 22 September 2022 (UTC)

OK - just seen the article from 2004 where Ken does write it all in caps. Why in that one article? Hashbangdevil (talk) 09:38, 22 September 2022 (UTC)

Hello, I removed the variant SCRUM from the lead, as scrum is not commonly capitalised, so I don't see the need to include that rare variation in the lead. Sauer202 (talk) 08:21, 15 October 2022 (UTC)

Merger proposal

As mentioned by another user on the Talk:Scrum Sprint page, these two pages currently seem to have a large degree of overlap. I therefore propose that Scrum Sprint either be rewitten with another focus, merged into or redirected to Scrum (software development). Sauer202 (talk) 13:15, 26 October 2021 (UTC)

I have withdrawn my merge request. Sprints are not just used in scrum, and deserves its own topic. Sauer202 (talk) 12:44, 22 January 2022 (UTC)

The Scrum sprint article has again been suggested for merging into the scrum article for some time. See Talk:Scrum sprint#Merger proposal for details. Sauer202 (talk) 08:28, 15 October 2022 (UTC)

Agile and SCRUM are not Project managment methodologies

I read the entire Scrum Guide from cover to cover again and there is no opinion anywhere in it that Agile or Scrum are project management methodologies. However, there are many sentences and phrases proving that Scrum is a framework vision of process management, whether it's software development or anything else. The document uses the word Product many times in the sense of Software or something other than software. acc. the authors have completely forgotten that the effect of the production process may be not only a physical Product or a virtual product in the form of Software, but also a Service and e-Service, because manufacturing companies produce Products, and service companies "produce" Services, which is clear from the so-called the concept of process management of the enterprise. At the very beginning, the authors write that Scrum is a Framework for managing the development and maintenance of a comprehensive Product, i.e. the production process.

They go on to write directly that Scrum is a process framework, so the word “Process” still appears many times, not the word „Project”. They further write that Sprints are similar to Projects with a horizon of no more than 1 month (so the conclusion is that Sprints are not mini-projects either). acc. Sprints are simply production cycles, and all of Scrum is a framework for managing the production process. The production process can function independently when it is Ongoing production or it can be part of the Project when the Project needs to produce something. Therefore, Agile and Scrum could be considered as dedicated sub-methodologies dedicated to managing the Product Development Process in Prince2. So Agile, Scrum and Kanban are sub-methodologies to the Prince2 methodology in terms of producing Products (and I would also add Services and e-Services) in the Project. On the other hand, it is totally wrong to consider them as replacement methodologies for project management such as Prince2. So all the propaganda on the Internet on this subject and book publications are at most suitable for the trash, and the GTP chat, if you ask him about it, just mindlessly repeats the same nonsense that he found on the Internet and various databases. So the reality is this:

- Prince2 is a project management methodology,

- PMI is a Library of good practices regarding project management (because it is not a Methodology, as the authors themselves write in the introduction to the PMBook),

- SCRUM, Agile, Kanban are Frameworks or Methodologies for managing production processes (and not any projects).

Thus, in relation to the production of software, the expression "Programming project" and not "Project" can be considered correct. The term Software venture (in Polish “Przedsięwzięcie programistyczne”) has been used for years in many software engineering publications. Unfortunately, such a concept does not exist in English and therefore they translate it into English as Project so according to me It's very confusing because Project is a Project and Process is a Process and they are completely different things. Attempts to combine the Production Process with project management into one methodology ended in failure. The only sensible solution is to recognize agile methodologies as a sub-methodology in the Prince2 methodology dedicated to managing the process of producing Products (or Services or e-Services) in a Project managed in accordance with the Prince2 methodology. Marek Prasoł (talk) 13:30, 7 June 2023 (UTC)

Marek. A very valid point about not a PM methodology. Oradium (talk) 20:06, 7 June 2023 (UTC)