What is the best way to split up teams on a large project which is implemented using Scrum?

Question

Options

• AGroup by domain expertise.
• BGroup by features being developed,
• CGroup by specialty of the team members.

• A
  5% (2)
• B
  83% (35)
• C
  12% (5)

Explanation

Grouping by features (B) aligns with Scrum's core principle of cross-functional teams - each team owns a vertical slice of the product end-to-end, can deliver independently, and minimizes inter-team dependencies that slow delivery.

Why A is wrong: Grouping by domain expertise creates horizontal silos (e.g., "the database team," "the UI team"), which forces coordination across teams for every feature and contradicts Scrum's self-sufficient team model.

Why C is wrong: Grouping by specialty (e.g., all QA engineers together, all developers together) is the classic "waterfall by another name" trap - it recreates functional departments rather than empowered Scrum teams.

Memory tip: Think "feature team = ship it team." In Scrum, each team should be able to pick up a user story and deliver it from backlog to done without depending on another team - that's only possible if teams are organized around features, not functions or skills.

No community discussion yet for this question.