Home > Uncategorized > Rounding in reported task implementation time

Rounding in reported task implementation time

There is lots of evidence that people often pick a round number when estimating the time needed to implement a task. Parkinson’s law suggests that reported actual implementation time will often also be a round number, e.g., report 30 minutes for a task that actually took 28 minutes.

If a task is estimated to take 1-hour, what is the distribution of reported implementations times? The analysis in this article uses the SiP task dataset, and similar patterns occur in other datasets.

The plot below shows the number of tasks having a given reported implementation time, for tasks estimated to take 1-hour, with main peaks labelled in red (reported times rounded to one decimal place and quarter hours; code+data):

Number of tasks reported to have taken a given amount of time, for tasks estimated to take 1-hour.

With 1-hour estimates, there is limited scope for a wide range of actual times (at least for times less than estimates). The labelled peaks contain 89% of 1-hour estimate tasks (1,525 tasks, 21% less than estimate, 44% equal estimate, 24% greater than estimate).

Tasks with larger estimated times are likely to take longer, creating more possible rounding peaks in the implementation time distribution. The plot below shows the number of tasks having a given reported implementation time, for tasks estimated to take 7-hour (i.e., 1-day), with main peaks labelled in red (reported times rounded to one decimal place and quarter hours; code+data):

Number of tasks reported to have taken a given amount of time, for tasks estimated to take 7-hours.

As expected, there are more peaks and implementation times are distributed over a larger range of values.

These plots suggest that many actual times are being rounded to 15-minute intervals. The plot below is based on the minute portion of the reported time (i.e., the hour part is ignored), and shows the fraction of tasks, for estimates of 1, 2, 3, 5, 7, and 14 hours, whose minute component of reported time has a given value (code+data):

Number of tasks having a given minute component of total implementation time.

For estimates of a few hours, around 90% of reported task time is on a 15-minute mark, while for 7- and 14-hour tasks the percentage drops to 80%.

If staff are manually entering task finish times, then some degree of rounding is to be expected. When the finish time is indirectly calculated, based on the submission of a completed form, there will be some fuzziness to the rounding number process.

  1. Nemo
    November 27, 2023 15:47 | #1

    Who would report a 28min task? I would never accept a report that recorded tasks of under 1h.

  2. November 27, 2023 21:22 | #2

    @Nemo
    If a task turns out to be trivial to implement, why not accept a report of less than an hour? You don’t want to encourage people to sit around. A time of 28 mins might stand out, but not if task start/end were measured via an automated report system.

  3. Nemo
    November 28, 2023 14:42 | #3

    @Derek Jones
    There was an entry called Miscellaneous. A task trivial to implement usually caused non-trivial problems down the road.

  1. No trackbacks yet.