Story pointing is probably one of the most ambiguous and confusing concept in agile practices. Many teams seem to be confused on how to deal with it. The idea is to measure the complexity of a story to an ideal baseline. Depending on who you, you have different perspective of what it is.
Story pointing is a relative estimation technique. One of the hardest tasks for a developer is to estimate how long it will take to complete a task. Software estimation has been a very difficult task to achieve and we can always say that we are very bad at estimation as software engineers. From a management perspective that is all what they care about. How long and when will it be completed.
The idea behind story pointing is to pick one simple story from your backlog that can be done in a couple of hours to a day or less and point it as one. Pick other stories and compare it with that and estimate relatively ie if it is twice harder(2) or thrice harder(3 points) or the same (1 point). The higher the unknowns the higher the pointing. Generally complexity and unknowns will increase the pointing. This way you have a relative estimation for a story. With a couple of sprints the number of story points done in each sprint will determine how much is the velocity of the team. Another way is to use yesterdays weather to determine tomorrows weather ie is to use the last sprint velocity as the number of points that could probably be done in the next sprint.
More than the relative estimation one advantage I see in story pointing is that during the story pointing when we have a wide range of points it indicates that the understanding of the story is not clear enough and that should lead to more discussions and a re-pointing to come at a better pointing for the story.
I have observed some teams estimate story points in terms of days of work for example 1 point story can be done in a day, 2 story point in two days etc. As long as the team is consistent on its idea of story pointing and it provides a baseline for estimation for the product owner it may be fine. The difficulties arise when you have multiple teams working on the same project and the product owner tendency to compare the velocity from team to team, which is a naive approach. The velocity for one team should never be compared against another team even if they both work on the same project. It would be better to divide the project on focused modules so that work on each module does not effect the other.
I have heard some arguments on what is the need of story pointing? Why not just pull in stories and using lean Kanban techniques and use last weeks weather to determine how much work can be done. But what will be last weeks weather to determine next weeks weather also it will be hard to buy in no estimation from a management perspective. After all you need to know when a project will end.
My overall view on story pointing with experience is just to use it for the advantages it gives like 1) a very generic estimation which could be used to estimate roughly when a project will end.2) a story complexity measure to determine if the story is rightly sized and has enough information to be pointed 3) give a rough velocity estimation. I would not give much importance to story pointing other than a rough estimation technique. With experience generally teams do get good at estimating story points and I have seen some teams come up with a reasonable velocity estimation that can be used. Mature teams who can come up with a consistent velocity from sprint to sprint in terms of output and value to business could use it to their advantages with the right conducive environment. With proper clarity of story pointing and understanding of story points teams and business can use it as a tool to come up with a generic estimation provided there is an environment and understanding to use the best process and engineering practices to move towards the business goal by releasing the most marketable value items early to the business so that each sprint has a possible valuable outcome irrespective of the velocity estimations.
