Three Problems with Estimations

Estimating work is a recurring theme in software development. Even in the most basic form of agile software development, utilizing a single scrum team, a planning session is held every sprint. The goals of a this ‘Sprint Planning’ are clearly defined in the Scrum Guide:

1. Define the Sprint Goal to show why the work is valuable;
2. Which product backlog items, or user stories, help achieve this goal and will be picked up in the sprint;
3. How this work will get to a ‘done increment’ within the allotted Sprint.

So far, so good. However, there are many impracticalities and problems that arise in real life situations that make estimations both detrimental and dangerous. Here are three.

Comparative sizing

Most teams utilize a technique called ‘planning poker’ to estimate their user stories. Each team member has a deck of cards with the numbers 0.5, 1, 2, 3, 5, 8, 13, 20, 40, and 100 on them. There’s also a question mark and a coffee icon, to indicate the need for more clarity or a break.

A baseline story is defined. This is a story everybody can agree on is 1 point (or 2 points, etc.), so that all other product backlog items can be compared to that baseline. Then, all stories are assessed on three factors: effort (time), complexity…