Story Points: How story points can help you to get better predictability

In Agile ways of working, story points plays an important role as it covers not only efforts involved to complete some work item, but also covers complexity and uncertainties which were missing in older ways of working. Hence it will give holistic view of factors which would have impact on completion of stories.

In this article I would like to share my thoughts and experiences on Story points.

|| Story points helps bringing team members to a common ground

Usually teams use Fibonacci series to decide on story points for any particular story. Team go through the story description and acceptance criteria as explained by the PO and anonymously give story points, there may be extremes or difference in story points what team members have given and discussion would be triggered to understand why there is difference in story points. This would go on for multiple rounds till all the relevant aspects would come in light and discussed thoroughly. It is kind of exercise which helps team members to get insights of various aspects of implementation which needs to be taken care and gives an opportunity to have common understanding on any of the work items.

|| Promotes the idea of relative sizing

Story points include basically three aspects i.e. efforts required, complexity involved and uncertainties.  So team starts with one reference story or sample story which all agrees on and would give it some number from Fibonacci series, then the next story would be compared with this reference story and story points decided based on above mentioned three factors. Hence there is no specific number decided with any efforts or complexities or unknowns, it is always relative in terms of the reference story.

|| Cumulative story points or velocity gives better future predictability

As cumulative story points or velocity derived from number of story points delivered in each sprint gives idea that how much story points a team can deliver in a particular sprint, an average velocity would be considered as reference for all future planning. Velocity gives more logical and scientific way to come to a conclusion that how much a team can deliver over a time of few sprint and based on this average velocity may be future sprints can be planned in similar way.

|| Story points for different categories

Usually teams gives story points for user stories only, there is no story point given for support tasks or enabler activities, but as per my experience we should give story points for all kind of work items including all kind of support work and other activities. Here spikes should be excluded which is kind of research work and we don’t have actual visibility of efforts or complexity.

The basic definition of deciding any work item qualifying to become User Story in Jira (not sure about other tools how the work items are handled) should be the activities involved to complete or implement that work item. If it is feature development work and having all the elements to become a cross functional work item, then it can be created as a  story in Jira. If it is just having support activities or any other kind of activities where it would not need all the activities i.e. development and/or testing then it should be created as task in Jira. Why I have mentioned this point here along with story points because once you have clear understanding on type of work item, you should still have story points captured with these work items and while presenting the sprint report for the team, it should be clearly called out that how much is the feature development velocity and how much support activities velocity for the team. It would give indication that where the team’s focus is now and based on that how future sprints should be planned. 

Hope this information would help you while deciding on story points and having it for different categories of work items.


Comments are closed.