Story Pointing

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.

Velocity

According to scrum values, velocity is how much product backlog effort a team can handle in one sprint. Velocity is used for predicting when the project will be done. When a project is started we have a general scope, a projected cost, and a probable date. When we go sprint by sprint we learn more about the scope based on the reality of the situation. We go faster or slower, may find better opportunities or challanges. So predicting when a project will be over based on velocity may not work out well as mostly seen in agile or scrum based projects.

Lets take a different approach and ignore velocity and capacity and work based on a goal. The team with the product owner selects a bunch of items of high priority for the next sprint and establish a goal for the team to meet. As the sprint moves either the items which were more than the team could  do be removed or get more PBI's that could fit into the goal into the sprint if they have the time for it. At the end of the sprint the Product Owner, Team and Key stakeholders can inspect and adapt based on what was completed.

If we used short cycles of development of a week to 2 weeks at a maximum which will give a quick feedback on the progress towards our goals, commitments and projections. A build up chart might help to gauge how far we have progressed towards our goal. Any time a team spends on worrying about velocity or capacity is waste and not adding any value. It slows down progress, impedes agility and robs time and effort that could otherwise go to creating value.

Use last sprint's velocity as a guidance to what can be done in next sprint but focus on goal and measure progress based on how far or near you are to your goal and make changes that help you to get to your goal.