The Agile manifesto focuses on the delivery of valuable software. In Lean, the principles emphasise value, where every activity that does not add value is seen as waste. Despite the strong focus on value, and that the primary critical success factor for software intensive product development lies in the value domain, no empirical study has investigated specifically what value is. This paper presents an empirical study that investigates how value is interpreted and prioritised, and how value is assured and measured. Data was collected through semi-structured interviews with 23 participants from 14 agile software development organisations. The contribution of this study is fourfold. First, it examines how value is perceived amongst agile software development organisations. Second, it compares the perceptions and priorities of the perceived values by domains and roles. Third, it includes an examination of what practices are used to achieve value in industry, and what hinders the achievement of value. Fourth, it characterises what measurements are used to assure, and evaluate value-creation activities.

Context: The principal focus of lean is the identification and elimination of waste from the process with respect to maximizing customer value. Similarly, the purpose of agile is to maximize customer value and minimize unnecessary work and time delays. In both cases the concept of waste is important. Through an empirical study, we explore how waste is approached in agile software development organizations. Objective: This paper explores the concept of waste in agile/lean software development organizations and how it is defined, used, prioritized, reduced, or eliminated in practice Method: The data were collected using semi-structured open-interviews. 23 practitioners from 14 embedded software development organizations were interviewed representing two core roles in each organization. Results: Various wastes, categorized in 10 different categories, were identified by the respondents. From the mentioned wastes, not all were necessarily waste per se but could be symptoms caused by wastes. From the seven wastes of lean, Task-switching was ranked as the most important, and Extra-features, as the least important wastes according to the respondents’ opinion. However, most companies do not have their own or use an established definition of waste, more importantly, very few actively identify or try to eliminate waste in their organizations beyond local initiatives on project level. Conclusion: In order to identify, recognize and eliminate waste, a common understanding, and a joint and holistic view of the concept is needed. It is also important to optimize the whole organization and the whole product, as waste on one level can be important on another, thus sub-optimization should be avoided. Furthermore, to achieve a sustainable and effective waste handling, both the short-term and the long-term perspectives need to be considered. © 2018 Elsevier B.V.

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 agile practices for evaluating and improving current processes and ways-of-working, no method or practices for evaluating the backlog exists. To address this gap, the Backlog Assessment Method (BAM) was developed and applied in collaboration with Telenor Sweden. BAM enables agile organizations to assess backlogs, and assure that the backlog items are good-enough for their needs and well aligned with the decision process. The results from the validation show that BAM is feasible and relevant in an industrial environment, and it indicates that BAM is useful as a tool to perform analysis of items in a specific backlog. © The Author(s) 2019.

Requirements Engineering has attracted a great deal of attention from researchers and practitioners in recent years. This increasing interest requires academia to provide students with a solid foundation in the subject matter. In Requirements Engineering Education (REE), it is important to cover three fundamental topics: traditional analysis and modeling skills, interviewing skills for requirements elicitation, and writing skills for specifying requirements. REE papers report about using role playing as a pedagogical tool; however, there is a surprising lack of empirical evidence on its utility. In this paper we investigate whether a higher grade in a role playing project have an effect on students’ score in an individual written exam in a Requirements Engineering course. Data are collected from 412 students between the years of 2007 and 2014 at Lund University and Chalmers | University of Gothenburg. The results show that students who received a higher grade in the role playing project scored statistically significant higher in the written exam compared to the students with a lower role playing project grade. © 2016 Springer-Verlag London

Requirements engineering is recognized as a creative process where stakeholders jointly discover new creative ideas for innovative and novel products that eventually are expressed as requirements. This paper evaluates four different creativity techniques, namely Hall of Fame, Constraint Removal, Brainstorming, and Idea Box, using creativity workshops with students and industry practitioners. In total, 34 creativity workshops were conducted with 90 students from two universities, and 86 industrial practitioners from six companies. The results from this study indicate that Brainstorming can generate by far the most ideas, while Hall of Fame generates most creative ideas. Idea Box generates the least number of ideas, and the least number of creative ideas. Finally, Hall of Fame was the technique that led to the most number of requirements that was included in future releases of the products.

Effort estimation is a complex area in decision-making, and is influenced by a diversity of factors that could increase the estimation error. The effects on effort estimation accuracy of having obsolete requirements in specifications have not yet been studied. This study aims at filling that gap. A total of 150 students were asked to provide effort estimates for different amounts of requirements, and one group was explicitly told to disregard some of the given requirements. The results show that even the extra text instructing participants to exclude requirements in the estimation task, had the subjects give higher estimates. The effect of having obsolete requirements in requirements specifications and backlogs in software effort estimation is not taken into account enough today, and this study provides empirical evidence that it possibly should. We also suggest different psychological explanations to the found effect. © 2017 IEEE.

User eXperience (UX) is becoming increasingly important for success of software products. Yet, many companies still face various challenges in their work with UX. Part of these challenges relate to inadequate knowledge and awareness of UX and that current UX models are commonly not practical nor well integrated into existing Software Engineering (SE) models and concepts. Therefore, we present a conceptual UX-aware model of requirements for software development practitioners. This layered model shows the interrelation between UX and functional and quality requirements. The model is developed based on current models of UX and software quality characteristics. Through the model we highlight the main differences between various requirement types in particular essentially subjective and accidentally subjective quality requirements. We also present the result of an initial validation of the model through interviews with 12 practitioners and researchers. Our results show that the model can raise practitioners’ knowledge and awareness of UX in particular in relation to requirement and testing activities. It can also facilitate UX-related communication among stakeholders with different backgrounds. © IFIP International Federation for Information Processing 2016.

We performed a retrospective meeting at a case company to reflect on its decade of Software Process Improvement (SPI) activities for enhancing UX integration. We supported the meeting by a pre-generated timeline of the main activities. This approach is a refinement of a similar approach that is used in Agile projects to improve effectiveness and decrease memory bias of retrospective meetings. The method is evaluated through gathering practitioners' view using a questionnaire. We conclude that UX research and practice can benefit from the SPI body of knowledge. We also argue that a cross-section evidence-based timeline retrospective meeting is useful for enhancing UX work in companies, especially for identifying and reflecting on `organizational issues'. This approach also provides a cross-section longitudinal overview of the SPI activities that cannot easily be gained in other common SPI learning approaches.

Modern automotive embedded systems are developed by Original Equipment Manufacturers (OEM) together with multiple suppliers. A key problem for a supplier is to allocate an OEM’s requirements specification to their own subsystem design. This is a difficult manual task especially on complex systems and it requires expert knowledge about the system design. To address this problem, this paper presents a design science research to develop and evaluate a Requirements Allocation Assistant tool (RAA). The tool provides functionality to search through and filter requirements and system models to enable efficient requirements allocation even in the presence of complexity. RAA is built on top of the EATOP/Eclipse framework using EAST-ADL as system modelling language. The tool was evaluated and validated during a qualitative usability study with 17 engineers active in the Swedish automotive industry. Key findings are that searching is used to learn about a system, whereas filtering is used to narrow down a set of candidate elements of the system design. Engineers request further support in narrowing down a set of candidate elements and in checking that an allocation is correct.

As the software value chain is knowledge-based due to the high dependency on people, the lack of practice to manage knowledge as a resource might jeopardize its application in software development. The resource-based view of the firm provides a different perspective on the utilization of knowledge, assisting the identification of the Knowledge-Based Resources (KBRs) that allow a company to have a continuous readiness to quickly respond to the market changes. To understand how the KBRs support coordination in Agile Software Development (ASD), we applied a grounded theory approach, collecting data from 18 practitioners, coming from five companies. As results, we identified 44 KBRs that were grouped in the Continuous Assimilation Model (CHASM). They support coordination in ASD with continuous assimilation of change which is supported by people’s business analytic perspective and product systemic reasoning. The companies are able to utilize a certain level of their KBRs through social collaboration and team environment/settings. However, the inefficient utilization of these resources results in a significant knowledge loss. Furthermore, CHASM points out areas where practitioners can establish strategies based on the priorities that the companies give to the investigated KBRs, as well as a set of research opportunities for future investigation.