Specific questions about Scrum in practice

How should we order tasks that are dependent on each other in a sprint? 

The Developers should order and organize the Sprint Backlog so risk to the Sprint Goal is minimized. That's it, although it is a continuous and ongoing process.

Can different teams share the same Scrum Master just like they share the same Product Owner?

There's no rule against it, but just because something is possible does not mean that it is a good idea. Bear in mind that in Scrum shared people are sharing a commitment.

Should we make the sprint shorter so that the sprint planning is scheduled at the usual date (for example every two wednesdays)? What if the day we usually have sprint planning is a day off?

Do the right thing so any dependencies are being managed, including any integration dependencies with other teams. If there are no dependencies, you could start a new Sprint right away.

The sprint backlog should show the current state of the work in a sprint. Should the work outside the project be included to improve transparency?

The work on a Sprint Backlog should provide transparency over the work the Developers need to do to meet their Sprint Goal. Is the work you are describing necessary for this commitment to be met?

1-Basically the P.O(with help of devs)should  order the product backlog considering this dependencies,devs should also consider these dependencies while organizing the sprint backlog.

These dependencies can be shown with maps and arrays.

2-Yes a SM can be in more than one team,even in teams that are working in other products.

3-SPrints should last less than one month,and in the vast majority of time they last 2 weeks.

So in the rare case that it had to be cancelled,start another immediatelly(lets say one of 19 days as an example),so It will last more than the traditional two weeks and will make your calendar come to normality.

4-Sprint backlog can only be selected from the Product backlog,In the product backlog there are items related only to the product,So something that is related to the company but not to the product should not be included,but you have to be aware in the sprint planning that you won´t have this dev for one or two days in the sprint,so your capacity is reduced for this sprint and this have to be considered while selecting what is going to be in the sprint backlog.

errata:Sprints should last at most one month.

How should we order tasks that are dependent on each other in a sprint?

That is something a self-managing, self-organizing group of Developers will figure out on their own.  The way you ask that question makes me think you are trying to organize some kind of chart/visual to show how the work will sequentially be done. That is not part of the Scrum framework at all.  Yes, the work should be visible and transparent but I think you are taking it a bit far.  The work does not need to be chronologically sequenced.  It just needs to be visible to anyone that wants to see it.  Showing what work is in progress vs waiting to start is enough.  Don't over complicate this because it just adds unnecessary work. 

Can different teams share the same Scrum Master...

Sure but is there a good reason for it?  I've been Scrum Master to multiple teams.  But I always started with one, helped them get to a good point where they are self-organizing, self-managing, and delivering incremental value every Sprint.  I ask them if they feel that I could work with another team and be less available for them. Then I can work with another team.  In my opinion, the goal of a Scrum Master is to not be needed often. Before you take on multiple teams, make sure that the one you are working with now is ok with it.  

However, what if a sprint goal becomes obsolete and we have to cancel the sprint?

The Scrum Team discusses what to do and how to make this happen.  There is no "right way" to do this.  It all depends on the specific situation and reasons.  Empiricism still applies. 

Should the work outside the project be included to improve transparency?

The Sprint Backlog is the work needed to reach the Sprint Goal. It is a representation of the value that is being created for the stakeholders during the Sprint timebox. Does any of this "work outside" the Sprint Backlog represent those things?  The Sprint Backlog is not a time reporting system. 

In fact books about Nexus talk more about dependencies in both the product and sprint backlogs,and tools to show this dependencies ,than books about Scrum itself.

But the concepts can be used in a single Scrum either.

It does not make sense to prioritize a "collection of loan installment" if the "loan" itself was not developed,for a single team is obviously easier to manage this dependencies without maps and arrows.

The product owner can prioritize the product backlog in the way he/she wants.

The developers can arrange the sprint backlog in the way they want.

But the SM should advice them about the advantages of taking dependencies in consideration.

A bit late in the comment cycle, but here are a few thoughts. Additionally, some of these items are accountabilities of the Product Owner (PO) or Developers, rather than the Scrum Master. Do not dicated to the Scrum Team as a Scrum Master.

1. The PO is responsible for ordering the Product Backlog (PB) based on value, but dependencies can influence the ordering, especially tasks in Sprint Planning. Unlike predictive project management, Scrum avoids setting fixed dates for individual PB items. Items are typically pulled in order during Sprint Planning, and gaps (leads or lags) are generally avoided unless there's clear value identified by the Team.
2. Definitely, Scrum Masters are not necessarily one-to-one with a team. It depends on availability, team maturity, project complexity, and organisational context.
3. Cancelling a Sprint is a rare and drastic event in Scrum. Only the Product Owner has the authority to cancel a Sprint, usually due to a major change in business direction. While the team may immediately begin planning the next Sprint, it can be valuable to pause, regroup, and align on a new direction, especially if the cancellation was unexpected.
4. The Product Backlog contains items that the Product Owner deems valuable to the product. Personal absences, capacity constraints, and team availability are not backlog items—they should be communicated within the team or noted on the Sprint board or a team calendar.

I want to thank everyone for their insights. Those issues are clearer to me now

Hi Kacper,

Great questions! Here are some practical insights based on Scrum best practices:

1. Ordering dependent tasks in a sprint:
   It’s best to order tasks so that Task 2 (the one that needs to be done first) appears right before Task 1 in the sprint backlog. Leaving space isn’t usually necessary since the backlog is a living artifact that reflects priorities and dependencies. You can also use task blockers or dependency tags in your tool to signal that Task 1 depends on Task 2. This helps the team clearly see and manage the sequence.
2. Sharing a Scrum Master across teams:
   While it’s possible for a Scrum Master to support multiple teams, especially if they are small or mature, it’s important to ensure the Scrum Master can fully dedicate enough time to each team’s needs. Sharing a Product Owner is less common because each team usually requires a dedicated Product Owner to manage the backlog and stakeholder communication effectively.
3. Sprint duration and handling sprint cancellation:
   Sprint durations should generally stay consistent to create a stable rhythm. If a sprint goal becomes obsolete, Scrum allows cancelling the sprint. You should plan the next sprint planning at the regular cadence to maintain consistency. If a usual sprint planning day falls on a holiday, reschedule it close to that day but avoid shifting the whole sprint cadence. This keeps the team’s rhythm predictable.
4. Including work outside the project in the sprint backlog:
   The sprint backlog should primarily reflect work related to the sprint goal. However, for transparency, it can include relevant non-project tasks like training or recruitment, especially if they impact team capacity. Scrum Masters and Product Owners should track their work that affects the team, but not necessarily in the sprint backlog — they can use separate tools or boards for their activities.

Hope this helps you in your PSM I prep and your Scrum journey!

Good luck!