Story Points

To make it easier for the team to plan the sprint, and for each member to organize their workday, every task needs an effort estimate.

There are different approaches and units for estimating tasks. For example, tasks can be estimated:

• by time (in hours)

• by effort/complexity (in person-hours)

In Agile methodologies, there is a dedicated unit for estimating task complexity — Story Points. This is a relative measure that helps forecast the effort required to complete a task and assign weight to items in the Product Backlog.

When estimating a task in Story Points, the following factors are considered:

• scope of work

• technical complexity

• possible risks and uncertainty in requirements

The main advantage of Story Points is their universality. Time-based estimates fail to account for risks and therefore are essentially just assumptions.

For example, the team might allocate 2 hours for a task. But due to unforeseen circumstances, it could take 8 hours instead, requiring a complete revision of the project plan.

Story Points cannot be directly converted into hours, days, or person-hours — they reflect only the relative effort. This lack of direct correlation to time actually simplifies sprint planning and overall project management.

Numbers

For Story Point estimation, it is recommended to use the Fibonacci sequence: 1, 2, 3, 5, 8, 13.

Tasks are estimated relative to one another. It’s best to start with simple tasks and then use them as a baseline for evaluating more complex ones.

In teams that work on similar projects over time, it is possible to compile a reference document with typical task estimates.

Task estimation should be done by the whole team. The most effective method is Planning Poker.

How Planning Poker works

Each participant is given a set of cards. A task to be estimated is described. Then each participant privately selects a card with their estimate and places it face down. Once all cards are on the table, they are revealed simultaneously. Anonymity ensures that estimates are independent of others’ opinions.

If the estimates vary, the team discusses the differences. Guiding questions can help: What difficulties do you see in this task? Why do you think it will or will not be a problem? The “5 Whys” technique can also be applied. After discussion, participants choose again and reveal their new estimates. When the team reaches consensus, the estimate is recorded. Note: consensus does not need to be absolute — agreeing on neighboring estimates may also be sufficient.

At first, this process may be difficult: team members’ productivity is still unknown, and estimates may be inconsistent. But this is exactly how Scrum works: with each sprint, the team becomes more accurate and productive.