The Scrum Team is the fundamental unit of Scrum, and it consists of one Scrum Master, one Product Owner and Developers. That one team is accountable for creating a valuable, useful Increment every Sprint, and it is accountable for all product related activities as well, which the Guide lists as stakeholder collaboration, verification, maintenance, operation, experimentation, research and development.
A Scrum Team has one Product Owner, one Scrum Master and 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. The word 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.
The Guide does not address whether the Product Owner or the Scrum Master may also work as a Developer, which means it is not forbidden and the team decides. The accountability each of them holds is unchanged either way.
Why a size of ten or fewer is guidance
The Guide says a Scrum Team is typically ten or fewer people. The word typically is doing real work, because the sentence describes what usually stays cohesive and sets no 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 the team has to keep a shared understanding 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.
Both the floor and the ceiling apply to the whole Scrum Team, so the Product Owner and the Scrum Master are inside the ten. The wrong version counts ten Developers and adds the other two accountabilities on top. It comes from the older editions, which sized a separate Development Team and left those two outside the count.
No sub teams and no hierarchies
The three accountabilities are roles within a single team, so none of them is a layer above the others. 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. The prohibition covers the standing structure, so 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.
The Scrum Team is cross-functional and self-managing
One team with no internal layers has to carry two properties for that to work. Cross-functional means the team has every skill it needs to create value each Sprint without depending on anyone outside it. The property belongs to the team as a whole, 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. Scrum needs both properties 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 never gets to use what it holds.
What the Scrum Team is accountable for
The team is accountable for a valuable, useful Increment every Sprint, and that accountability is collective. The framework assigns no personal 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 Developer ever acquires accountability for the value of a particular Product Backlog item, at Sprint Planning when the item is selected, when somebody picks it up mid Sprint or 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. That accountability concerns what the product becomes as a whole, and the Product Owner discharges it through the content and ordering of the Product Backlog, with no supervision of who built what.
The distinction matters because the wrong version has consequences. Assigning item level value accountability to named people recreates precisely the task ownership the framework removed, and it gives people a reason to argue about attribution when something disappoints. A team scored on who delivered which value stops behaving as one team.
When a Scrum Team grows too large
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 and sharing one Product Goal, one Product Backlog and one Product Owner. Those three belong to the product, so they do not multiply when the teams do.
Each of the resulting teams has its own Scrum Master and its own Developers. The Guide settles neither whether one person may serve more than one team nor how the teams coordinate their work, and that gap is what the scaling frameworks exist to fill.