Story points, while certainly not perfect, can be a decent first-stab abstraction for development effort. In my opinion, using story point scales can be an excellent tool to uncover both risk and incompletely broken down tasks.

This set of point descriptions 1 seems to be a (fairly) decent starting point for pointing tasks:

  • 1 point: This is the absolute smallest feature that a single person could do without needing QA. This cannot be a subtask. These should be rare.
  • 3 points: Can be done in 1 day 2 by the team. The majority of tasks should be this size.
  • 5 points: This is a task that cannot be done in a day by the team. It cannot be broken down or it has extra dependencies.
  • 8 points: This is truly smelly and probably represents a story that is still in rough form or hasn’t be dissected.
  • 13 points: Large unknowns. Here be dragons and catastrophies.

  1. I know grabbed this from somewhere, probably a HN comment, but I did not note the source. I will edit with a reference if I come across it again. ↩︎

  2. I am not at all against using time for story points. It always boils down to that anyway. ↩︎