Capacity planning for team with a lot of meetings

Last post 09:15 pm June 17, 2021
by Ian Mitchell
8 replies
Author
Messages
09:30 pm June 15, 2021

I manage a team of designers who have meetings for most of the day (usually around 5 hours). Some of the meetings are working sessions that contribute to getting their work done. Others are passive meetings, or planning discussions, or meetings that contribute to OTHER people's work getting done.

My team does not currently track their capacity because the typical 6 hours of effective work time per day is laughable. Does anyone have thoughts on how to measure capacity on for a team with tons of meetings? And what happens when a new user story comes with new meetings? Does capacity always equal the time available after meetings and personal time is subtracted?

07:59 pm June 16, 2021

I'm a bit confused by your description. Is your team of designers using Scrum? Are the meetings that are working sessions represented by items on the Product Backlog and are they using some kind of technique to forecast how much effort (including working meetings) needed to get the Product Backlog Items to Done? Are the "passive meetings" things that could be replaced by the Scrum events or a non-meeting method?

08:16 pm June 16, 2021

How does the team currently frame and meet its Sprint Goal commitments? If commitments are not being made and honored by the team, what are the consequences of this?

09:11 pm June 16, 2021

Our team is not doing proper scrum, but it's something I want to work towards. Right now we create user stories and tasks, and track their completion dates, but don't estimate hours or points for them. We have an informal "sprint chat" every 2 weeks where we look at the assigned tasks and talk about progress, blockers, and interference.

I really need help in implementing better structure. I believe many team members are overloaded (and they express being overloaded) but I'm finding it challenging to re-prioritize or re-assign work appropriately when I don't know exactly how everyone is allocated and what their capacity is.

As a starting point, I want to determine team capacity, but I'm not sure how to do this when everyone has a ton of meetings in their schedule. Each designer works with multiple PMs on multiple different projects. Their meetings are things like:

1) Bi-weekly sync with each of their feature crews to review designs and discuss upcoming work - sometimes these are working sessions, sometimes they are just discussions

2) Review designs with other stakeholder groups, and designer gets feedback on how they need to change their design (usually there are multiple rounds of review per task)

3) Multiple design crits each week (this is where designers bring their work to other designers to discuss improvements - sometimes a designer just listens, sometimes they give input on other's work, sometimes they show their own work)

4) Shareouts where PM lead showcases metrics and customer feedback on the new design

5) Team meetings - including sprint discussions

I'm having trouble understanding whether these meetings would lower someone's capacity, or whether they need to be included as part of the estimated hours for each task.

09:20 pm June 16, 2021

Everything is very informal - our various PMs assign tasks to designers, and PM sets the completion date. Our designers just say "yes" to everything that gets assigned, and they will work after hours to get it done if they have to. We don't have an issue with not delivering on our commitments, but we do have a problem with people working too much. I need to be able to prioritize work based on capacity to alleviate this.

04:34 pm June 17, 2021

I need to be able to prioritize work based on capacity to alleviate this.

When there is a cultural problem of managers assigning tasks and completion dates to people who say yes to everything, capacity will never be understood. That's the issue to resolve. Team members must first be empowered to pull work to them, and not have it pushed.

05:43 pm June 17, 2021

I second @Ian Mitchell's comment.  Any agile practice you will find is based upon the people doing the work pulling it in when they have capacity.  When you push work upon people, you are setting their capacity and forcing them to comply.  What you want to achieve is a workload that is maintainable over extended periods of time without relying on heroics.  In the case you have described, you not only depend on heroics, you actually expect it. 

To find your true capacity, stop assigning work.  Create a backlog of work that needs to be done.  Order that list so that the items at the top provide the most value to the company.  How you determine that is up to you as there is no "right way" to do it. Then let the individuals pull work into progress as they have the capacity to do so. They should pull the item at the top unless there is a very good reason why they can't. But you need to emphasize to EVERYONE that heroics is not an option. Yes, it may take longer to get some work done but it will become more consistent, make the team less stressed, and make forecasting much easier.  It will not take long for you to understand how much work can be done by the team, not individuals, and that becomes your capacity.

08:30 pm June 17, 2021

Thank you, it's helpful to know how I can change our processes to help alleviate the stress on my team. So, when a team member pulls in a task, and they're logging how many hours was spent on it, do they include their time spent in the bi-weekly sync meetings with the PM (even if those meetings are often higher level, and often not directly related to assessing or reviewing the team member's designs)?

09:15 pm June 17, 2021

So, when a team member pulls in a task, and they're logging how many hours was spent on it, do they include their time spent in the bi-weekly sync meetings with the PM (even if those meetings are often higher level, and often not directly related to assessing or reviewing the team member's designs)?

If it's necessary for planned work to be Done that Sprint, and so made immediately usable, then yes.