Dilemma of story point estimation

Story points are popular tools used in agile project development practices to estimate the overall effort and cost required for implementing a user story. Story points usually includes variety of factors such has time, complexities, risks, development efforts, difficulties and dependencies. The subjective factors involved in the measurement often makes the accurate calculation difficult. There are a number of articles and books available explaining what they mean, how to estimate the story points and what all should be the considerations. However, there is another aspect to the story point estimation that is more subtle but might exist and affect many teams. This particular angle is how story points are perceived. In this blog, I am going to share my experience about how story points perception can be different and how it affects the projects.

The Dilemma

In a team consisting of new members, experienced developers, managers and executives, story points can be perceived almost in opposite ways as we go from top to bottom in the hierarchy of the team.

Higher number of points for a project tends to bring more confidence for development team. It adds room for experiments, time for testing and room for handling technical debt. It can also allow the project to be improved in subsequent iterations to get to the final goal. However, higher estimates, may convey higher costs and hence higher risk for the senior management and executives. It may exhibit that the project is resource heavy, resulting in re-evaluation of its importance, requirements and priorities as compared to other projects.

Lower number of points, on the other hand, brings in time crunch, higher delivery risk, tight scheduling, less room for iterations, less testing and overall potential for cutting the corners by introducing short term work arounds resulting in code debt for developers. However, such a project can be perceived as a low investment and higher return project by senior management and executives, hence bringing in higher probability of getting ranked higher in prioritization.

Escape

Following are some of the methods that can be used to solve the story points dilemma:

• Dividing the project into multiple smaller releases
  Higher number of points can often reflect bigger size of the project. One approach we have tried in my team to overcome this story points dilemma is to divide the project into smaller epics or releases where each part moves us closer to the end goal while at the same time also providing value. This helped us in keeping the points in a reasonable value to points ratio, as at each smaller release there was a value delivered. This also helped us in moving in more agile fashion and adding enough time for development.
• Re-evaluating the key requirements
  A project might be aimed at solving a particular user story. However, when the points increases, it might be worth while to look deeper into the requirements and end goal of the project. A solution to the points conundrum might lie in understanding the end goals better and reprioritizing them such that the value to points ratio can be optimized.
• Re-calculating the return
  A project of bigger size might involve designing or development of some core components. In some cases, it might be possible to reimagine these components such that they can be used in other projects as well. In this way, completing the current project would help in reducing the cost / estimates for a similar project in future thus increasing the return value of the current project. Further, we can even use the method mentioned above and divide a project into these smaller core components where each part solving a problem that can be utilized by more than 1 project in future.

Have you experienced such a dilemma in your projects or teams? How have you solved this paradox?