Should I remove distraction time from developers' capacity time while giving time estimation?

Question

I am about to give new estimations of a project delivery time, estimating iterations etc..

Besides development, developers spend much time on distractions. By distractions I mean everything(tea, coffee, chats,) not directly related to development and code writing. In this case, developers spend no more than 6 hour on code writing instead of 8. While giving estimations on task completion, developers always give daily estimation, not hourly.

This fact allows them to lengthen the task completion time. I know that a task will take 12 working hours to complete, but in fact it has taken 2 working (16 hours) days.

In this case

1.Should I take hourly estimation in order to be more precise

2.In my project management software, should I write a developer's daily capacity time-6 or 7 hour instead of 8?

I know that distractions are necessary and very vital and I do not argue their existence. The main question is 'Is is right to extract this time while making estimations?'

Answer 1

Saakyan, no human resource is ever 100% productive. Non productive time, including necessary work but not tied to a specific task as well as simple down time, always exist and should exist because of the inherent benefits of rest. The range of productive time you should be using could be as low 50% but likely never higher than 75%. Also, other things that increase duration despite the work hours are dependencies on other people.

When I estimate, I ask for input in both hours, days, and resources, and I ask for multi-point data on all three. I expect a return on a task to look like: 20 to 40 hours, most likely 25; three to 10 days, most likely five; 2 to 4 resources, most likely 3. (I have no idea if my example here works out mathematically; I just made it up as an example.)

When you have this type of probabilistic estimates on all three parameters, you can gauge the level of risk you wish to take as you arrive at your planning values, the single numbers on all three. It becomes more a judgment call based on risk versus a math result. This is precision in a risk-based, uncertain environment. In my example, based on the threats and uncertainty I have, I may end up with using 28 hours, 4 days, and 2 resources as my measurable baseline. So this results in about 50% productive time. Essentially, I am trying to incorporate the aleatory risk involved in those three probability estimates that bang up against each other in a very random way that the D = W/Ute does not allow.

Make sense?

Answer 2

Software development is not like an assembly / production line where we have exactly the same inputs and outputs for every project. Requirements, technology, and team members change. So if it took 12 hours to implement 'search' feature in Project A, may change for Project B (having similar requirements as of A). Developers learn new ways of doing stuff every day. On the other hand, new developers having a different skill level may join the team, so your '12 hours' job may be too big for that person and may require 16 hours to get completed.

100% (8 hours) utilization of humans is a big ask and should not be tried on a prolonged duration. Everyone needs breaks. At the same time there will be meetings, support calls, production issues, etc which will eat up team's time. They do need a context switching time to more from one task to the other. It is a natural requirement and can not be removed (although it can be minimized).

I think it is not a good assumption that by taking estimates in hours would make it precise. An estimate is after all a guess. You can put in more time to improve the accuracy of your estimate but it will not change the fact that it is a guess (although it maybe based on knowledge, past experience, etc.).

Answer 3

I know when I am on the worker bee side of things and am asked to estimate my time on a project I quote as such: 120 hours total - 20 days at 6 hours per day - 30 days at 4 hours per day; this will give the PM or team a range of time to completion. When I am PM on a project that is how I expect my team to report their estimates as well.

Answer 4

Your estimations should ideally include both productive and non productive time as a matter of fact. As a matter of commitment, you can follow the PERT estimation technique i.e.

(Optimistic Time + 4 * Most Likely + Pessimistic Time) / 6

So for example if a task can be technically accomplished in 6 hours and takes 1 or 2 hours of distractions, and 12 hours in the worst case, your estimates should go like: (6 + 4(8) + 12) / 6 = 8.33 hours approx.