Kanban Time: Why Your Development Hours Matter

So, you think you Kanban?

Kanban boards are superb tools for organising development workflow.

It’s the flexibility that makes Kanban a better method for agile teams than, say, Scrum, which (in it’s simplest form) relies on highly target oriented sprints to develop software in an incremental way. Don’t get me wrong - Scrum is great if you don’t need to worry about interruptions (or if you have staff in place to deal with interruptions), but if you can’t afford to run fully dedicated teams against highly specific goals, Kanban is probably a better option.

At its very core, a Kanban board has three basic states - "To Do", "Doing" and "Done".

For smart business leaders, however, the states read "How much to do?", "Doing for how long?" and "Is it really done?"

PRO tip

If you're using Asana as your Kanban board, the easiest way to import your new Asana tasks and projects into your Toggl Track account is by using these Zaps:

Using these Zaps, you can automatically bring your Asana projects and tasks into Toggl Track & track how much time you're spending on each.

Tracking your time spent on different projects and tasks will help you see the big picture when it comes to project planning and spot potential bottlenecks in the development cycle.

Kanban & metrics (or why time matters)

So why is time so important? For two reasons.

The first reason is a tactical one (yes yes, tactics and strategy are intertwined, but bear with me here) - you need to watch your lead time.

Lead time is basically the time it takes for a ticket or an issue to go from being added to the backlog to being done. The shorter the lead time, the more efficient you are - if you're working off a fixed budget, you'll be more profitable and if you're working for hourly rates, your client will be happy too (well, for obvious reasons).

While not all Kanban teams use time tracking, I would argue the time factor is nonetheless a core part of the Kanban philosophy - though it is not always so overtly stated. A major (and known) benefit of using a Kanban system is its ability to point out bottlenecks in the development process, usually by way of imposing a limit on the number of active tasks a team can have open at any time - if the number of active tasks is too high, the team will have to identify the problem and solve any issues.

But bottlenecks are the last symptom of an organisational issue. Having an accurate overview of your lead times will point to inefficiencies much sooner. Oh and by the way, inefficiencies don't necessarily mean that your developers are too slow - rather, you might find out you've bitten off more than your team can chew and that it's time to look for extra staff to manage the growing workload.

OK, but that's just the time tactics - things get a whole lot more interesting when you start looking at time costs on a strategic level.

The Hidden Cost of "One More Thing"

If you’re charging your client solely by the hour then, well, congrats! Because however long a project takes, you'll at least be compensated for all your hours (though yes, get a reputation for being too slow and expensive and pretty soon you'll be swimming in a very dry client pool, alone).

But that's a story for another time - where strategy gets really interesting, is when you have to work with a budget.

If you’re working off a retainer, you’ll want to have really good estimates in your back pocket - sell your services for too cheap, and it won’t be long until you’re dealing with an angry mob of underpaid and overworked developers, slipping deadlines and bug-riddled deliverables. Coming up with a budget that satisfies both you and your client alone is a science. Add to that the fact that development never goes exactly as planned, and boom - we're in quantum mechanics territory.

So, here's your core problem - how do you account for all the potential unexpectancies when coming up with your price offer?

You might say the answer is “experience”. This is basically correct, with one amendment - it has to be “measured experience".

Any software development project is a sum of many different moving parts. In addition to variations in technical difficulty, you’re also dealing with tasks of varying complexity as well as your different employees and their different work skills and habits. You might even need to bring in extra help midway, in the shape of a freelance developer with a very particular skillset.

The problem is, while you might have “experience” with how long one task or the other should take, or how long one employee or the other takes to complete something, it’s nearly impossible to add it up into an accurate big picture. This is where “business intelligence” comes in.

Successful companies never “wing it” - they act consciously according to a plan based on measurable metrics.

So kill the guesswork. It's not in your business vocabulary anymore.

The only way to have good estimates is to know exactly how long specific tasks have taken to complete in the past. The only way to know how long things take is to track them. Why so?

Because time is a treacherous thing - how we perceive it is highly subjective and depends on many different factors. Imagine, for example, the following scenario. You go to the cinema and see two movies of equal length - one you absolutely love, and the other one so agonizingly dull that makes you wish you were dead. Without knowing their exact runtimes, you would most likely estimate that the film you liked was shorter than the second, boring one.

We don't really have a sense of time - rather, we perceive time through a myriad of external factors. As such, our internal clocks aren't terribly reliable.

The effect can have a catastrophic effect on business decisions, as lost minutes here and there slowly add up to horribly distorted data and grossly miscalculated estimates.

In the worst case scenario, these estimates turn into "official statistics".

Shudder

We've managed to build some impressive reporting, exporting and integration features into Toggl Track - if you want to learn about how these can work for software teams, hit that neat little CTA button after the jump.

For now, let's spell out what you get from tracking time on a strategic level. Namely this - having good business intelligence means you can walk into a meeting with a new potential client with a very clear understanding of how much your time costs, and how much of your precious time the new client will be asking for.

Chances are they will say something like “yeah, and I guess if we have some suggestions you can make some changes later?”

Now, there’s nothing wrong with that question - for agile teams, development is about constant cooperation and feedback. But when you’re armed with accurate time tracking data about exactly how long different kinds of development work takes for your team, you’ll be in a much better position to judge how your client’s requests and ideas match the offer on the table.

Also, you’ll be in a much better position when (re)negotiating fees - it’s hard to argue with an actual minute-by-minute report of your work. We’ve also seen a few cases of people sending out regular Toggl Track reports as a preemptive strike (you know, to avoid that pesky “how hard can it be?” question).

Just make sure you’re tracking time with discipline - but also, with respect towards your team. Your developers must know that time tracking isn't used for penalizing them for their inevitably varying work methods, but that it serves a more strategic purpose.

Remember that time tracking isn't about putting people in boxes - it's about knowing the boxes you work with.