One of (many) challenges that come with technical leadership is estimation and prioritisation. In essence, this boils down to answering either “What’s been done lately” or “When will x be done”.

This sounds straightforward and can be when you only have one or two developments to get done. But then in come a couple of production bugs, some support requests that need assistance, the odd meeting, a quick change which will “only take 2 minutes” and helping out that other developer with a change. Time quickly evaporates for all and it can seem like little planned work gets done.

Tracking planned development

I like to keep things as simple as possible here and use Kanban. Todo, doing and done are all the columns you need to start with and then you can add more if you run into issues. No estimation or task sizing is preferable. Order the todo column by importance, then start at the top.

I find this works better than sprints due to the simplicity of the process. Estimations, task importance, additional stages - these all add extra information, which we ultimately try to process and factor in. With estimations, we turn this into a counting exercise and try to beat last week’s “score”. With additional stages, we try to do more things at once. With task importance, we introduce additional noise on the order we should do things.

I have always found simplicity to win here and there is a very good reason why.

Productivity = doing the right thing

There are many ways to measure how productive a team is. Lines of code changed, number of story points completed, time spent in front of the screen. Stakeholders and customers care about none of those. What matters to them is that the particular problem they are facing is solved, quickly and reliably.

If you can solve these kinds of problems and continue to do so in a timely manner, without breaking everything, you will be viewed as “productive”.

Un-planned work

Of course, it’s not as simple as just implementing all of the shiny new features and ignoring everything else. We have a large amount of other work that needs doing just to keep the lights on.

The trick here is turning unplanned work into planned work. Track all of these tasks, with the time taken if required.

Doing this allows you at the next Kanban review to look at everything achieved and reflect on this with stakeholders. Natural questions will arise here like “Should we be doing X over Y?” or “Can we automate X?”. This is great as now you are both on the same side of the problem instead of opposite sides, e.g. “Why wasn’t X done?”.

Measuring

If you have to measure anything here, I suggest lead time as the metric. As I said earlier “What matters to them is that the particular problem they are facing is solved, quickly and reliably”. Lead time is what they care about ;)