In Agile ways of working, story points plays an important role. It covers efforts involved to complete some work item, complexity and uncertainties which were missing in older ways of working. It gives holistic view of factors which impact completion of stories.
In this article I would like to share my thoughts and experiences on story points.
|| Helps in bringing team members to a common ground
Usually teams use Fibonacci series to decide on story points for any particular story. In backlog refinement, team goes through story description and acceptance criteria as explained by the PO, anonymously give story point. There may be extremes or differences in story points which team members have given. Discussion triggers to understand differences. It go on for multiple rounds to make sure that all relevant aspects discussed thoroughly. It is kind of a constructive discussion. Team gets insights to take care for implementation. These insights gives an opportunity to have common understanding on any of the work items.
|| Promotes the idea of relative sizing
Story points covers three important aspects namely efforts required, complexity involved and uncertainties. Team starts with one reference story or sample story which all agrees on. Team decides a number from Fibonacci series. New story is compared with reference story to decide point. No specific number decided with efforts or complexities or unknowns, it is always relative in terms of the reference story.
|| Velocity gives better future predictability
Cumulative story points or velocity derived from number of story points delivered in each sprint. It gives idea that how much story points a team can deliver in a particular sprint. Average velocity considered as a reference for all future planning. Velocity gives more logical and scientific way to come to a conclusion. Team would get to know that how much a team can deliver over a time of few sprints. Based on average velocity, future sprints planned in similar way.
|| Story points for different categories
Usually teams gives points for user stories only. No point given for support tasks or enabler activities. As per my experience we should give points for all kind of work items including support work and other activities. Here spikes should exclude as it is kind of research work. We don’t have actual visibility of efforts or complexity for spikes.
Any work item qualifying to become user story should include the activities involved to complete or implement that work item. Feature development work, which have all elements to become a cross functional work item, created as a story in Jira. Support activities or any other kind of work, where all activities not required, created as tasks.
After team is having understanding on work item type, it will capture story points for work items. In sprint report team clearly calls out feature development velocity and support activities velocity. It gives indication about team’s focus now and based on that how sprints planning would be in future.
Hope this information helps you to decide on story points for different categories of work items.
Refer Scrum Guide for more information on all events, roles and artifacts.