Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

My title sums up my question pretty well. We're investigating whether we can use a Kanban-based system to manage and track some internal projects and one of our requirements is to track time spent on activities. This will allow us to collect stats on engineering cost.

Is anyone doing this and if so, how?

share|improve this question
    
Can you let us know which (if any) systems you already have in place for time-tracking or for PM more generally? –  Willl Oct 19 '12 at 14:09
    
At the end of each month, our developers simply provide a breakdown of how many hours they spent on each product and category, e.g. new features, bug fixing, tech support, meetings. We're not doing this for performance improvement, productivity, kaizen, etc. Instead, the numbers are used to analyze financials. e.g. are we charging enough for a certain product's maintenance based on income and costs. –  Brian Leach Oct 20 '12 at 11:17
add comment

6 Answers

up vote 11 down vote accepted

TL;DR

Don't think "time tracking." Think "cycle time" instead.

Kanban Should Measure Cycle Time

Generally, Kanban is not about measuring "activities" at a granular level; it is about measuring cycle time for a pull through the entire system. There is legitimate debate about whether this time should include lead time (e.g. time spent in the ice box) or just time from "started" to "done."

Some examples of how lead and cycle times can be measured are:

but there may certainly be better explanations out there. The the general idea, though, is that you care about how long it takes and average batch to move from from initialization to a delivered state--regardless of how you choose to measure that.

Don't Micro-Manage

The important thing in Kanban is that you are not measuring sub-tasks or work products belows the level of the user story. In other words, if a user story is "embiggen the quux" then it doesn't matter how long it takes to order the quux components, perform the embiggening, or update the quux documentation--unless those are explicit queues in your Kanban process, of course.

With Kanban, the question you're asking is "how long does it normally take for a standard-sized story to move through the entire queue and across all defined processes for that queue?" You then use kaizen to eliminate waste and reduce cycle time to the maximum extent practical, rather than optimizing individual tasks.

When you ask how to track time spent on specific activities, you're trying to optimize parts of a task. This is wrong. Consider the following quote:

To optimize the whole, you must sub-optimize the parts...First, model the process by breaking it down into between five and nine sub-processes. Visualize each sub-process as an input hopper that sits on top of a black box. Inputs to the queue are dumped on top of the input hopper where they wait their turn. When the black box is ready to process the next item it grabs an input from the bottom of the stack, does whatever it does, and shoves it onto the top of the input hopper of the next sub-process.

Lewis, Bob (2012-01-23). Keep the Joint Running: A Manifesto for 21st Century Information Technology (pp. 31-38). IS Survivor Publishing. Kindle Edition.

All you (should) care about is the overall efficiency of the entire process chain, not the individual sub-processes. That doesn't mean waste can't exist in a sub-process, but you should spend zero time on that level of analysis until and unless it is negatively impacting the cycle time of your macro-process.

share|improve this answer
    
Kanban should arguably measure the flow of value, not cycle time. Scrum is about cycle time, Kanban is about flow. –  Andrew Clear Feb 11 '13 at 5:35
add comment

Disclaimer: I'm the author of Breeze.

I had a similar problem where I internally use Kanban for software development but still needed somehow to bill clients based on estimates and actual work done. So, being a developer, I made a simple tool called Breeze. It's basically a Kanban board with time tracking and reports. Initially I called it Trello and Basecamp hybrid with time tracking and reporting.

Basically you can add estimates and log work (also includes timer) for every card and you can then generate report based on that.

In an ideal world I would like to drop the tracking and use pure agile development but it is not possible if you are primarily doing freelance development. Also it really depends on the client, if they insist on Gantt charts then you are stuck.

share|improve this answer
    
I'll try it out. It looks very nice at first glance. Thanks! –  Brian Leach Oct 30 '12 at 21:30
add comment

You can achieve this using JIRA (which will manage your issues/bugs/backlog) and Greenhopper (which will handle the Kanban side of it). Devs (or PMs) can log work on the issues that they're working on but, as others have mentioned, it might not be quite right in a Kanban context.

We use it in Scrum, where it's helpful for calculating burndown and velocity, but I should emphasize that, for us, it's just about helping us to improve our estimation and not overloading our sprints rather than for performance management. In my opinion, performance management is much more complex than just the measurement of hours/days a person has logged against a particular task.

share|improve this answer
add comment

My advice is to use whatever time tracking system you currently have rather than add unnecessary bells/whistles to Kanban because:

  • It will cost you less in terms of time, effort, training and dollars.
  • It will avoid giving people one less thing to complain about when you implement Kanban, so acceptance of this change will be easier.
  • It will avoid trying to graft on bells/whistles onto Kanban that at the end of the day may not work as well as your current system.

If you don't have a time tracking system already in place then I suggest that you get a good one that your accounting and HR teams can work with rather than try to graft something onto Kanban boards. The fact that you're asking if this can be done says to me that it isn't obvious that it can be done which means you should think twice about whether or not it should be done.

share|improve this answer
add comment

I concur with codegnome's answer above. Kanban is about outcomes, what the team delivers in terms of throughput and how fast they do this, measured as cycle time.

You could use this to support your financial analysis by asking 'Of our team's throughput, how much of that is bug fixes for product X, how much of it is new features for product X, new features for product Y etc?' and then charging your customer accordingly.

I would urge you to think in these terms rather than measuring developer activity as such measurements do not come for free, they are an imposition on the team and as such can end up being incorrectly recorded and so less than useful.

share|improve this answer
add comment

Disclaimer: I am related to Eylean board development

One more tool is Eylean Board - it is virtual board which offer both scrum and kanban tools. You can customize it anyway you like through a simple GUI. I have to say the board looks pretty nice and is very fluent with drag and drop everywhere. And of course it has cycle and lead time reports. One thing is that Eylean must be installed on client machine it is not a web app.

share|improve this answer
1  
Hi Vidas, welcome to PMSE! Would you mind sharing your experiences with this tool and how did you get to know it? Also, in case you have any relationship to its development, worth to make a disclosure in your answer referring to it. Cheers! –  Tiago Cardoso Feb 8 '13 at 16:50
    
Hello, yes I am involved in Eylean board evelopment as a software engineer. Sorry for not mentioning this. Will fix this. –  Vidas Vasiliauskas Feb 13 '13 at 10:15
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.