For sometime there’s been debate on the use, or even the need of story points. Hmmm…. There are  multiple needs to consider:

1. Short term estimation, so as to commit for a sprint.

2. Prioritisation decisions

3. Release planning

Though controversial there may be another reason:  Productivity gauge (caution advised)

In this discussion I’m assuming you are executing projects using Scrum or some other short cycle iterative approach.

The two matters to consider are:

1. Do we need to do any estimation at all?

Well, unless you seldom have to prioritise a work packet over another, or have very large capacity you need to estimate (not exactimate) items. So for a vast majority, the answer is yes.

2. Should we switch to story point estimation?

If the current method of estimating is able to handle relatively small packets of work (enhancements/change requests)  taking into account the whole cycle from analysis to delivery (to staging) with reasonable reliability, there is no need to change to story points. However most projects don’t find themselves in such a happy state and story point estimates is a good approach. There are many reasons why story points are a superior choice (at least at the team level);

But finally the only good circumstance in which we can avoid estimating altogether is if we can always break items (or user stories) into small uniform sized pieces of work (taking just about a couple of days to complete). Then all we need to do is look at the business benefit for every story and count the number of stories. The velocity is given simply by number of stories done in an average sprint. This uniform and consistent division is not usually easily achievable.

Advertisement