Scrum Guide
The Scrum Guide describes the Scrum process and framework and how it applies to software development. It contains the base minimum of what must be done and, sort of, how in order to follow this methodology. Scum is the process in which developers implement increments of value from work defined by a product owner, and it all happens inside a sprint.
The Scrum Team is made out of developers, people that plan a sprint and commit to delivering the work as one or multiple increments of value adhering to the definition of done, instilling quality and keeping each member accountable as professionals.
There can be only one Product Owner in a team, they are responsible with defining work, through backlog items (such as tickets or issues), and prioritizing them.
Finally, the Scrum Master is responsible that everyone adheres to the Scrum Guide, coaches people about Scrum and, if need be, takes an active role in unblocking people that are waiting for various tasks to get done.
A sprint is a length of time (1, 2,3 or even 4 weeks) where a number of events take place and certain work is delivered as one or multiple increments of value. Generally, each ticket, issue or work backlog item describes enough work for an increment of value making each valuable on its own.
Sprint Planning is the first event and happens at the beginning of a sprint. In this meeting, the Product Owner ensures that everyone is ready to discuss, plan and commit to the most important work backlog items. Once the work has been committed to, the Sprint Scope does not change unless it is agreed by everyone.
As the sprint progresses, each day there is the Daily Scrum in which each team member describe their progress, what they plan to do and whether they have any impediments or questions. The meeting is generally short (about 15 minutes) and is meant to take the pulse of the Sprint.
The Sprint Review happens at the end of a Sprint and it is meant to showcase the increment(s) of value implemented in the respective Sprint. This is where feedback can be provided about what has been done, how this affects the Product and whether changes need to be made with regards to it.
The Sprint Retrospective is the final event in the Sprint where the team reflects on what was done and how it was done. What went good, what didn’t go so good and what can be improved are the usual questions. If there are actions that need to be taken, they are usually assigned to different people (usually one person per action).
At all points there is an emphasis on transparency. People know what is being done and why, they can always get more information if they need to. This allows for inspections (or reviews) to take place which allows team members to provide feedback or look into different aspects.
This further builds up towards adaptation. All the information is available and can be inspected allowing the team to determine whether they need to make changes, during the sprint and not after it was completed, to adjust their efforts towards the Product Goal.
The entire framework is built on a number of core values. More can be added, these are the ones that are mandatory: commitment, focus, openness, respect, and courage.
The Scrum Guide (the 2020 edition) has been written by Ken Schwaber and Jeff Sutherland. It is freely available, in multiple languages, as an ebook (PDF) at scrumguides.org - downloads.