EBS in real life , how to handle "Implicit time loss" - FogBugz Knowledge Exchange

EBS in real life , how to handle "Implicit time loss"

2012-03-14T10:27:20Z

I'm searching for a best practice on how to handle implicit timeloss when working on a task.

for example if a developer is working on a Task. now the phone rings and he is asked something that doesn't have anything to do with the task he is currently working on. Now he phones for 5 minutes.

Should this 5 Minutes be added to the spent time on the task he was originally working?

On the one hand I think this would be good because EBS would learn from "daily interruptions". But on the other hand I can't see how long the task really took.

Also when working on a task and now our boss wants spontaneously a meeting talking about the task.

Should this meeting be counted towards the time effort ?

I'd love to hear in which way (bigger picture) this scenarios are handled and what were the up- and downsides of each solution.

Answer by Michael for EBS in real life , how to handle "Implicit time loss"

2012-09-02T14:47:38Z

I'm struggling with this too, as we are a small (2 person) team just starting to use Fogbugz for our project, which is a sideline to our real jobs. So the work on the project is rather irregular (small snippets during the day, a few hours in the evenings, and most weekend days). What I've done is edit my working schedule to be from 7:00am to 9:00pm and set my time spent on the project to 32%. Then I use Edit Timesheet to add intervals of time spent on cases.

Answer by torbengb for EBS in real life , how to handle "Implicit time loss"

2012-09-02T21:07:14Z

The correct thing to do is to keep the clock running on the original task.

Here is Joel explaining why this is the case:
http://www.joelonsoftware.com/items/2007/10/26.html
Search for the term fishing to find the relevant part.

Quote:

In the Monte Carlo simulation, the probability that each estimate will be divided by 0.5 is exactly the same as the probability that [your phone] would interrupt [you] during any given feature. So EBS produces a correct schedule!

In fact, EBS is far more likely to have accurate evidence about these interruptions than even the most timesheet-obsessive developer. Which is exactly why it works so well. Here’s how I explain this to people. When developers get interrupted, they can either

make a big stink about putting the interruption on their timesheet and in their estimates, so management can see just how much time is being wasted on fishing conversation, or

make a big stink about refusing to put it on their timesheet, just letting the feature they were working on slip, because they refuse to pad their estimates which were perfectly correct with stupid conversation about fishing expeditions to which they weren’t even invited,

… and in either case, EBS gives the same, exactly correct results, no matter which type of passive-aggressive developer you have.