Torlief Halkjesvik and colleagues from the University of Oslo began with simple task estimation. Following a pilot, their second study asked student participants within two conditions to imagine that they had read a book excerpt (the task was framed retrospectively to avoid encouraging ambitious estimates to whip up motivation). One condition involved estimating the time taken to read a fixed piece of text, either two or 32 pages. The work estimation condition involved estimating the amount of text read in either three or 48 minutes.
In terms of estimated productivity - page reading per minute - participants thought a big task was more efficient than a small one, but that proportionately less gets done in a larger amount of time than a smaller one - seemingly a paradox. To Halkjesvik and co-authors, this simply demonstrates we have trouble with magnitude, dilating small things - "it's not *that* small!" and compressing larger ones. This has parallels with other features, such as Vierordt's law on time estimation, and the central tendency of judgment.
Moving to an occupational setting, the authors informed 94 IT professionals about a genuine (historic) software project, broken into 10 ‘UserStories’ - discrete components common to IT projects. The study again avoided personal motivation, here by focusing estimates on the productivity of a hypothetical project developer. Unlike the other studies, no effect was found for imagined time efficiency for completing smaller (two User Stories) vs larger (five) tasks, but participants estimated work delivered in 20 hours would be more efficient than that over 100. It's worth noting the study as a whole overestimated the true productivity of the historic project, so the estimation of work completed in short windows reflects a pinnacle of unwarranted overconfidence.
These studies suggest "smaller magnitudes (of work or of time) are judged as disproportionately larger than large magnitudes." Breaking a software project down into a quick succession of releases may encourage unrealistic estimates of just how much of the project will get done in each release. Therefore, it's valuable to reverse your thinking and focus on the sub-tasks involved, and sense-check whether their durations really do fit your fixed deadline.