Scrum Team Size For Product Owners – Part 2
Sizing the Scrum Team
The degree of complexity of technology – Agile embraces uncertainty by allowing substantial room for it from conceptualization to implementation. Hence, this is reflected in the team’s understanding of the complexity of the technology of the project and how fast they gain familiarity with it. The Product Owner (and management) should select team members from their organizational roster in terms of compatibility and availability for the project. Moreover, Product Owner is responsible for informing stakeholders of the product roadmap (long-term), release plan (short-term, sprint level) and the Sprint Goal agreed upon by the scrum team taking at least the scope, cost, velocity, and capacity into the mix.
Team Maturity
Despite it being difficult to measure both quantitatively and qualitatively, some factors to keep in mind is how mature and cohesive is the team’s dynamics and how these affect the Product Owner’s ultimate decision. The size of the team will relatively increase the complexity of communication as more pathways are established: [(N*(N-1))/2] where N is the number of members. In addition, the scrum teams need to understand what position of the maturity model they lie.
This can be referred in Tuckman’s stages of group development – Forming, Storming, Norming, and Performing – with the Performing reaching the optimal and efficient state of flow. Other psychological influences regardless of team size should be considered as well such as the Ringelmann effect, also known as social loafing, which is a sociological phenomenon describing a member of a team performing relatively worse when working in a group than working alone. Observe that these are not technological factors but sociological and psychological and can affect the performance of the team.
There are common ways on how the Product Owner can manage the product backlog and negotiate with stakeholders in the context of team availability and capability, which are velocity planning and capacity planning. While the two sorts mentioned are not necessarily mutually exclusive, the Product Owner should also, in fact, reinforce his or her planning with the consistency and maturity of the team in strategizing accordingly. In velocity planning and assuming a velocity trend has been established by the development team, the Product Owner will be able to predict how much scope or product backlog items can be prepared on the next sprint backlog in terms of estimated story points. This is effective as long as the velocity is stable across sprints and with a consistent Sprint goal focusing on value delivery. Capacity planning will take into consideration development work disruptions – planned leaves, the tendency for context switching, member availability, meetings or any AFK (away from keyword) non-relevant activities. Stories to be worked upon are planned by man-days and will fill-up to availability limit of the team.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Guiding Product Owners in Practice
It’s preferably better to employ both to address common uncertainties in those two planning approaches, such as the following:
Revolving team members – while ideally this is highly discouraged especially when hiring contractors that only serve a portion of the entire project lifespan or project context-switching team members, such case does happen and can likely compromise the project’s health. Furthermore, the instability of the team composition will yield more overhead to train new-comers to familiarize with the project before being able to deliver value. The large-swing variability of capacity and velocity should be considered and negotiated accordingly with stakeholders.