Effort Measurement/Estimation Process | Meta | Blog

The goal is to be the most productive and focused on the most important things, both personally, and (later) as a team.

After maintaining the "done" log for several months, I decided to improve my estimation accuracy, and here is how:

"Done" Log

In March, I started an experiment - writing daily blog posts about what's done.

Here is how it worked:

In the beginning of a day, a start a new Markdown file with some unique number, for example 19.3. Here, 19 is the iteration No.

Every task goes as <h2>. Subtasks become <h3>. In the text following the heading, I share any decisions/progress/issues that I find worth noting.

In the beginning of next day, I give the title to the whole Markdown file, write an abstract, publish, and share on Twitter.

And it helped me a lot:

Now, I have a searchable history about various decisions I've made along the way, and the reasoning.
Everyday starts with a blank page, and it helps to break unproductive loops from yesterday.
Writing down the struggles also serves as asking for help from some invisible friend, and actually getting it.

As it has proved itself being useful, I'll keep this practice going, with the following improvements:

The "done" entries will be in the new Done category.
The title will be just unique number such as 19.3.
The blog post abstract will contain autogenerated {{ toc }}.
I'll fix relative link rendering, including the table of contents, in blog post abstracts.

Estimates

Currently, I only document what's done. It's both productive and useful, but I also want to use it to estimate future work.

How can I do that?

Here is what Scrum says about estimates.

Historical Data

From the "done" log, you can tell:

for how many days you have touched a specific task/subtask
if you have worked for the whole day, or only part of it.

Note that not all days are created equal, some are longer than the others. Also, "part of a day" may differ.

On the scale of hours and minutes, the information in the "done" log is very imprecise. However, on the scale of weeks, months and iterations it's good enough.

The "Right" Card Size

When you add cards to the backlog, you can't tell if a card is of the "right" size to be a task. Some are too small, the other are too big.

What size is the "right" one, anyway?

The main criteria is if it's suitable for the iteration board. If tasks are too small, it's hard to see the full picture, and it takes too much bandwidth to manage them. If tasks are too big, the iteration board stalls for days, or even weeks. Neither one is good.

The sweet spot is one full day for one task. 2-3 tasks in a day are OK. One task is 2-3 days is OK, too. Anything outside these bounds should be either merged or split.

"Done" Tasks

Now, a rare task comes from the backlog. Most tasks are done ad-hoc. To learn picking the right size for a task, and to prepare historical data for estimating future work, I'll register ad-hoc tasks on the iteration board, too.

Notation

The unit of measure is days. Full day spent on a task is 1d.

Part of a day spent on task is measured approximately:

most of the day: 0.8d
half of the day: 0.5d
minor part of the day: 0.2d.

If a task took less than 10 minutes, let's agree it's nothing, 0d.