[Paper Review] A Multi-dimensional Study of Requirements Changes in Agile Software Development Projects

Kashumi Madampe, Rashina Hoda+1 more|arXiv (Cornell University)|Dec 7, 2020

Software Engineering Research27 references4 citations

TL;DR

This study presents a multi-dimensional taxonomy of requirements changes (RCs) in agile software development through mixed-methods research with 50 practitioners. It reveals that RCs are predominantly functional, human-centric, and originate most frequently during daily standups, with agile teams using diverse handling techniques despite reluctance to accept changes—contrary to the belief that responding to change is the main driver for adopting agile methods.

ABSTRACT

Agile processes are now widely practiced by software engineering (SE) teams, and the agile manifesto claims that agile methods support responding to changes well. However, no study appears to have researched whether this is accurate in reality. Requirements changes (RCs) are inevitable in any software development environment, and we wanted to acquire a holistic picture of how RCs occur and are handled in agile SE teams in practice. We also wanted to know whether responding to changes is the only or a main reason for software teams to use agile in their projects. To do this we conducted a mixed-methods research study which comprised of interviews of 10 agile practitioners from New Zealand and Australia, a literature review, and an in-depth survey with the participation of 40 agile practitioners world-wide. Through this study we identified different types of RCs, their origination including reasons for origination, forms, sources, carriers, and events at which they originate, challenging nature, and finally whether agile helps to respond to changes or not. We also found that agile teams seem to be reluctant to accept RCs, and therefore, they use several mitigation strategies. Additionally, as they accept the RCs, they use a variety of techniques to handle them. Furthermore, we found that agile allowing better response to RCs is only a minor reason for practicing agile. Several more important reasons included being able to deliver the product in a shorter period and increasing team productivity. Practitioners stated this improves the agile team environment and thus are the real motivators for teams to practice agile. Finally, we provide a set of practical recommendations that can be used to better handle RCs effectively in agile software development environments.

Motivation & Objective

• To understand how requirements changes (RCs) originate, are communicated, and are handled in real agile software development projects.
• To investigate whether agile methods genuinely enable better response to RCs, as claimed by the Agile Manifesto.
• To identify the primary motivations for agile adoption, particularly whether responding to change is a key driver.
• To develop a comprehensive taxonomy of RCs in agile contexts, including types, sources, forms, and challenging metrics.
• To provide practical recommendations for agile teams to improve RC handling in practice.

Proposed method

• Conducted semi-structured interviews with 10 agile practitioners from New Zealand and Australia to inform the research design.
• Performed a systematic literature review to identify existing RC taxonomies and gaps in agile-specific research.
• Administered an in-depth global survey to 40 agile practitioners across Asia, Oceania, North America, and Europe.
• Collected data on RC types, sources, origins (including events like daily standups), forms, carriers, and reasons for change.
• Analyzed qualitative and quantitative data to develop a conceptual framework of RCs based on human and non-human aspects.
• Proposed metrics to measure the challenging nature of RCs, including change request arrival rate and requirements volatility.

Experimental results

Research questions

• RQ1 What are the primary types, sources, and forms of requirements changes in agile software development projects?
• RQ2 At which agile ceremonies or events do requirements changes most commonly originate?
• RQ3 How do agile teams perceive and handle requirements changes, and what strategies do they employ?
• RQ4 Is the ability to respond to change the main reason agile teams adopt agile methods, or are there other dominant motivators?
• RQ5 To what extent does agile methodology actually support better handling of requirements changes in practice?

Key findings

• The majority of requirements changes are functional in nature, with human-centric changes being more common than software-centric ones.
• Daily standups are the most frequent event where requirements changes originate, followed by customer-support discussions and sprint planning.
• Customers are the primary source of requirements changes, though other stakeholders such as product owners and team members also contribute.
• Agile teams often exhibit reluctance to accept new requirements, leading to the use of mitigation strategies such as backlog refinement and acceptance criterion clarification.
• Responding to change is not the primary motivator for agile adoption; instead, faster delivery and improved team productivity are cited as the main drivers.
• A significant proportion of requirements changes stem from software-centric reasons such as inadequate documentation, rushed analysis, and initial requirement errors, indicating potential misapplication of agile principles.