blog

As a developer in the industry for 8 years, I have had a love-hate relationship with planning. From being a developer who dreaded the idea of looking at a Jira ticket and guessing how much time it would take, I have come full circle to now becoming a team lead who is having that conversation with other developers. I confess, that planning is a dark art. It takes practice to get better.

For better or worse, planning is unavoidable. Any kind of execution needs some preemptive thinking to channel energies in the best manner possible. So I have come to think about planning with more intentionality. I want to get better at it.

Over the years, the model has remained the same, a group of people gather and look at what needs to be done. Work is divided into tasks. Thematically similar work is grouped into one task. Each task has to be carried out with a goal of completion in a fixed period.

The variables that control the nature of planning are the length of the execution, the length to which a task’s goal has been defined, and the nature of capacity at disposal. The more information you gather about a task before its execution, the better your effort estimation gets.

If you define the goal of a task loosely, it leaves a scope of other “work” creeping in. It could be answering user queries or just emptying the inbox. The busyness of these tasks comes with a sense of urgency which subsumes the plan at hand.