Agile Resource Allocation - How to choose a particular team size?

Please refer to the Scrum Guide, where it explicitly states that the optimal Development Team size is between 3 and 9 members, not 5 - 9.

Regarding the "optimal" team size within that "optimal" range, my suggestion is to select a size, execute a few sprints, and reflect on whether that size is working, or should be increased/decreased based on team and business feedback.

Beg pardon, you're right on with regard to scrum guide suggesting between 3 and 9.

Your suggestion of executing a few sprints and then reassessing team size seems hard to reconcile with the widely recognized concept of stable, long-lived agile teams. However, I can see how this might make sense just in the initial stages of team development (first few months?). I'm curious if there is a rough range for number of sprints you would recommend before fixing the size of the team?  Also, how do you select a size to begin experimenting with?

Are the team able to formulate a Definition of Done for the product, and to plan a forecast of work for the first Sprint? Upon inspection, do they believe they have the optimal composition to continue delivering feature-complete increments?

Thanks for the reply Ian. I believe the answer to those questions would be yes so long as the team is cross-functional. Is it as simple as that though? do we stop adding folks (e.g. perhaps with redundant skill sets) to a team as soon as it's cross-functional? what if time to market on this product is more important than others in the portfolio? should that influence whether the product team has more members than others?

If I'm missing the boat, do you mind indicating what factors you have seen teams take into consideration when inspecting whether they have optimal composition?

Is it as simple as that though? do we stop adding folks (e.g. perhaps with redundant skill sets) to a team as soon as it's cross-functional?

I'd stop adding people as soon as the team reaches the desired level of efficiency. That a team consists of cross-functional members does not per se mean that it has reached it's full potential. Experiment, reflect, adapt. 

what if time to market on this product is more important than others in the portfolio?

More people doesn't equal quicker time to market. More people in your team can lead to more discussion which will limit the optimal flow of value. Putting more people in a Formula 1 pit team doesn't lead to shorter pit stops either. They will be in eachothers way, thus leading to a longer pitstop and ultimately losing the race. 

If I'm missing the boat, do you mind indicating what factors you have seen teams take into consideration when inspecting whether they have optimal composition?

What I usually do with starting teams is first visualize what exact skills are needed to build the MVP and start with that. After the first sprint, take some time in the retrospective to reflect on our presumption that with the current team, we are able to build the desired value in the desired timeframe. If not, what do we need further? Is it more budget/people/teams? Discuss and always be transparant. 

Each team must be able to apply focus, which limits how many people ought to be brought on board. In other words, you wouldn’t add team members only to have them working on separate things.

Potentially multiple teams can draw work from the same Product Backlog, and each can have its own specific focus. They will need to collaborate on integrating their deliverables by observing a shared Sprint Goal, but each team would ideally have all the skills needed to create a feature complete piece of work. That can be a better scaling mechanism than just adding team members to one team. However, the first option is always to try and descale the problem first so it can be handled by an existing feature team and without bringing in more people at all.

Your suggestion of executing a few sprints and then reassessing team size seems hard to reconcile with the widely recognized concept of stable, long-lived agile teams

Don't treat team size like Big Planning Up Front.   Yes, there are inherent benefits to stable teams, but it is a mistaken assumption that there is a "magic" team size or composition that immediately creates a stable, functioning Scrum team.

You need to start somewhere, and then use empiricism to gauge the effectiveness of the team size and composition.   Team stability will hopefully be achieved after many sprints are executed.

Think of it like a recipe.   You have to cook it for a certain time period, at a certain temperature, and perhaps tweak the recipe and recook it a few times before you are happy with the results of the recipe.   You can't double the cooking temperature thinking that it will cut your cooking time in half.   You can try to "copy" another recipe, but if you live in Denver Colorado for example (where the elevation is high), that same recipe will produce a mess.   



Each team situation is unique.   The Scrum Guide offers guidelines for your recipe.   Just get started with something, and then adjust and repeat until you (and the team, and the business, and the customers) are happy with the results.

I agree with what everyone has said about start with something then adjust.  And all of those recommended adjustments must come the team. They are the only ones that can decide what skills are missing. I will even go as far as to say to let the team request a specific individual if they have one in mind.  This usually helps get a better "fit" and cause less disruption to the team.  Unfortunately reality always sets in and there is usually a management decision involved.  But even then, the team will feel that they have had the opportunity to participate in the decision and if the management is actually embracing Scrum, they will do what they can to accommodate the team's requests.

I will also say that those adjustments do not have to be increases.  There could be times that one team no longer needs an individual's skill set because others on the team have grown and are able to do enough of that skill to accomplish the work that they consistently do.  If there is another team needing that skill, let the individual(s) with those skills move.

Yes, long lived consistent team membership is desired and prescribed based on a lot of studies, but in reality that is not always possible.  Be transparent with the needs, inspect the problem, adapt accordingly.

thanks for all the great feedback everyone. very helpful!