Microsoft Guru Eric Brechner discusses measuring "time on task" in his book "Hard Code". The discussion comes up during a section on Agile - Scrum. My guess is that it means "time spent to complete task X", but then he goes on to discuss time on task in terms of percentages by team. So I don't know how to make this logical leap.

In the Microsoft context, what exactly is "time on task"?


The daily stand-up meetings in Scrum are highly organized and collect useful data. The team organizer (Scrum Master) simply asks all the team members what they accomplished since yesterday (and how long it took) [...]


Tracking how long it took is my team's small contribution to Scrum at Microsoft. By adding this information to the burn-down data (how much is left to do), you can produce fantastic cumulative flow diagrams, measure time on task and work in progress, and better estimate team capacity. Typical time on task is around 42% for production teams; 30% for teams focused on communication--like mine--and as much as 60% for co-located feature teams.


2 Answers 2


I think of time-on-task as time I spend directly working on the task. If it doesn't directly advance the state of the project, it's not time-on-task.

  • Surely it is not a measure of the inverse of goofing off? I mean, what else would you be doing? Maybe if you get pulled off to work on another piece or maintain some other software...then you are not on task perhaps? How does this apply to those measurements above? Oct 6, 2011 at 16:59
  • 2
    @P.Brian.Mackey, there is an awful lot of time spent on other things than software development, even in effective teams. Time you spend on meetings, communication of all sorts, reading mails etc. etc. eats up a significant part of your "body time". The 60% figure quoted above is pretty realistic in my experience. Oct 6, 2011 at 17:03
  • People get sidetracked all the time. desktop software upgrades, assisting other team members, administration work, emails etc..etc.. All that stuff has to be done but its very likely not within the scope of your tasks.
    – TygerKrash
    Oct 6, 2011 at 17:04
  • ..what @Péter said.
    – TygerKrash
    Oct 6, 2011 at 17:05
  • @P.Brian: As Peter said. There are a slew of vital tasks that aren't project tasks. Oct 6, 2011 at 17:09

I'm making the assumption that Time on task is Microsofts version of the what we call focus factor, I don't have a reference to confirm, but based on your information I believe it is.

Basically there's no such thing as the perfect man day so often used in estimates. the reality is you'll end up doing any number of other things in your day, conversations, emails,admin and yes, coffee breaks and the occasional off task chat with your team mate.

I picked up the concept from this book which explains it well: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

You can think of it as a measure of how close to the 'ideal man days' your team is actually achieving. It allows you to understand the true 'velocity' of your team. 75% is considered very good.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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