Scenario

This question came from one of the organizations I was helping in Agile Coaching in Telecom Industry.  A member from the senior leadership team asked how he can determine the number of teams and team members required for a development work?  I asked him how he would otherwise do it in a conventional development model that is not Scrum.  He responded by saying that they would estimate a ballpark number for all the various efforts that is required, like Design, Development, Test and so on, and calculate staffing.  He also said that they will add contingency depending on the technology, domain and specialization.  He also added that he would ramp-up the team to the peak during development and gradually ramp-down during testing, defect fixing and deployment.  I also asked him if he has requirements prepared and agreed with the users, or he has product ideas?  He responded saying that he has some skeleton requirements that looks like product idea or product features, but those appear to emerge as we progress, hence he is looking at Scrum.

Solution

Suggested not to look at the whole team size or number of teams to begin with.  First to form a team having different functional specialization that he thinks will be required and capable of interacting with the business and share within themselves to understand the product or feature idea, like Business Analysis, Architecture, Design, Development, Test, Deployment, Infrastructure etc.  If some of these team members have other expertise as their secondary or tertiary skills, that is desirable, like Business Analysts have Testing as their Secondary Skill.  Allow this team to work with the Product Owner or Business to elaborate the product/feature idea. Encourage this team to use techniques like Story Mapping. Let the team members look at those from their individual functional specialization – and converge with others within the team – for example, development shall see if they can develop according to the design that is being thought about.  Further gather those feature sets into small logical groups that probably delivers a specific business value – that may ultimately form a release.  Select a couple of these logical feature groups, may be the riskier ones in their view, and decide what is to be built first especially to learn and not to release.  Then allow this team to build the first release or two releases to see how the product/feature idea is implemented.  Review those, collect feedback, revisit and adjust those logical feature groups to prioritize now.  At this point you would have learnt enough as how the initial plan works and delivers value.  With this learning, make any adjustments, that you think you need and decide on adding teams to work on those feature groups that can be developed alongside.