Much of the early history of Scrum was written on Jeff Sutherland's Scrum Blog almost 20 years ago. This may still be accessible at jeffsutherland.org/scrum but needs to be brought forward to scruminc.com so history is not lost.
Today, many practitioners have no understanding of the origins of Agile which began with organizational patterns and Scrum. The patterns and Scrum work was shared with Kent Beck to start up eXtreme Programming and the Agile Manifesto meeting had the founders of XP and Scrum along with a group of consultants and thought leaders. There were no other widely deployed frameworks at that time with the possible exception of DSDM in Europe which today is largely replaced with Scrum.
This 2003 blog post was cited by Jim Coplien's 2008 presentation on the history of Scrum as organizational patterns, also worth reading.
Jeff Sutherland's Scrum Blog: 11 March 2003
Here are some comments on requirement needs for a Scrum motivated by postings in the scrumdevelopment@yahoogroups.com list. Here, I am talking about product companies. There are parallels for IS internal development.
The Scrum's that I work with deal with changes to the requirements during the sprint iteration. The product manager (as Product Owner) is part of the Scrum for this reason. The development Scrum does not define initial requirements unless they are a product marketing Scrum.
We have always started a development Scrum with some working code. Thus, a Scrum is designed to improve a codebase. The functional specification provided by marketing should be based on running prototypes shown to customers or potential customers who agree that is what they want for the next release. It may be one sprint or several to get to the release.
My current customers are physicians and they don't have time to meet in the daily Scrums, so product marketing physicians have to be their surrogates. Physicians have taught me that a product WILL NOT BE USED, unless it carefully meets their workflow, is extremely responsive, and can be customized quickly whenever it has shortcomings. Since failure is immediate by physician refusal to use the product, it must be close to right the first time and fixed within a month, or you fail and have to go find another customer.
This tight discipline required by the physician environment has made me realize that all projects should be run with this discipline. If they are not, failure may take longer, but the system ultimately does not sell well or get used well. So I think my comments are relevant in other environments. You won't win big unless you do this.
In addition, if product marketing is not clear about customer (or market) needs, neither is senior management. If senior management is not behind a product, priorities will get confused. This will sap focus and resources from the Scrum and reduce the probability of success.
If product marketing can't function, development has to do it. They will not do it as well and they should not treat it as cutting code. They must get out of the office, do market research, and get into the customer's offices or bring the customer to them. They must do sales support and be there when the customer is buying or not buying and understand why or why not. They must give up their development job long enough to define the use cases, get a user interface the customers love and clarify the customer workflow and business logic. When that is done, they can think about coding the product.
In a greenfield project without existing code, I have seen a development Scrum work on a prototype for a week and define it as their code base.
The task then is to refine the code base to better meet customer need. If that is not clear, the programmers should not write a line of code. Every line of code costs money to write and more money to support. It is better for the developers to be surfing than writing code that won't be needed. If they write code that ultimately is not used, the company will be paying for that code for the life of the system, which is typically longer than the developer's professional life. If the developers went surfing instead of writing useless code, they would have fun, and the company would have a less expensive system and fewer headaches to maintain.
When the customer need is clear, write the minimal lines of code to meet the defined need. This is the XP way of working (which was the original Scrum team's practice) and should be the Scrum way of working.
That said, product marketing should be run as a Scrum of Product Owners (now called a Metascrum). I once led a senior management team (CEO, EVP, SVPs, and Product Marketing Directors) as a product marketing Scrum. With one lunch meeting a week they made more product changes and innovations in 6 months than they had made in the five previous years. This Scrum also helped spawn successful internet companies such as Lycos y Altavista, a leading search company before Google existed.
Spanish 
English 
French