Nowadays you will find less and less people who still haven’t heard anything about Agile framework called Scrum. Those, who already learned about it one of the first things they met was the concept of a “Story point”. Story point is a measure of size of a user story, feature or other piece of work but not equal unit of time. Story points are used by Scrum teams and provides with forecasts on total effort needed to deliver task.
Let’s start with the fact that the most common approach to estimate teamwork is estimation of hours. People are used to track projects using time units such as hours or days. Most of a time people encounter with time evaluation problem. Which means that some of tasks are difficult to evaluate in hours, so what they do is referring approximate number of hours they need to complete one task. To avoid inaccuracy problem is better to use story points which are used to calculate how many user stories a team can take in a sprint. In most cases story points are usually expressed according to a numerical range which is known as Fibonacci sequence. The usage of this sequence has an advantage. The team feels comfortable when using Fibonacci sequence because they understand the scale’s values. You will never struggle on questions like “Is it 4 or 5 hours” – in Fibonacci there is no 4 only 1 2 3 5 8 13 21 and so on. It contains meaningful gaps. To continue with, using story points is less stressful for each member of a team. Coworkers are not compared to each other so there is no direct competition between team members on how many hours they work. This enables to feel more confident of what you are doing. Furthermore, story points have no limitations to actual hours. That is why it is easy for Scrum teams to think abstract about the effort required to complete a story.
However, there are some disadvantages of using story points. A new team member or whole team is not able to use story points instantly. The first thing he/they must do is to complete couple iterations or so called sprints to measure how many story points they are able to deliver on average sprint. This average shows velocity which indicates the number of story points that are done in one sprint. What is more, to compare velocity between teams is very difficult, because of the different baseline of story size they chose. It is one of the common mistakes when project managers or CEO’s starts to compare people and even teams according to amount of story points they accomplish.
All things considered, yet there are lots of doubts what is better to use: story points or estimation by hours. The strength of using story point is that if you want to complete a story, the amount of work remains same regardless of the experience. That means no more disputes during estimation. Moreover, each team member is not limited by time for each task. Otherwise, story points are inappropriate for hourly build teams when time tracking is important for them. Anyways, as Dwight D. Eisenhower says: “In preparing for projects I have always found that estimates are useless, but estimating is indispensable”.
Social tagging: scrum > story point > time estimation