Design Capacity Planning

Capacity planning aims to have the right resources available when needed. Resources could mean individuals with the right skills, and time available to add another project.

Why do we need capacity planning at Scaler?

Understand how much you can take as a pod

• At the time of sprint kickoff and retrospective, understand how much you can take up in terms of tasks with story points assessment, keep space for research tasks, buffer ad-hoc duties, and so on.
• Basis the ongoing initiatives, Plan the distribution of hands-on tasks and research tasks.
• We’ve already added time spent on calls and discussions along with strategic planning. It might come in handy with all the things planned upfront.

Efficiency test

• Once you have a clear understanding of how much are the MDIs (Must Deliver Initiatives) in terms of story points, you can assess how your pod is working. You won’t have to take a guess when prioritizing some tasks over others.

Individual performance assessment

• This helps each pod lead understand how efficiently each individual in the team is working. Say, each day has 2 story points. With 10 working days in each sprint, we have 20 story points for each individual. By the end of the sprint, you’ll be able to check if this person was able to take up as many story points as you expected and how was the quality of that work delivered.
• Might help us to give more constructive feedback and work alongside tech more aggressively on timelines with a calculated approach.

Cross-functional resource sharing

• In case your pod is extra on resources (more story points available than the product initiatives), we’ll be able to shuffle resources with a much better clarity and vice versa help those who are low on resources for the time being. This way, we’ll be able to make the best out of the limited resources we have.

Visibility on a Higher Level for Principals/Leadership

• Principals/Leadership have a really small part in planning the sprint and focus more on the impact analysis of each pod. This limits access to individual resource mapping. With this model, Leads would be able to share the high-level view in a well-quantified manner, helping shuffle/manage/align/distribute resources really well for leadership.
• In case of new initiatives (such as UG and other special projects) where we might have to bring the best out of the existing resources to make things work, each pod lead will be able to share the insights of their team without a lot of stress doing retrospectives.
• While scoping new initiatives without disturbing the existing product verticals, give us a better understanding.

Understand the Local vs Global Maxima

Local maxima = the maximum amount of growth in your org or company. Growth can be defined however one wants.

But there are a lot of factors at play in a company: Your growth or lack of it can be due to leadership changes, random reorgs, local politics, optics, and the like.

So let’s start thinking about global maxima too instead of just local. We want all designers to not just optimize for their next role in my company, but also benchmark themselves globally. That’s why we are setting up this model to do a retrospective on our work efficiency and management strategy.

We are learning alongside you all so feel free to help us with your thoughts!

Instructions for this capacity doc

On the top of the sheet, there’s a table that defines the industry standard on how the design team should be distributed in terms of their day-to-day work.

Bandwidth Allocation

Now, this has to be defined basis of the product vertical. Considering the paid product are more connected to users and have to be user-centric that includes a lot of research and analytics. Bandwidth for such initiatives is kept at 35% for Paid + Careers and 20% for Growth vertical.

1. In this doc, we are not adding the bandwidth of leadership including the Head/Principal as they’ll be mostly occupied in the high-level strategy calls. If it turns out that the 15% for discussion is not what’s happening as of now, then it’s concerning for us as a team and we should work towards it. More on this later.
2. The total efficiency in this doc is kept at 100% which is not true most of the time as at a given amount of time not all designers are available due to unforeseen situations resulting in planned/unplanned leaves. We are compensating this delta of 10% efficiency with the Principal’s bandwidth for now, which might change as we move forward. Also, Interns’ efficiency is not kept at 100% to balance such cases.
3. This brings us to the hands-on bandwidth that is kept at 50% for Paid + Careers and 65% Growth
4. Now, From the first principle, given the exceptions where sometimes the project requires us to realign this distribution, if we are not following the above, there’s some need to change the way we operate to improve the efficiency of timelines/quality of deliverables.

Pod-level Bandwidth Allocation

Refer — https://docs.google.com/spreadsheets/d/1-T06fkxQB58IG_1wWsGRQ21AmP4ea78ytl5dOSOytgQ/edit#gid=1040430667C

• All ICs are counted at 1 FT while each intern is counted as 0.5 FT. We all firmly believe that our current pool of Interns gives in as much as an FT designer but for the sake of this.
• Everyone who’s working across multiple pods is distributed in bandwidth as well. e.g. If Goutham is working solely on Mentorship alongside Ash who’s working on 4 pods, the total BW for Mentorship is 1 + 0.25 = 1.25. This works the same way for each pod given above.
• Total BW available = Total story points that one pod can pick up in a sprint. This is further distributed in Hands-on design and UXR/Strategy/Discussion
• The last 2 rows marked green are the actual distribution table (pre-filled) basis what might be the average state of that pod for that distribution as compared to the maths we did earlier. It’s fine to be different from what we deduced as long as we are aware of this difference. e.g. CL dedicated a lot of time to research tasks and is currently working on a Dashboard Revamp that includes a lot of strategies work including user research, creating forms, competitive analysis, A/B testing etc.
• Eventually, this sheet is here to help us. Neither tech nor product, Us. As long as we have the visibility on work we are doing and can be reflected easily in terms of story points, we can map out our efforts with outcomes.

Impact Created

With this structure of planning sprints and allocating bandwidth to teams well in advance resulted in reducing the bandwidth leak of almost 45 Story Points each sprint adding to up to save or better utilize 35% of the design team’s bandwidth.