Fig 1 - available via license: Creative Commons Attribution 4.0 International
Content may be subject to copyright.
Source publication
The necessity of software as stand-alone products, and as central parts of non-traditional software products have changed how software products are developed. It started with the introduction of the agile manifesto and has resulted in a change of how software process improvements (SPI) are conducted. Although there are agile SPI methods and several...
Contexts in source publication
Context 1
... front-heavy development. The core scenario is that in the Telenor Sweden case, backlogs are used in multiple stages, which is a common practice in agile software development [8] from an initial backlog where items of large variety are collected, then the items are "sorted" into product backlogs, and finally in a spring backlog, as illustrated in Fig. 1. In each backlog containing items, the items are analyzed and refined, and sometimes broken up/merged/dismissed before progressing to the next backlog, e.g. in feasibility review and detailed analysis phases (as illustrated in Fig. 1) through several decision-points. This way of working joins business analyst/product management level ...
Context 2
... collected, then the items are "sorted" into product backlogs, and finally in a spring backlog, as illustrated in Fig. 1. In each backlog containing items, the items are analyzed and refined, and sometimes broken up/merged/dismissed before progressing to the next backlog, e.g. in feasibility review and detailed analysis phases (as illustrated in Fig. 1) through several decision-points. This way of working joins business analyst/product management level and product planning with subsequent product realization (sprint backlog) levels. This is one of the main goals of becoming a complete agile organization. It is also in line with the general levels of decisionmaking in agile software ...
Context 3
... realization (sprint backlog) levels. This is one of the main goals of becoming a complete agile organization. It is also in line with the general levels of decisionmaking in agile software development [19]. In agile software development, decisions about products and release plans are made at a strategic level (similar to the feasibility review in Fig. 1, while decisions related to project management with the aim to determine the best way to implement the strategic decisions are made at tactical level (detailed analysis phase in Fig. 1. Finally, decisions about the implementation are made at the operational level (development phase in Fig. 1. Telenor Sweden's agile process supports ...
Context 4
... development [19]. In agile software development, decisions about products and release plans are made at a strategic level (similar to the feasibility review in Fig. 1, while decisions related to project management with the aim to determine the best way to implement the strategic decisions are made at tactical level (detailed analysis phase in Fig. 1. Finally, decisions about the implementation are made at the operational level (development phase in Fig. 1. Telenor Sweden's agile process supports product planning and development and they have good ideas of using their backlogs at different levels which enables other roles, teams, and parts of the organization to work "agile". ...
Context 5
... a strategic level (similar to the feasibility review in Fig. 1, while decisions related to project management with the aim to determine the best way to implement the strategic decisions are made at tactical level (detailed analysis phase in Fig. 1. Finally, decisions about the implementation are made at the operational level (development phase in Fig. 1. Telenor Sweden's agile process supports product planning and development and they have good ideas of using their backlogs at different levels which enables other roles, teams, and parts of the organization to work "agile". However, this creates several challenges, which are detailed ...
Context 6
... in industry. In particular for large organizations where the work requires decisions on multiple levels to select what to realize in the next phase/sprint. The case company Telenor has, in essence, three types of backlogs for a product, one backlog before the feasibility review, one product backlog, and one sprint backlog as illustrated in Fig. 1. In the first backlog all incoming requirements/ideas/features (called items from hereon in) are initially gathered before a feasibility review takes place. An item is then, either dismissed or it progresses to the product backlog, and then to the sprint backlogs. Each of these backlogs contains items that are inherently specified in ...
Similar publications
The specialized literature defines Software Process Improvement (SPI) as the fundamental approach to improving software products in software development organizations. In this context, studies report several problems and difficulties that organizations face during the implementation of improvements. Although there are studies that address the probl...
While many organizations successfully embrace and experience software process improvement (SPI) benefits, others abandon the effort before realizing the total potential result of an SPI initiative. Therefore, researchers' interest in understanding the reasons why software organizations that have a successful start in adopting SPI abandon improvemen...
Citations
... However, in practice, SP are often initially estimated based on incomplete information. Such information may be discovered late or changed (Hoda and Murugesan 2016;Svensson et al. 2019), which may lead to the SP changes. To minimize the impact, there are needs to better understand the SP changes and an automated approach to predict the SP changes. ...
Story Points (SP) are an effort unit that is used to represent the relative effort of a work item. In Agile software development, SP allows a devel- opment team to estimate their delivery capacity and facilitate the sprint plan- ning activities. Although Agile embraces changes, SP changes after the sprint planning may negatively impact the sprint plan. To minimize the impact, there is a need to better understand the SP changes and an automated approach to predict the SP changes. Hence, to better understand the SP changes, we examine the prevalence, accuracy, and impact of information changes on SP changes. Through the analyses based on 19,349 work items spread across seven open-source projects, we find that on average, 10% of the work items have SP changes. These work items typically have SP value increased by 58%-100% rel- ative to the initial SP value when they were assigned to a sprint. We also find that the unchanged SP reflect the development time better than the changed SP. Our qualitative analysis shows that the work items with changed SP of- ten have the information changes relating to updating the scope of work. Our empirical results suggest that SP and the scope of work should be reviewed prior or during sprint planning to achieve a reliable sprint plan. Yet, it could be a tedious task to review all work items in the product (or sprint) backlog. Therefore, we develop a classifier to predict whether a work item will have SP changes after being assigned to a sprint. Our classifier achieves an AUC of 0.69-0.8, which is significantly better than the baselines. Our results suggest that to better manage and prepare for the unreliability in SP estimation, the team can leverage our insights and the classifier during the sprint planning. To facilitate future studies, we provide the replication package and the datasets, which are available online.
... However, in practice, SP are often initially estimated based on incomplete information. Such information may be discovered late or changed (Hoda and Murugesan, 2016;Svensson et al., 2019), which may lead to the SP changes. To minimize the impact, there are needs to better understand the SP changes and an automated approach to predict the SP changes. ...
Story Points (SP) are an effort unit that is used to represent the relative effort of a work item. In Agile software development, SP allows a development team to estimate their delivery capacity and facilitate the sprint planning activities. Although Agile embraces changes, SP changes after the sprint planning may negatively impact the sprint plan. To minimize the impact, there is a need to better understand the SP changes and an automated approach to predict the SP changes. Hence, to better understand the SP changes, we examine the prevalence, accuracy, and impact of information changes on SP changes. Through the analyses based on 13,902 work items spread across seven open-source projects, we find that on average, 10% of the work items have SP changes. These work items typically have SP value increased by 58%-100% relative to the initial SP value when they were assigned to a sprint. We also find that the unchanged SP reflect the development time better than the changed SP. Our qualitative analysis shows that the work items with changed SP of- ten have the information changes relating to updating the scope of work. Our empirical results suggest that SP and the scope of work should be reviewed prior or during sprint planning to achieve a reliable sprint plan. Yet, it could be a tedious task to review all work items in the product (or sprint) backlog. Therefore, we develop a classifier to predict whether a work item will have SP changes after being assigned to a sprint. Our classifier achieves an AUC of 0.69-0.8, which is significantly better than the baselines. Our results suggest that to better manage and prepare for the unreliability in SP estimation, the team can leverage our insights and the classifier during the sprint planning. To facilitate future studies, we provide the replication package and the datasets, which are available online.
... Based on the Agile manifesto that comprehensive documentation has lower priority than working software [14], it is possible that the team may not foster adequate or up-to-date information in documentation when it is needed for effort estimation and sprint planning [19,25,38,51]. Indeed, a recent survey reported that most of the participated agile developers considered that documented information is important when estimating effort and reestimation would be performed when the documented information was changed [38]. ...
... Hence, the team needs to analyze the documented information to understand the work to be done for the work item. Prior studies reported that the quality of documented information could impact the effort estimation accuracy [24,51,56,57]. Furthermore, the documented information may also be changed after the sprint plan is finalized, requiring the team to spend more effort in re-estimating and re-planning the sprint [19,33,38]. ...
In agile iterative development, an agile team needs to analyze documented information for effort estimation and sprint planning. While documentation can be changed, the documentation changes after sprint planning may invalidate the estimated effort and sprint plan. Hence, to help the team be aware of the potential documentation changes, we developed DocWarn to estimate the probability that a work item will have documentation changes. We developed three variations of DocWarn, which are based on the characteristics extracted from the work items (DocWarn-C), the natural language text (DocWarn-T), and both inputs (DocWarn-H). Based on nine open-source projects that work in sprints and actively maintain documentation, DocWarn can predict the documentation changes with an average AUC of 0.75 and an average F1-Score of 0.36, which are significantly higher than the baselines. We also found that the most influential characteristics of a work item for determining the future documentation changes are the past tendency of the developers and the length of description text. Based on the qualitative assessment, we found that 40%-68% of the correctly predicted documentation changes were related to scope modification. With the prediction of DocWarn, the team will be better aware of the potential documentation changes during sprint planning, allowing the team to manage the uncertainty and reduce the risk of unreliable effort estimation and sprint planning.
... Motivation: Accurate effort estimation requires an adequate understanding of a task [28,44,47,48]. While documentation can convey the information to understand the task [3,19,24], it has a lower priority than delivering working software in the Agile concept [16]. ...
... Motivation: Comprehensive documentation can be considered as an overhead in Agile [16,24]. On the other hand, inadequate documentation may lead to a misunderstanding of a task [29,44]. Hence, just-enough and just-in-time documentation would be suitable for Agile practices [21]. ...
... [...] the change of user stories/functional requirements changes the original estimation often." Since the effort estimates are used in iteration planning, such uncertainty may cause the plan to become unreliable [8,44]. Hence, to facilitate effort estimation and improve its accuracy, these useful types of information should be documented and reviewed. ...
... Motivation: Accurate effort estimation requires an adequate understanding of a task [28,44,47,48]. While documentation can convey the information to understand the task [3,19,24], it has a lower priority than delivering working software in the Agile concept [16]. ...
... Motivation: Comprehensive documentation can be considered as an overhead in Agile [16,24]. On the other hand, inadequate documentation may lead to a misunderstanding of a task [29,44]. Hence, just-enough and just-in-time documentation would be suitable for Agile practices [21]. ...
... [...] the change of user stories/functional requirements changes the original estimation often." Since the effort estimates are used in iteration planning, such uncertainty may cause the plan to become unreliable [8,44]. Hence, to facilitate effort estimation and improve its accuracy, these useful types of information should be documented and reviewed. ...
Effort estimation is an integral part of activities planning in Agile iterative development. An Agile team estimates the effort of a task based on the available information which is usually conveyed through documentation. However, as documentation has a lower priority in Agile, little is known about how documentation effort can be optimized while achieving accurate estimation. Hence, to help practitioners achieve just-enough documentation for effort estimation, we investigated the different types of documented information that practitioners considered useful for effort estimation. We conducted a survey study with 121 Agile practitioners across 25 countries. Our survey results showed that (1) despite the lower priority of documentation in Agile practices, 98% of the respondents considered documented information moderately to extremely important when estimating effort, (2) 73% of them reported that they would re-estimate a task when the documented information was changed, and (3) functional requirements, user stories, definition of done, UI wireframes, acceptance criteria, and task dependencies were ranked as the most useful types of documented information for effort estimation. Nevertheless, many respondents reported that these useful types of documented information were occasionally changing or missing. Based on our study results, we provide recommendations for agile practitioners on how effort estimation can be improved by focusing on just-enough documentation.
