A story point is a unit of measure used in the agile development process to express an estimate of the overall effort that will be required to fully implement a product backlog item. Essentially, story points are used to standardize how effort is conveyed and understood across the team.
What matters is the relative difference between each story point number. If you assign point 2 to a story, that means the effort taken to complete that item is twice as much as a story that you assign point 1.
Learn how to prioritize by making it a simple process, to build products that stand out. Learn more about how to source insight, choose the right prioritization framework and much more.
The same goes for 100 and 200. Or 1000 and 2000.
Whilst this may sound a little complex, in theory, it’s simple to roll out in practice.
There are 3 main factors to consider when estimating effort using story points:
The amount of work there is to do: All members of the development team should come together and agree on how much work there is to be done. If the backlog item in question is a simple webpage build, the work will be less than if it involves coding a new log-in system.
How complex that work is: Following on from the amount of work, with a story point, the team needs to define how complicated that work is. Is the task demanding purely because of the man-hours required, or because each small step is an undertaking in itself?
The level of risk or uncertainty associated with the work: They say “nothing ventured, nothing gained” but some developments are inherently riskier than others. If you’re rolling out a brand new product, the level of uncertainty will be higher than if you’re just tweaking a long-standing, successful piece of software. Nevertheless, this is why story points are so useful.