A hardware test engineer joins the Developers on a home-robot Scrum Team and also happens to hold a formal supervisory title in the company's org chart, with authority to conduct the other Developers' performance reviews. Inside Scrum events like Sprint Planning, how should this person's Developer accountability function?
Select an answer to reveal the explanation.
Short Explanation
Whatever authority someone carries in the org chart, it doesn't come through the door with them into the Scrum Team. Inside Sprint Planning, a Developer is a Developer — one voice among equals deciding together how much to take on and how to get it done. Outside titles don't buy extra weight inside the room.
Full Explanation
The 2020 Scrum Guide's Scrum Team has no sub-teams or hierarchies, and the Developers are collectively self-managing regardless of any external organizational title a given person also holds. A formal supervisory role that exists elsewhere in the company does not translate into deciding authority over the Sprint Backlog, item selection, or task assignment inside Scrum events — those decisions belong to the Developers as a group. Giving that person a deciding vote, unilateral exclusion power, or task-assignment authority all reintroduce the internal hierarchy the Scrum Team definition specifically rules out, just relocated from a manager title to a 'senior Developer' title. This distinction matters most in a mixed-discipline team, like firmware and hardware test engineers working together, where informal seniority can otherwise quietly override self-management. The correct picture is that outside-Scrum reporting relationships and Scrum accountabilities are separate systems, and the Scrum Team's internal decisions run entirely on the second one. A concrete check: watch whether Sprint Backlog decisions get made by discussion among all the Developers or get finalized by one person's say-so — the latter signals the hierarchy has leaked back in.