Scrum Team Size For Product Owners
Self-Organization and “Ideal” Size of Scrum Teams
Self-organization is the underlying principle of effective team dynamics as implicated in the Agile Manifesto: “Individuals and interactions over processes and tools”. The framework opportunity is granted to teams to allow themselves to organize and manage their own work in a way that would yield optimal performance for the sprints they will be running. In other words, the foundation of trust and autonomy, constant experimentation, and driving commitments and maximum business value will yield positive restructuring and optimize team dynamics across the period of collaboration.
According to the Scrum Guide by Ken Schwaber and Jeff Sutherland, “the optimal development team size is small enough to remain nimble and large enough to complete significant work within a sprint.” There is no ideal team size, although the Scrum Guide does mention a recommended range of three to nine members of the development team. As such, it is merely a guideline; and when circumstances require such size to go beyond the suggested borders, then it is up to the development team to determine what works for them to reconcile with the dynamic nature of sprint goals and achieve accordingly.
Influencers of Decisions & Value Delivery – An Overview
There are several variables in the team composition and sizing equation that would influence how effective and efficient the teams are in delivering value. Not only do those variables comprise of purely technological or capability in nature, such as technological innovation and expertise, but also contain a blend sociological and psychological attributes. This is asserted by Tom Demarco and Tim Lister in their book, Peopleware, in which their thesis exemplifies the sociological aspect of business then the technological. Similarly, not only are we determining solely the optimal team composition and size to fulfill the project and sprint’s bottom-line objectives, but also directly influencing the business decision-making of other people such as the scrum master, general management, and most especially the product owner who is the usual single authority figure for a software project.
The product owner is ultimately responsible for the management of the Product Backlog; hence, the product owner is heavily reliant on the working nature and capacity of the team in order to formulate proper decisions against stakeholders’ expectations in terms of project’s risk, scope, cost, and schedule.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Who Dictates the Team Size and Composition?
So who dictates the team composition and size? While the general management maintains the overall resource allocation from the organization level, every member of the scrum team is responsible for contributing to the decision pool. For instance, each member of the development team can exert influence by making recommendations on team composition and size. On the other hand, the scrum master contributes by facilitating discussions on project resources, impediments, and process improvements; usually, the scrum master has no authority to execute organizational change but he or she is responsible for making sure the information coming from the team is relayed to appropriate authority figures to drive the needed change.
The product owner is one of those authority figures and critically responsible for the resource budgeting. So the final declaration is done by the product owner assuming the decision is proper and informed based on the influence exerted by the scrum team. There is still a trace of authority, which is not necessarily negative, especially when the decision is derived carefully from the collaborative participation of the entire team.
Velocity and Capacity Planning based on Team Size and Capability
There are typical ways on how the Product Owner can manage the product backlog and negotiate with stakeholders in the context of team size and capability, velocity planning, and capacity planning. While not mutually exclusive, it also anchors on the consistency and maturity of the team as to how the Product Owner will strategize.