Story points are a way of measuring the complexity of a story.
Put them in relation to the implementation effort of a story and the result will be the velocity, that represents the complexity of a story in relation to its effort. Story points are abstract, relative, and about effort.
It can be defined as a simple calculation measuring units of work completed in a given timeframe.
For example, units of work can be measured in several ways, including development hours, user stories, or story points. The same applies to timeframe; it's typically measured in iterations, sprints, or weeks.
One good reason not to use hours is that one team member may take longer than another. Using story points, a team could, for instance, estimate using a combination of risk, uncertainty, complexity, and effort for the entire team.
Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to story points. Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work.
But there is also an understanding that story points can and should be an estimate of how long it will take to develop atask. In the end, story points represent time. This has to be so because time is what measures velocity and what is important when there's a deadline, need or expectation to deliver value to the team and to the company.
Time is a important reference but should be avoided. So estimation, as a linked concept to time, represents the effort involved to deliver, and the estimate of the effort involves complexity, risk and uncertainty.
Teams assign story points relative to work complexity, the amount of work, and risk or uncertainty.
Values are assigned to more effectively break down work into smaller pieces, so they can address uncertainty. Over time, this helps teams understand how much they can achieve in a period of time and builds consensus and commitment to the solution.
It may sound counter-intuitive, but this abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work.
The main points to estimate:
Time could still be used to estimate a task effort in situations like:
Major benefits of Story Points:
One option is to use the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 20...), on a scale up to 20. The definition of ready states that all stories (or tasks) over 20 have to be split, so estimating up to 20 is a good standard.
The first issue should receive 5 or 8 story points to be referenced as a benchmark to the following points estimates.
Any other task in the sprint will be compared to the first issue. Is it more complex or simpler to implement? It’s all about effort evaluation.
During the planning phase, the implementation effort can be measured in time by creating detailed subtasks and estimating them in hours. Comparing different issues over time and focusing on the remaining time of open tickets, gives a much better understanding.
At the begining of each sprint, compare issues with the first one of the first sprint. Repeat it. The key is to compare. Then repeat it again. Compare different forms of complexity to the very first issue. The intention as teams progress and evolve is to increase perception and velocity.