Scrum/Story points

Story points are a tool used to help with medium-term predictions as they may be needed for release planning or communication inside the organization. They also give a rough(!) sense of the evolution of team velocity. If these two are not needed, estimating in story-points is not adding any value.

Each story on the product backlog is compared to other stories to see how it's difficulty (representing the complexity of the work, time and effort needed for it and also the involved risk) compares. We typically start with a very simple item that will only take a little amount of time to do and then expand the scale from there.

The measurements used for estimation can for example be T-Shirt sizes (S/M/L/XL/XXL), At Openbravo we use a scale based on a part of the Fibonacci sequence:

• 1, 2, 3, 5, 8, 13, 21, 34 are used to express the difficulty of a manageable task
• 89 is used to express a task is too large to be handled.

If an item is found to be an 89, it must be examined and broken down into easier pieces. Things must also be broken down if they are found to be too large for the sprint ahead.

The pieces must however be self-contained in terms of user value.

Example:

Sorting 1000 address book cards by family name and first name – the goal is to make them easy to find for a person searching someone specific. A valid breakdown needs to consider this intended value and then deliver it in steps, e.g.:

• first sort only by the first letter of the family name
• fully sort by family name
• sort within the family names by first names

Each of these 3 steps gives value to a person looking for a card and each can be delivered to the user after being executed.

An invalid breakdown would be:

• scan all cards into a computer
• write sorting algorithm and let that sort the scanned cards
• print sorted cards

In this sequence we could deliver customer value only after the last item, not at every iteration. Such an approach is perfectly valid inside a sprint, but the substeps cannot be an acceptable deliverable.

Things to keep in mind:

• Do not try to have your entire product backlog estimated. It is perfectly enough to just estimate the things coming up soon, or if you need to plan for a specific timeframe (e.g. a release), items you are hoping to get done in this timeframe
• Estimates are estimates. When you need to pinpoint a committed release date or similar, first check with the team and give careful consideration to all risks and probabilities so you can name the most likely date as well as the best-case/worst-case bandwidth. Never use a plain estimate to make a binding commitment.
• Estimates should not be revised later on (even if they turned out to be seriously mistaken). They include information about the error tendency in your estimations and hence they reflect the future better than actual numbers.
• Estimates have a tendency to drift over time. This is a normal process and should be kept in mind when looking at velocity data over a longer period of time.