Story points are a sizing technique used as a relative unit of measure for expressing the overall size of a user story or development effort. The utilization of story points is the most popular estimation approach for software sizing to measure the effort needed to implement a user story (Choetkiertikul et al., 2018; Dragicevic et al., 2017). The estimation method is a bottom-up approach and provides a measure of the complexity or quantity of work to produce (Jadhav, Shaga, & Thorat, 2017).
There is no fixed formula for defining the effort or size in the utilization of story points (Osman & Musa, 2016). Story points commonly utilize the Fibonacci sequence to express relative size (Alostad, Abdullah, & Aali, 2017; Jadhav et al., 2017; Raslan et al., 2015). The gaps between the sequences provide a higher degree of uncertainty in the level of effort for larger units of work. Essentially, the larger the effort (greater the size), the more likely the error in the estimate; thus, the higher the gap in the sequence (Raslan et al., 2015). Fox (2016) claimed that the Fibonacci sequence, when used as an estimation metric, is relatively unbiased. Usman et al. (2017) suggested an extended approach to story points by providing estimates by averaging three values; fastest, most practical, and maximum values to give a final estimate.
Story points are relative values, can differ from team to team, and are numerical representations of complexity. The estimating approach (size value) is specific to each team and uses each team’s cumulative knowledge (Choetkiertikul et al., 2018). The story point value can change from team to team depending on the baseline story in which they are relative too (Choetkiertikul et al., 2018; Soni & Kohli, 2017). Each development team uses story points on a different scale to establish a velocity over time (Ahmed et al., 2017). Story points are relative measures rather than quantitative measures (Soni & Kohli, 2017). The accuracy of story points is subjective to the person or persons performing the estimation and derived from previous experience (Arifin et al., 2017). Values are determined from previous efforts using a relative approach and differ from team to team.
One of the critical success factors for story point estimation is that the development group estimates the stories as a team using the same scale. Once the story points are estimated, the values are translated into the team’s velocity to forecast future sprints, iterations, or efforts (Brad et al., 2016). Velocity represents the total of story points that the development team can deliver in a specific iteration (Torrecilla-Salinas et al., 2015), and is a useful predictor of the team's capabilities (Ahmed et al., 2017). Story points are independent of time units and are a successful and common approach in software development estimation (Zahraoui & Idrissi, 2015). Harzl (2017) indicated that there could be disadvantages to using story points as a critical factor in the success of story point estimation is a team’s shared experience. According to Harzl (2017), it is challenging to establish velocity in the initial iterations, as team members have not had experience working and estimating as a collective group and experience challenges in providing accurate estimates. The story pointing approach, although commonly used, is subject to error.