Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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"?


First

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) [...]

Then

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.

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
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? –  P.Brian.Mackey Oct 6 '11 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. –  Péter Török Oct 6 '11 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 '11 at 17:04
    
..what @Péter said. –  TygerKrash Oct 6 '11 at 17:05
    
@P.Brian: As Peter said. There are a slew of vital tasks that aren't project tasks. –  Paul Nathan Oct 6 '11 at 17:09
add comment

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.

share|improve this answer
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.