Hi, guys! We continue to spread good practices on development processes got from our users so that your valuable experience becomes a common asset. Remember that you are always welcome to share your opinion on methodologies, technical and project management solutions or any other subjects you are interested in if you haven't done that before. Today we will talk about such a common job estimate as story points.

As a rule, developers are not good enough in work evaluation in hours or any other time values. To deal with this, we use story points instead - relative estimates of effort required to finish a particular task. Story points are supposed to add to our estimates more accuracy and objectivity. They allow us to take into account not only amount of work while estimating it, but also possible risks and uncertainly we can meet up with during the development process. That sounds nice, doesn't it? But everything can not be so simple - estimates which, it would seem, must consider all the difficulties and perfectly coincide with the real terms, still differ from them, continuing to break deadlines and harm project management. So, why don't they work sometimes as expected?

In terms of physics, story points are a job. And a developer's ability to cope with the job is power. We all remember from physics that a power is proportional to the ratio of job to time. Or, in other words: job is power multiplied by time. Therefore, it is possible and necessary to define planned time of work on a task. Only after this, don't forget to adduce it correctly to the job-storypoints, multiplying the value by the power. A developer on his own is unlikely to do that properly.

And what about your team? Do you use story points or tend to traditional ways of tasks evaluation? How successful is you experience in this?

Riter development team