Scrum teams and the risk of a member getting sick
Scrum suggests small teams as far as I'm aware. This means that we often have single frontend developer, single backend developer, single QA engineer, etc.
Doesn't it negatively affect the project success? If, for example, a backend developer gets sick, then what should we do as a manager? Should a customer pay for our work as earlier, despite the fact that we can't produce as much value as when the whole team worked together? How should this situation be stated in a contract document?
There are misconceptions around Scrum and team sizes. The first common misconception that I've seen is that Scrum mandates small teams, specifically a Development Team of between 3 and 9 individuals. Scrum contains several concepts that are immutable - "roles, events, artifacts, and rules" - and changing these core concepts would result in something that is not Scrum. The statements that "fewer than three Development Team members" and "having more than nine members" refer to the ranges at which Scrum has been seen to be most optimal. It doesn't mean that Scrum can't be used with a Development Team of one or two or ten or eleven people, but with teams smaller than three or larger than nine, there may be problems where Scrum is either introducing unnecessary overhead and coordination or where the communication is complex and events cannot be completed effectively within their timeboxes.
The key characteristic of a Development Team is that they are cross-functional and have "all the skills as a team necessary to create a product Increment". In addition, Scrum does not recognize titles or sub-teams among Development Team members. Having a "frontend developer", a "backend developer", a "QA engineer", and so on is recognizing titles among members. Consider that someone can have expertise in a particular domain or skill, but the team should strive for distributing the knowledge and the ability to work across all members of the team.
In a situation where the team is reliant on a single individual to provide particular knowledge and skills to deliver, that is something that should be identified as a project risk. As with any risk, it can be avoided, reduced, shared, or retained. The risk can be avoided by increasing the team size to double up on key skills or not taking on work that is too risky. It can be reduced by implementing knowledge sharing, and shorter Sprints may also reduce the chance for unexpected events to occur in the timebox. It can be retained by accepting the risk as it is and moving forward.