In our sprint planning for the BBC Food website on Tuesday, we quickly estimated how long each task would take. Thinking about it today, I wonder whether that was sensible. Clearly it's important to ensure that there's enough time to get things done (and that there's enough things to fill the time available), but there are two problems that have struck me this week.

1. Unless you're very familiar with the code, there's no way you can make a reasonable estimate (other than by chance).
2. Putting a time against a task, even if it's an estimate and you know it's not accurate, means you're less likely to do the right thing when fixing it if that right thing is going to take longer than you've estimated the task will take.

The second point there is the issue I've been thinking about. On the Food website, there's a tool that allows you to add a recipe to your "binder". There was a bug which meant that the name on the binder was broken in the mobile site, even though it had been fixed on the desktop site. The right thing was to write a helper so the same code created the header on both versions, but that would have taken 10 times as long (estimate) as the fix I had thought to implement (which was fix the bug in the code on the mobile template). The act of estimation has put me under pressure to do it in the time I said I would and not apply the correct fix. Maybe I shouldn't create estimates.