Why story pointing needs to be stopped

If you've been around in the Software Engineering industry long enough, you'll probably be familiar with the term 'story points'.

For those that haven't aren't familiar, story points are meant to be an estimate of the overall 'effort' required to implement an item within the backlog.

What is the problem story points are meant to solve? Well, they are there to stop developers from estimating in hours, because we are notorious for underestimating how long we think something will take. Using story points is meant to be a way to get an accurate velocity of how much work a team is actually able to get through in a Sprint.

Now, let's delve into what story points are. Story points are a relative measure of the effort and complexity involved in completing a user story or task. Instead of estimating in hours, teams assign story points based on a collective assessment of the work's complexity, uncertainty, and effort.

For example, consider two user stories: one involves creating a simple login page, while the other entails developing a complex algorithm for personalized recommendations. In this scenario, the team would assign different story points to each, the size would be relative to the effort required for each task. The simple login page, being less complex, might be assigned a lower number of story points, such as 3. On the other hand, the complex algorithm for personalised recommendations, with its higher intricacies and effort, could be assigned a larger number of story points, let's say 8.