In agile, there is a concept called “Capacity”, drilled down further to be in a per sprint cycle – “Sprint Capacity”.
A sprint is a block of time in which you set out to accomplish a particular task, generally 2 – 3 weeks, capacity is the allocation you have to complete a certain amount of work in that time period.
A typical developer, dedicated to one sprint (let’s say it is 2 weeks) might be 5 – 6 hours a day (giving leeway for some non-sprint meetings, bathroom breaks, and other things). From here you are looking at approximately 50 – 60 hours of developer time over the 2 week period (10 days x 5 or 6 hours a day).
What a developer does in this time boils down to their tasks that they have allocated for themselves and here is where it gets tricky.
If a developer fully understands the problem they are trying to solve they probably have a good idea of where that 50 – 60 hours is going to go – they know the problem, they understand it. If they don’t understand the problem, they should not be trying to max out that 50 – 60 hours because they’ll need to allocate some time for “discovery” and thinking about things – all important endeavours.
Managing sprint capacity as a Manager is an onerous task because it takes knowing your team to know when they are overallocated or underallocated per their abilities and what they are working on. Sure you might have a system like JIRA or Azure DevOps that might highlight when someone is overcapacity but that will be all they do. In addition, these tools will not take into account past velocity of the developer (i.e., are they on a streak and hitting stride so getting more done).
All this to say, when thinking about capacity for your team, focus on the most important metric that matters – what are they being distracted with, what are they being pulled off to do, where are they context switching. These are not going to be stored within any application, these are going to be stored with the manager and that’s what’s needed to calculate an accurate Sprint Capacity.
