Individual and team problem solving and self-management.
Evolutionary and incremental requirements and development, and adaptive behavior.
Customer participation and steering.
Openness and visibility.
Easily combined with other methods.
Team communication, learning, and value-building.
Team building via the daily Scrum, even if not in common project room.
 Could be viewed as a weakness, strength, or deliberate desirable exclusion, depending on point of view.
Minimal guidance within disciplines other than project management (e.g., programming). That is, Scrum's emphasis is the lifecycle and project management aspects of development, rather than for example software or requirements engineering techniques.
- For example, the Product Owner has the domain knowledge and requirements vision. But, they will describe a function in only brief terms in the Product Backlog. How to transfer and expand this domain knowledge or requirement? Scrum does not address such issues related to workproducts, requirements analysis, and so forth.
Many projects will need some documents. Scrum does not define what these may be, and thus each project may create ones with similar intent, but varying names and content. In other words, no common, standard workproducts that are shareable with common names across projects. This impedes reuse of workproducts and impedes a common workproduct vocabulary in larger organizations.