Liferay.Design / Handbook
Part of Liferay, IncCode/Content Licenses

Story Points

Sign In

What is Story Points?

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.

What is Velocity (in Agile)

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.

Why Not Using Hours Instead?

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.

Story Points vs Hours (and the relationship to time)

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.

How to Estimate?

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:

  • The complexity of the work;
  • The amount of work to do;
  • Any risk or uncertainty in doing the work;

Could Time Still Be Used?

Time could still be used to estimate a task effort in situations like:

  • If related to small tasks, especially when it is known exactly how much time is needed;
  • From the very beginning, when estimating a sprint by the hours/days/week capacity – there's no need to investigate team velocity (but still need to teach the team how to estimate).

Major benefits of Story Points:

  • No correlation with skills and experience of the estimator;
  • No re-estimation if velocity changes;
  • Velocity is tracked;
  • Perfect for high-level estimation.

How to Calculate Story Points

  1. Adjust the Definition of Ready

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.

  1. Use the first story as a benchmark

The first issue should receive 5 or 8 story points to be referenced as a benchmark to the following points estimates.

  1. Compare tasks and estimates in the first sprint

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.

  1. Determine the implementation effort in time

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.

  1. Repeat the process for a few sprints

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.

Something to improve? Report an issue!