Agile is a way of thinking. Scrum is a 'flavour' of Agile. It is a project management framework, not a methodology. It combines Agile thinking with a strong process providing transparency to both the development team, and any business stakeholders. The Agile way of thinking is more aligned with the natural way that the human mind works - we generally test and learn when we're carrying out any activity where there are unknowns that we need to tease out. For example, when deciding to paint a room - we don't paint the whole room and then decide we don't like the colour, we use colour samples to try things out first. When playing sport - we don't repeat the exact same moves/shots every single time, we determine these based on what our opponent is doing/weather conditions/etc. We constantly adapt to inputs we receive from our physical environment, rather than plough on with an inflexible plan regardless.

Scrum describes a self-organising team (a flat hierarchical structure) of usually 6-7 members. It focuses on delivering value to the customer (or user) and determining that it has done so by constantly engaging with the customer via feedback from incrementally delivered working software.

Scrum typically describes a process that helps us in the place of work to plan in small time-boxed periods¹ the next test and learn you want to conduct. Depending on the size of the team, this may involve several or many discreet tasks.

Beware faux-Scrum, or Dark Scrum. This is bad! There are lots of other flavours of bad Scrum practices - cargo cult Agile, fragile, lipstick Agile etc
(and you know what, there are probably an equal or greater number of bad waterfall practices, if anyone cared to look for them - collaboration and Product development is not easy!).

Agile manifesto and principles

Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity - the art of maximising the amount of work not done - is essential.
The best architectures, requirements, and designs emerge from self-organising teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Scrum 'events' (meetings) and 'artifacts' (documents)

Events (these used to be called "Ceremonies"):

Sprint Planning

The first meeting in the Sprint, where the team takes the highest priority items from the product backlog to work on in the Sprint.

Some points to note in Sprint Planning:

understand team availability first;
try to select only those tasks that as a team you KNOW you will complete by the end of the Sprint (if in doubt, err on the side of caution - if anyone in the team does run out of work that they can contribute to, they can always dip back into the Product backlog for an extra task or two);
make certain that everyone in the team is clear what each of the tasks are, such that more than one person could work on them if required;
break a task down into sub-tasks where necessary.
if your team uses estimation, estimate the tickets you bring into the Sprint backlog - for Value and Effort in order to determine Priority.

Daily scrum meeting (Stand up)

A very quick catch up (usually at the start of the day) for the team to synchronise their efforts:

confirm what they worked on yesterday, what they're working on today and what impediments they have encountered.
review the Product Backlog Items on the Kanban board.

This ensures that team members don't duplicate work, encourages collaboration and teases out problems in a timely manner (which the Scrum Master takes as an action to remove).

Sprint Review

An opportunity for the team to invite stakeholders into a room to review the work that the team has done in the Sprint. This helps with getting internal understanding of work completed; advice on future prioritisation and direction based on the work completed in the Sprint; group feedback to inform future decisions; and wider support for any impediments the Scrum Master was unable to remove.

Sprint Retrospective

A crucial meeting for the team to introspect their ways of working, and determine: what went well; what could be improved; and what actions they could take to prevent impediments from getting in their way in the future.

Artifacts:

Product backlog

The full list of prioritised needs for the product. Some of these may begin life as very high level ideas of things that the product should do. Some may be more easily defined from the start. Over time, the closer the team comes to starting work on anything in the product backlog, the more definition needs to be added. What is important is that it is easy from looking at the product backlog to see what are the most valuable next things to work on. The team constantly refine this backlog on a daily basis.

Sprint backlog

A subset of the product backlog that represents a discreet set of tasks that the team commits to achieving in the Sprint. Often grouped into a theme, and something that can easily be made visible to the customer in order to gain feedback. By the end of the Sprint, these completed tasks should form functionality that can be released as a product increment.

Product increment

The first product increment is the Minimal Viable Product (MVP) - i.e. the smallest element of functionality that can be released to the customer to provide them value.

The cadence or 'rhythm' of Scrum

Writing the base user needs for the product
Refining the backlog
Starting the Sprint
Transparency throughout the Sprint
Additional function available to deploy.

User stories

Write your Stories (or Tasks) from the perspective of providing a valuable function for your customers. Consider the degree of detail you need to create at any stage - to begin with, you probably don't need much, but as you get closer to working on the function, you need more. For example: "As a user, I can backup my entire hard drive.". This is a big Story - there are lots of detailed elements that make up this size of Story. This Story may well be too large for the team to complete in one Sprint, so it will need to be split into multiple smaller Stories before it is worked on. It could be split into dozens (or possibly hundreds), including these two: "As a power user, I can specify files or folders to backup based on file size, date created and date modified." and "As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.". I'm sure you could think of any number of others if you took a few moments.

Reference document for writing Stories. Including writing non-functional requirements as Stories.

Use the INVEST mnemonic approach.

Consider using the structure:

As a (type of user - WHO)
I want (goal of the task - WHAT)
So that (reason - WHY)

and when your Story is close to being worked on, include 'Acceptance tests' - scenarios that serve to describe what 'Done' looks like. One structure for this is one associated with Behaviour Driven Development (BDD):

Given (put the system in a known state - NOW)
When (describe the key action - WHAT)
Then (observe outcomes - CHANGE)

¹.normally two weeks - but determined by the longest period of time the team can work independently before senior stakeholders need to have an input, guiding next steps, or feeding back on what the team has achieved.

TIS21 Confluence Space

Brief guide to Agile and Scrum