Regardless of how the effort is organized, approached, and executed within the framework, Scrum helps to expose the opportunities for improvement. If/How/When a team decides to use tasks, user stories, and other techniques is at the core of self-organization which is a Scrum requirement.
Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
Take some time to read and understand The Scrum Guide and its history. There are many sources out there providing information as "Scrum" that present common practices as rule; some information is entirely inaccurate. As a framework, Scrum does not prescribe many details; it provides a structure within and upon teams can execute complex work using their choice of tools and processes.
User Stories are a concept from eXtreme Programming. They have lost their original intent and often become traditional requirements. Product Backlog items can be represented in any format with the "As a, I need, So that" User Story or the Job Story formats being common.
The concept and use of a "Scrum Board" is common, yet not a requirement. It comes from kanban in manufacturing. A kanban board is used for tracking progress through many steps in a process in order to locate and address inefficiencies. Continuous Flow Diagrams (CFD) are a common tool to discover such inefficiencies. Within the Scrum framework a Product Backlog item is either 'Done' or not. Ideally only three kanban columns are needed and used: To Do, In Progress, Done. Additional columns may indicate processes that are still based in separate sub-teams1 or not using best practice techniques such as test-first including unit and or acceptance test driven development. CFDs can help identify such opportunities for improvement.
Tasks are another common practice from traditional project management2 where work items were often still somewhat relatively large efforts. The details, tasks, were left to those executing those specific activities within the line item. Creating Product Backlog items that are thin, vertical slices of functionality is often preferred to tasks. Tasks can once again be an indicator of sub-teams.1
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis;
2Project Management being based upon and often still rooted in manufacturing. Thus Scrum's product focus. (Yes, Scrum was based on lessons from Toyata so it's not completely divorced from manufacturing.)
Join me in chat if you are interested in learning more.