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.

Grooming

Scrum doesn't give a clear cut idea on grooming which is actually one of the most important practices in an agile project.  A well groomed product backlog is one of the basic tenants for a successful agile project. From a well groomed product backlog you can pull out stories to a sprint and comfortably complete the implementation with less uncertainties.

Unfortunately most projects in the initial stages have a tendency to use product backlog to push stories into the sprint without a proper grooming more due to ignorance. We are agile so we don't want to spend too much time on grooming. Once the story is picked into the sprint and when worked on we will discuss the details. The problem is that if we start learning what needs to be done while working on a story the is likely hood that there will be scope creep. Working on the details will expose more questions and might even end up in the story not being completed or completed without the whole business value or quality and overall trust on the team will be effected. You don't want to spend the sprint to be used to figure out the business need and struggle to keep up to the commitments. This more sounds like waterfall model inside a sprint, ie first find the requirements, develop the code and then put it for testing. If the business is not reachable within the sprint it will add more problems. If there are external project dependencies it gets even more difficult.

If we can apply grooming the right way which is to 1) discuss the story first to find out if it is the right story in terms of priority, test ability and feasibility. 2) if it is in the right size and priority then discuss the acceptance criteria in terms of a common understand by 3) bring out the scenarios that can be used to define the scope and help define the defenition of done based on acceptance criteria so the team now only needs to pull it into the sprint and work on the implementation details.

How can this be achieved. It is very important that the team understands the business need of the story. Spend about 10% of capacity of the current sprint to groom stories for the next sprint. Grooming will include Identifying the user and need for the story to the business and the scenarios that will define the story to be done based on the acceptance criteria identified for the story. This will reduce the time on planning and help estimate tasks for a story.