Allowing work to spill over from one sprint to the next. This happens when the scrum team is not able to finish all the items planned for the current sprint from the product backlog and end up spilling over tasks from current sprint to next.

Honestly, it happens sometimes that the team isn't able to close everything and it's completely fine. However, Scrum Master and the Scrum team should not take a light attitude over failing to finish all the tasks, else Sprints become meaningless. Teams should feel a bit of pressure as the sprint is nearing it's closure, and they should really focus to wrap as much as possible, having low or no spillovers.

In case, if spillovers are happening in every sprint, then the Scrum Master and team should plan next sprint conservatively such that they can definitely finish everything. And if things finish early, one can always add more to the sprint. By doing this, teams would feel positive by crushing down more work and also motivated by closing sprint on a good note and finishing everything.

One of the learnings, that I follow, "under commit and over deliver" than "over commit and under deliver".

Daily Scrum

Daily Scrum is a ceremony where the team meets for 15-20 minutes and each member speaks for not more than 3 minutes on things he/she worked on yesterday, things he/she is going to work on, and any impediments. Scrum Master facilitates this meeting and gives an update too. But Scrum Master does not and should not conduct the meeting by calling out people to speak.

Scrum Master should explicitly explain the purpose of daily scrum, conduct the initial 3-4 scrum calls and then let the team take-over and conduct the meetings themselves. Daily Scrum doesn't need a Scrum Master to call the people and speak, because that way it becomes too directed.

I usually start the daily scrum by calling out loud, "Everyone, let's meet. It's time for Daily Scrum." After a few meetings, I would stop calling out and would just stand silently (with out scrum board) awaiting for the team. During the team, as a Scrum Master, you may need to coach the person into providing more details or politely interrupting someone from going into more details, and bringing them back to the rules and purpose of daily scrum.

Eventually, the team would get self-organized and if any external person joins the Daily Scrum, they will not be able to identify the Scrum Master by just watching the meeting.

Burn Out

As a Scrum Master, it's very important to understand the pulse of the team and that they are delivering at sustainable pace, not being very optimistic. A good Scrum Master will always guard the team to prevent burn outs.

Many teams are optimistic and that optimism carries over into the amount of work they pull into a sprint. Scrum Masters should always be on the lookout and should caution the teams when they seem to be over-committing during sprint planning than they have historically completed in a given sprint. Why? Because even if a team manages to complete the work as planned during the sprint, it runs the risk of entering the next sprint both tired and also overly optimistic about the amount of work it can complete. Such a team might once again commit to more work than it can complete at a sustainable pace. Eventually, the team will burn out trying to work at a pace that is unsustainable. A Scrum Master can guard the team against burn out by allowing the team and giving them time to work on things that they want to chose.

I used to do this, by introducing something called as Blank Sprint or Hackathon Sprint with duration of 1-week. This sprints are introduced after every 6-8 sprints, and we use it for personal development, online course, code refactoring, etc. Having such sprints benefits Product Owner too, by setting some high-level goal and delivering it in 6-8 sprints, followed by a Blank or Hackathon sprint where team can work on their items. So it helps Product Owner to plan better and at the same time keeps team away from burn outs.