Points compare work rather than promise a duration
Story points are a relative estimate of work size within a team.
The team compares a new task with work it already understands: how much needs to be done, how complex the conditions are and what remains unknown. The number helps people discuss differences, but does not mean the task will necessarily take a particular number of hours.
Imagine a training example involving a team developing a workshop website. It needs to add a form field, support booking changes and connect an unfamiliar external service. All three tasks may be called “small” until the participants compare their actual conditions.
- Size
How much larger or more complex is this work than a familiar example?
- Timing
When can the team finish it, given availability, the queue and dependencies?
How to choose a reference task
Choose recently completed work that participants remember well. In our example, this is adding a required contact field: changing the interface, validating input, saving the value and checking the main flow. The team provisionally calls it a 3. The number itself is arbitrary; a shared understanding of what it includes matters more.
Do not use only a simple text change as the reference if most tasks involve several parts of the system. Comparing booking changes with it will be awkward. Keep a short description of the reference and one or two familiar examples of different sizes.
If the team or product changes substantially, old references may lose their meaning. There is no need to maintain the appearance of an absolute scale. Discuss new examples and be cautious about comparing figures from before and after the change.
An example of relative estimation
| Work | Illustrative estimate | Reasoning |
|---|---|---|
| Add a contact field to a familiar form | 3 | Reference: the interface, storage and checks are understood. |
| Move a booking between available sessions | 5 | More rules and checks, but familiar parts of the system. |
| Connect an unfamiliar notification service | Do not estimate until clarified | Access and information about integration limits are missing. |
An estimate of 5 does not mean “five hours” and does not establish an exact ratio between durations. It says the team expects larger work than the reference. Even tasks of the same size can spend different amounts of time waiting for an external decision.
The last row deliberately has no number. Sometimes it is more useful to obtain access, check the documentation and make a small trial request first. Putting a large number in place of uncertainty creates an appearance of understanding without reducing risk.
Why one participant chose 3 and another chose 13
When discussing booking changes, one developer sees a date change in the database. Another includes releasing the old place, reserving the new one, protecting against concurrent actions and notifying the visitor. Different estimates reveal different views of the scope, not necessarily different levels of competence.
- State assumptions
What did each person include in the work?
- Check boundaries
Which scenarios are actually needed now?
- Clarify risk
What is unknown, and how can it be checked?
- Estimate again
Compare the commonly understood scope with the reference.
Do not automatically average 3 and 13. The average does not answer whether protection against duplicate bookings is included. After clarifying the scope, the team might choose 5, split the story or investigate first. The useful outcome of the discussion is clarity, not a compromise number.
To prevent the first number from influencing everyone else, participants can think independently and reveal their estimates at the same time. This is one way to organize the discussion, not a compulsory ritual. A lengthy card exercise may be unnecessary for obvious, familiar work.
When splitting the task is a better option
If participants cannot keep all the conditions in mind, try identifying a small, useful outcome. For example, first allow changes only between sessions of the same workshop, and consider switching workshops separately. The boundary must make sense to visitors and be honestly represented in the interface.
Splitting work into “server” and “interface” may help execution, but does not itself reduce the scope users need. Relative estimation requires understanding the complete outcome the team intends to finish. Technical subtasks sit within that decision.
Do not lower the number simply by leaving checks out of the discussion. If work is considered done only after scenarios have been verified, that verification belongs in the estimated scope. Otherwise, the estimate will describe writing code while the plan expects a finished result.
Definition of Done helps the team agree on what completed work includes.
How to use historical data for forecasting
Observe how much work the team actually finished over comparable periods using the same definition of done. This may help the team discuss a range for future scope. But holidays, unfamiliar technology, team changes or accumulated dependencies make mechanical repetition of the past unreliable.
If a team completed 18, 22 and 16 points in three illustrative periods, that is not a promise to finish 22 next time. Check the work mix and people’s availability first. When discussing an external deadline, state assumptions and uncertainty rather than treating the highest past result as a commitment.
Do not turn the scale into a fixed hourly conversion. If a budget or date is needed, estimate it separately with people, dependencies and risks in mind. A relative number may be one input, but cannot replace that discussion.
Where to keep the working result
In Sinqly, you can create a task called “Clarify the scope of booking changes” and add the reference task, scenarios and unknown conditions to its description. This example does not imply built-in story point calculation; registration is free.
A small experiment for the team
Choose several upcoming pieces of work and record their estimates and the reasons for disagreement. Once they are finished, revisit what was unclear rather than asking “who was wrong”: a hidden check, external access or a different interpretation of a requirement. This gives the team material for improving task preparation.
If points do not help people make decisions, do not retain them merely out of habit. For a flow of similar small tasks, the team may use other forecasting methods. A tool’s value depends on the mistakes it helps people notice, not how familiar its report looks.
More questions to clarify
Does one story point equal one hour?
No. A fixed conversion undermines relative estimation. Duration also depends on the queue, availability and dependencies.
Are story points mandatory in Scrum?
No. The Scrum Guide does not require this particular unit of estimation. The team chooses a suitable way to discuss work size.
Can two teams’ velocities be compared in points?
That comparison is not valid without common calibration and context, and in practice the scales and work mix usually differ.
Was this helpful?
Rate the article and tell us what was missing. Your feedback goes to the Sinqly team and will not be published on the site.
Sources and notes
- Atlassian: agile estimation
- The suggested process reflects editorial practice; it does not promise identical results for everyone.
Sprint planning: set a goal, choose the work and inspect the result
Formulate a Sprint Goal, select work the team can complete and inspect the result. An illustrative booking improvement and common planning mistakes.
Definition of Done: what counts as finished work, with an example
How to agree on a Definition of Done, distinguish it from acceptance criteria and Definition of Ready, and check completion using a booking form example.
User stories: how to write one, with examples
The user story format, three improved examples and a workshop booking story: distinguish a need from a feature, add acceptance criteria and split work that is too large.