Is Scrum an incomplete methodology? Or: Agile needs UML?

It is a fairly common mistake to confuse Scrum with a software development process when in fact it is a framework with which you can use various processes or different techniques to develop, deliver and maintain complex products.

According to the Scrum Guide written by its creators, the definition of Scrum is:

A framework within which people can address and solve complex and adaptive problems, while productive and creatively deliver products with the highest possible value.

Briefly, Scrum employs an iterative and incremental approach to improve predictability and risk control, but it does not define which processes, techniques, tools or technologies should be used.

What happens is that some processes, techniques and tools have become popular to the point that people think they are part of the Scrum, such as: Users, Quandro Kanban and Planning Poker.

Scrum consists of roles, events, artifacts, and rules. The rules integrate the roles, events and artifacts, managing the relationships and interactions between them. The roles defined by scrum are: the Product Owner, the development team and the Scrum Master. The events are: Sprint, Sprint Planning, daily meeting, Sprint Review and Sprint Retrospective. The artifacts are: Product Backlog, Sprint Backlog, Increment.

Thus, to implement Scrum, it is up to the development team to define together with the product stakeholders a development process according to their needs. That's why you won't find definitive answers on how to do requirements surveying, domain modeling, architecture, and Design in Scrum.

For more information, I recommend reading the Scrum Guide .

Scrum is not a methodology for software development but a framework that was born with the purpose of being applied in product development project management.

According to Scrum.org (free translation)

Scrum is a framework for developing, delivering and sustaining complex products. This definition consists of Scrum functions, events, artifacts, and the rules that bind them together.

Scrum is not a process, technique or method definitive. Instead, it is a framework within which you can employ various processes or techniques.Scrum makes clear the relative effectiveness of your product management practices and work techniques, so you can continuously improve your product, team and work environment.

Here you can download an English version of Scrum Guide.

You can watch this video lesson that describes what is the Scrum and its values, pillars, events, roles and artifacts.

Why then is Scrum confused with Agile software development methodologies? Simple, first why people simply do not seek to study the concepts (irony), but mainly, precisely because it delivers rules and tools that marry the concepts and guidelines of Agile methodologies and processes, and therefore it is used in conjunction with, for example: XP or RUP, people confuse it.

Also why methodologies like RUP, at first, do not define all tools for project management but im artifacts and phases of a software development process - have I said that developing software is complex? Look at the supporting Scrum here

When you say:

In the case of Scrum I see continuous improvement (retrospective meetings), proximity to stakeholders (the action of the product owner), iterative development (sprints), prioritization of requirements (planning poker and backlog) and quick response to changes (frequent deliveries, daily meetings and the backlog itself). Also the self-sufficient team.

You are just citing the possibility of incorporating these team management tools into the process. So when you state

But for a software development this is incomplete.

Is correct, so an agile methodology is mixed with Scrum.

Where are the use cases? Scrum got the user stories, but they need refinement.

From experience I understand that every methodology and process must be adapted to the context (team, culture, Company, project complexity etc). When I talk about adaptation I can cite the possibility that a user story can be written as a use case, without demerit. Or that an epic story is a complex use case that explodes into iteration requirement documents, which resolve parts of the use case. In my understanding: user history is "what", use case and its rules is the" how " to describe them. We can expand this to many other artifacts.

Where is domain modeling? Where is the design (project)?

No Scrum? I think it has already given to understand that does not cite this, each complex product (airplane engine, for example) has its specificities and must use the appropriate process tools (domain modeling when Scrum applied to development of software)

Where is the architecture?

I'm just scoring, same context of the answer above, if I were developing a complex product like a smart garment that offers safety and fire resistance, I could certainly apply scrum, to manage the team and deliveries in various interactions, but scrum does not know what deliveries are, in this case, perhaps: scientific literature studies, fabric prototype, results analysis, evaluation of damage, functional prototypes of the product, testing in real situations.

In the case of software: study of the architecture, prototype of the security components, data modeling for each module, etc.

Already in the colon where it states

Implementation and ad hoc design anyone does.

I see people worrying a lot about Agile and little about these things.

I co