Developers are surprisingly bad estimators when it comes to dates. On the other hand, they have a good memory of what circumstances lead to what problems on just about every project they ever worked on and have a sixth sense for the same circumstances in a new project.
Therefore: Let developers estimate effort by selecting comparable work. A job that is 2/3 as complex as some previous job will probably take about 2/3 as long. Comparable estimates are usually accurate even for ill-defined projects unless there is hidden complexity not taken into account when selecting comparable.
Hidden complexity usually shows within a few days of actually starting work. It's OK to challenge an estimate that is not taken seriously but don't try to hold developers to last week's estimate when they've uncovered hidden complexity. Take heart, there is such a thing as hidden simplicity that does surface on occasion.
As an aid to memory, record uninterrupted days applied to current efforts as was done in Figure 3. This data will be a handy reference when today's projects become tomorrow's comparable. Do not expect a week on the job to yield more than two or three full days of development.
Also, don't try to use this data for performance evaluation. To do so will destroy the frank relationship required for good estimating. Besides, it's not clear whether bigger or smaller numbers indicate improved performance. It will be necessary to prorate accumulated effort data should a project undergo a Work Split. Some ratio will suggest itself. Just don't count days twice.