Talk:Scrum (software development)

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

Confusing timeline

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

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

Object Oriented

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

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

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

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

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

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)

Talk:Scrum (management)

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.--JEF 21:40, 10 June 2007 (UTC)

Merge with Scrum (development)

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

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

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

Advantages and Disadvantages

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

Inaccurate Link - please correct

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

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

thanks, Deborah Hartmann deborah.hartmann.net

NPOV and Cleanup tags

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

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

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

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

I've wrote down a few known (or alleged) disadvantages, so that there are now less reason for NPOV tag. -Humu

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.