The Scrum Team is the fundamental unit of Scrum. It is one Scrum Master, one Product Owner and Developers, and it is accountable for creating a valuable, useful Increment every Sprint. It is also accountable for all product related activities, which the Guide lists as stakeholder collaboration, verification, maintenance, operation, experimentation, research and development.
One Product Owner, one Scrum Master, and the rest Developers
The composition is fixed in a way little else in Scrum is. A Scrum Team has exactly one Product Owner and exactly one Scrum Master, and everybody else on it is a Developer.
Developer is not a job title and says nothing about a person's speciality. It names anyone on the team committed to creating any aspect of a usable Increment each Sprint, so testers, designers, writers, analysts and operations people are all Developers on a Scrum Team.
Whether the Product Owner or the Scrum Master may also work as a Developer is something the Guide does not address, which means it is not forbidden and the team decides. The accountability each of them holds is unchanged either way.
Size, and why ten is guidance rather than a rule
The Guide says a Scrum Team is typically ten or fewer people. That word is doing real work, because the sentence describes what usually stays cohesive rather than setting a limit. A team of eleven has broken no rule.
The reason behind the number is communication cost. Each additional person adds more paths along which a shared understanding has to be kept in step, and past some point the team spends more effort staying aligned than it spends building. The Guide states only the finding, which is that smaller teams communicate better and are more productive.
The guidance works as a floor as well, because a team must be large enough to complete significant work within a Sprint.
No sub teams, no hierarchies
The three accountabilities are roles within a single team rather than layers above it. The Product Owner does not manage the Developers, the Scrum Master manages nobody, and no accountability may direct another's work.
Nor may the team divide itself. A design group that hands work to a build group has recreated the handover a single team exists to remove, and no part of that arrangement can finish anything alone. What is prohibited is the standing structure, since people pairing for a day, or one person leading a piece of work because they know most about it, creates no hierarchy and happens constantly.
Cross-functional and self-managing
Cross-functional means the team has every skill it needs to create value each Sprint without depending on anyone outside it. That is a property of the team and not of any individual, so nobody has to be a generalist for the team to qualify.
Self-managing means the team decides internally who does what, when and how. The two properties are needed together, because a team waiting on an outside specialist cannot choose its own sequence, and a team that holds every skill but is told what to do next has no use for them.
What the team is accountable for
The team is accountable for a valuable, useful Increment every Sprint, and that accountability is collective. The framework assigns no individual ownership of tasks and gives nobody a way to succeed while the team fails. A Sprint in which every Developer finished their items and the Increment is not usable is one the whole team did not deliver.
Who is accountable for the value
The whole Scrum Team is accountable for creating a valuable, useful Increment every Sprint, and that is where accountability for value sits. No individual Developer ever acquires accountability for the value of a particular Product Backlog item, not at Sprint Planning when the item is selected, not when somebody picks it up mid Sprint, and not at any later point. Choosing to work on something is not the same as owning what it turns out to be worth.
The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team, which is a different statement from owning the value of each item. It concerns what the product becomes as a whole, and it is discharged through the content and ordering of the Product Backlog rather than through supervision of who built what.
The distinction matters because the wrong version has consequences. Assigning item level value accountability to individuals recreates precisely the task ownership the framework removed, and it gives people a reason to argue about attribution when something disappoints instead of a reason to help each other finish. A team scored on who delivered which value stops behaving as one team.
When the team is larger than the guidance suggests
Growing past the point of cohesion is a real problem, and adding a layer inside the team is not the answer. The Guide's remedy is to reorganise into multiple cohesive Scrum Teams, each focused on the same product, sharing one Product Goal, one Product Backlog and one Product Owner. Those three describe the product rather than the team, which is why they do not multiply.
Each of the resulting teams has its own Scrum Master and its own Developers. Whether one person may serve more than one team, and how the teams coordinate their work, are not things the Guide settles, and that gap is what the scaling frameworks exist to fill.