Abstract Agile software development often faces challenges related to architectural uncertainty. ArchHypo addresses this by providing a hypothesis-driven architecture technique that helps teams formulate, test, and learn from architectural assumptions iteratively. However, studies have shown that the lack of tooling integrated into everyday development workflows is a significant barrier to its adoption. In this paper, we present , a Trello plugin that integrates hypothesis-driven architectural reasoning directly into agile boards and validates the ArchHypo technique in real projects. The plugin uses an LLM and a RAG mechanism to help teams generate and classify architectural hypotheses, develop technical plans, and link actions to architecture decision patterns. By operating on top of an existing project management tool, aims to lower the adoption cost of hypothesis engineering and to make architectural decision processes more observable. We evaluated in a controlled study with software professionals working on a realistic architecture scenario. The results indicate that the plugin helps structure architectural discussions, reduces manual effort in documenting hypotheses and plans, clarifies procedural steps, and surfaces differences in risk perception within teams. Qualitative feedback suggests that AI-assisted support facilitates collaborative reasoning about architecture. Our findings show that LLM-based tools can effectively support hypothesis-driven architecture in agile settings and highlight design considerations for integrating such tools into existing workflows.

Abstract Agile Requirements Engineering (Agile RE) has been widely studied, but gaps remain regarding how user-centered research practices, specifically UX Research, are integrated into Agile RE. This paper investigates how UX Research is applied within Agile RE activities and identifies the positive and negative aspects of this integration. We conducted a multiple-case study with four distinct organizations, collecting data through interviews with 12 agile and UX professionals. Our results revealed that UX Research practices and tools are most frequently employed to discover requirements, both in organizations with and without UX professionals. However, the findings also indicate that although UX Research practices provide valuable input for requirements specification, there remains a need to better structure and communicate UX-related aspects so they become more visible to the agile team in all Agile RE activities. Our study contributes by discussing how UX Research practices and tools are employed across the stages of the Agile RE cycle, as well as the roles of the different stakeholders involved in these stages in different companies.

Longitudinal user experience research depends on capturing how perception evolves over time. Two practical problems limit current tools: participants reconstruct missed reports after the fact (“back-filling”), contaminating in-situ datasets with retrospective fabrications; and the qualitative volume produced by long studies exceeds what manual analysis can absorb. We present UXTracker , a web-based instrumentation platform engineered for longitudinal UX studies. The system makes three architectural commitments. First, all temporal and protocol decisions are taken on the server, so the client cannot bypass cooldowns or alter timestamps. Second, the data model separates the semantic definition of evaluation aspects from the storage of raw measurements, allowing researchers to add or modify evaluation dimensions during a study without database migrations. Third, qualitative interpretation is generated by a Large Language Model that operates strictly on a structured analytical context derived from server-side clustering, never on the raw dataset. We deployed UXTracker in a five-wave field study with 51 participants, distributed across in-situ and retrospective protocols, and collected 765 evaluation points on a third-party learning platform. The deployment demonstrates that the architecture concurrently enforces two temporal regimes within a single study, preserves the granularity differences expected between protocols, and produces grounded narrative interpretations.

Abstract Companies adopt agile methodologies for various reasons, primarily due to their adaptability to change and evolving business demands. In this context, addressing non-functional requirements (NFRs) may not always be a priority and can present challenges for agile teams. The focus on User Stories present in agile methods and tools often does not offer explicit alternatives for documenting NFRs. In this research, we perform a survey to explore five different strategies for documenting NFRs, to identify which fits better for different types of quality attributes and to understand the strengths and drawbacks of each one. As a result, the participants considered certain strategies as being more or less suitable for specifying different types of quality attributes. For instance, while Story Labeling was rarely recommended for security requirements, using Story Sub-sections or Verification Rules were highly recommended for this kind of quality attribute. Our results also evaluated the strategies considering several factors, such as the level of detail and requirement duplication. As a practical implication, the results of this work can provide guidance to agile development teams in choosing the most suitable alternative for each NFR documentation.

This paper presents a literature review on using agile for safety‐critical systems (SCSs). We have systematically selected and evaluated relevant literature to find out major areas of concern for adapting agile in the development of SCSs. In the paper, we have listed the most used Agile process models and reasons for their suitability for SCS, then we have outlined phases of the software development life cycle (SDLC) where changes are required to make an agile process suitable for the development of SCSs. Thirdly, we have elaborated on problems and other important aspects according to specific domains where agile is used for SCS. This paper serves as an insight into the latest trends and problems regarding the use of Agile process models to develop SCSs.

Abstract Software start-ups develop innovative software products working with disruptive technologies in time pressure and market-driven environment. Recently, User eXperience (UX) has become a hot topic that interests software teams of start-ups. However, software and UX professionals have struggled to match UX practices into the development activities, partially because of the lack of resources in the start-ups. This paper investigates how software start-ups handle UX activities during software development and how relevant UX is to these companies’ professionals. To achieve our aim, we surveyed 88 professionals who take part in software teams in star-ups, analyzing the responses using descriptive and statistical methods. Our results reveal that regardless of having or not a UX position in the start-up, UX practices are spread in different software development phases and not fitting into them. Results also show although professionals consider UX relevant and recognize important skills to perform UX activities, some obstacles hinder the effective use of UX in software start-ups. From the survey results, we identified a set of challenges to be overcome in consolidating the UX work in software start-ups. By diagnosing the UX state-of-practice in start-up scenarios and identifying such challenges, our work contributes to provides relevant insights to further academic and practical studies in this field.

Software analytics supports data-driven decision making, which allows software practitioners to leverage valuable insights from software data to improve their processes and many quality aspects of the software.In this paper, we present an artifact designed from a set of patterns to support agile teams to plan and manage software analysis activities, named Software Analytics Canvas.Further, we report the study undertaken to evaluate the ease of use and the utility of our canvas from the practitioners' viewpoint, and a participatory design session carried out to collect information about possible artifact improvements.In general, subjects found the artifact useful, but some of them reported difficulties in learning and understanding how to use it.In the participatory design, they pointed out improvement points and a new layout for the canvas components.The results of both studies helped us refine the proposed artifact, improving both the terms used in each element and the layout of the blocks to make more sense for its users.

Abstract Test-Driven Development (TDD) is one of the most popular agile practices among software developers. To investigate the software developers’ initial perceptions when applying TDD, we have performed an exploratory study. This study was carried out with participants who had about ten years of professional experience (on average), the majority of whom with no experience using TDD. The study is in the context of an agile project course at the postgraduate level of a research institute. Participants individually developed medium size projects addressed to different domains and using different programming languages. Through a structured questionnaire with open and semi-open questions, we collected information on TDD effects such as the perceived benefits, encountered difficulties, and developer’s opinion about the quality improvement of the software. Afterward, we conducted a thematic analysis of the qualitative data. Most participants noticed improvements in code quality, but few have a more comprehensive view of the effects of TDD on software design. Our findings suggest that after overcoming the initial difficulties to understand where to start, and know how to create a test for a feature that does not yet exist, participants gain greater confidence to implement new features and make changes due to broad test coverage.