How can I make sure that planned work isn't over capacity, per person?

Question

I currently manage a team of 1 backend developers and 2 frontend developers. We usually split tasks into backend and frontend subtasks.

Before committing to a scope for an iteration, we assign and estimate the subtasks. Then we make sure that every developer's sum of estimates is less than the length of iteration (20 days). It's important to plan per person, not for the whole team, because otherwise we risk overloading the single backend developer.

This is a manual process at the moment, where we go through the ticket tracker and sum all the estimates. I'd like to find a better solution that would make it easier. Ideally, I'd like to quickly see whether a developer has more tasks assigned to them than they can fit in an iteration.

I tried looking into Jira, but it doesn't seem to provide such planning capbilities. It allows planning for the whole team, but not per person. (Version Workload Report comes close, but it doesn't allow any filtering, so in a larger team it would become very crowded).

1. How can I quickly estimate work per person planned for an iteration?
2. Am I missing something, and solving the wrong problem?

Answer 1

How can I quickly estimate work per person planned for an iteration?

I suppose the answer to this question is what you're doing now: you are quickly estimating work per person. And it's not working as you want it to.

What you really want is a most precise estimate you can get, and there is no tool for that because you're dealing with humans who can make mistakes, get busy with random things, get tired, get sick, quit the job, or even die.

Even putting the human factor aside, there are always some random tasks which can appear during a sprint, and they will take more time even if you estimated known tasks precisely.

Am I missing something, and solving the wrong problem?

I think it's a matter of software lifecycle paradigm choice.

• If some tasks don't fit into a sprint, you can just defer them to a next sprint. If it has to take that long, it will take that long.

• You can get rid of your arbitrary 20 days time frame and just release whenever everything you want to release is complete. It's the features that are important, not the fact that they fit in 20 days, right?

• You can put fewer tasks into a sprint. For example, plan only 70% of what you have estimated. You can spend the spare time improving quality and dealing with technical debt.

• Even if you are forced (by your clients) to have estimates, you can explain to them that shit happens, and sometimes it takes longer.

Giving yourself a chance to make some non-fatal, predictable mistakes creates a better working environment where developers feel safe. As a developer, I know how much better it is to not have a deadline: the work still takes the same time (because it has to, you know), but I feel less stressed and produce better code as a result.