\section{Introduction}\label{sec:Intro}}
\input{sections/introduction}
\else
\fi

\label{sec:motivation}


\section{Research Questions}

\input{sections/RQs}
\label{sec:RQs}


\input{sections/method}
\label{sec:Mtd}

\section{Results}
\label{sec:Results}

    \subsection{What  are  the  Types  of  Requirements  Changes Agile Teams Face? (RQ1)}
   
    \label{sec:type}
    \input{sections/type}
    
        \subsection{Why are Requirements Changes Needed? (RQ2.1)}
        \label{sec:reason}
        \input{sections/reason}
        
        \subsection{What are the Sources of Requirements Changes? [Artefacts] (RQ2.2) }
        \label{sec:source}
        \input{sections/source}
        
        \subsection{Where do Requirements Changes Originate? [Events] (RQ2.3)}
        \label{sec:where}
        \input{sections/where}
        
        \subsection{Who brings Requirements Changes to the Team? [Carriers] (RQ2.4)}
        \label{sec:who}
        \input{sections/who}
        
        \subsection{In Which Forms are Requirements Changes Documented? (RQ2.5)}
        \label{sec:form}
        \input{sections/form}
    
    \subsection{How Challenging are the Requirements Changes? (RQ3)}
    \label{sec:challenge}
    \input{sections/challenge}
    
    \subsection{Does Agile Help in Responding to Requirements Changes? (RQ4)}
    \label{sec:agile_helps}
    \input{sections/agilehelps}
    
\section{Discussion}
\label{sec:discussion}
    \input{sections/discussion}
    
\section{Recommendations}
    \label{sec:recommendations}
    \input{sections/recommendations}


\section{Related Work}
\label{sec:RW}
\input{sections/relatedwork}


\section{Conclusion}
\label{sec:conclusion}
\input{sections/conclusion}

\section*{Acknowledgement}
This work is supported by a Monash Faculty of IT scholarship. Grundy is supported by ARC Laureate Fellowship FL190100035. Also, our sincere gratitude goes to \emph{Agile Alliance} and all the participants who took part in this study.

\bibliographystyle{ieeetr}


\subsection{Research Questions}

We wanted to gain a comprehensive understanding of RCs in agile and to understand whether agile helps to respond to RCs. We derived the following research questions to guide our study with the help from our interview-based preliminary study (Section \ref{sec:interview}) findings and existing literature.

    \textbf{RQ1. What are the types of requirements changes agile teams face?}
    Several types of RCs were found from our preliminary study data analysis. We wanted understand these more comprehensively by using a larger sample of real world agile software development teams.
    
    \textbf{RQ2. Origin of requirements changes}
    We wanted to know why, what, when, and who are involved in producing RCs in an agile software project. We formulated the following sub-RQs:
\begin{itemize}
   
        \item \textit{RQ2.1. Why are RCs needed?}
       
    
        \item \textit{RQ2.2. What are the sources and frequency of RCs?}
       
        
        \item \textit{RQ2.3. Where do the RCs originate?}
       
        Apart from typical agile ceremonies, our preliminary study proposed that RCs originate after releasing the complete product as well. We wondered about other times and reasons where RCs originate as well as the frequency of the origin at the particular ceremony/event.
        
        \item \textit{RQ2.4. Who brings RCs and how often?}
        Not only the customer, but also other stakeholders bring RCs to the team according to our preliminary findings. We used this question to confirm the carriers we found and how often they bring RCs to the team.
        
        \item \textit{RQ2.5. In which forms are requirements changes documented?}
        Given that various ways exist to document requirements changes, we wanted to know the forms that agile teams use to document RCs.
    \end{itemize}
    
     \textbf{RQ3. How challenging are the requirements changes to handle?}
    Requirements changes  can be very challenging for all software development teams. We wanted to understand how challenging are RCs to teams using a set of metrics we defined to measure the nature of these challenges.
    
    \textbf{RQ4. Does Agile help to better respond to requirements changes?}
    As agile software development is supposedly popular because of its ability to allow a team to better respond to RCs, we wanted to know in what ways agile actually helps the teams  when handling RCs.
    

\subsection{Requirements Changes Taxonomies in Traditional Software Development}






McGee and Greer's studies \cite{McGee2011SoftwareStudy,McGee2009ATaxonomy} resulted in an RC taxonomy for software development based on sources categorized as RCs originating from \textit{market, organization, project vision, specification,} and \textit{solution}. Their study found that higher cost and value changes originate mostly from \textit{organization} and \textit{vision} \textit{sources} and these sources involve cooperation of stakeholder groups with less control than the RCs originating from the sources: \textit{specification} and \textit{solution}. Additionally, except for RCs originating from market, RCs originating from other sources showed a considerable amount of difference in cost, value to the customer, and management considerations. They also found the triggers and uncertainties for each classified source. Furthermore, findings of these studies indicate that using the given taxonomy will help to manage RCs, understand RCs, and gain risk visibility.



Nurmuliani et al.'s work \cite{Nurmuliani2004AnalysisCycle}, presents types of RCs, reasons of they originate, and sources from which RCs originate as its key findings. They categorized types of RCs as additions, deletions, and modifications of requirements. Also, they found that defect fixing, missing requirements, functionality enhancement, product strategy, design improvement, scope reduction, redundant functionality, obsolete functionality, erroneous requirements, resolving conflicts, and clarifying requirements as the reasons of why RCs originate. As sources of RCs, they found defect reports, engineering's calls, project management consideration, marketing group, developers' detailed analysis, design review feedback, technical team discussion, functional specification review, feature proposal review, and  customer-support discussions. In addition to the taxonomy based on type, reasons, and sources of RC, they also provided change request arrival rate, and requirements volatility measure which is the ratio of number of RC to the total number of RC over a certain period of time (during development phase).

Harker et al. found mutable, emergent, consequential, adaptive, and migration as RCs in their classification \cite{Harker1993TheEngineering}. They also found environmental turbulence, stakeholder engagement in requirements elicitation, system and user development, situation action and task variation, and constraints of planned organizational development as the \textit{origins} of RCs.



Inpirom and Prompoon classified RCs according to analysis and design of software artefacts \cite{Inpirom2013DiagramUML}. Their taxonomy is based on unified modeling language including the most commonly used diagrams: use case diagram, class diagram, and sequence diagram. In addition, they mentioned that most research focused on impact of RCs on source code but impact of RCs on diagrams are also required. Likewise, Basirati et al.'s study \cite{Basirati2015UnderstandingStudy} indicate that, RCs impact artefacts. Therefore, they explored the changes in use cases and their further analysis of problematic changes resulted in a taxonomy of RC. In addition, they also found the local and temporal dispersion of RC as difficult and risky.

The only taxonomy we found for RCs in agile software development was Saher et al.'s literature based study \cite{Saher2018}. They described their taxonomy in terms of \textit{time of change, type, reason,} and \textit{origin} of RC. However, out of the 9 studies they used to build the taxonomy, 8 use traditional software development  while only one study actually focused on agile methods. This leaves a gap in the research where a taxonomy of RC in agile is necessary where responding to RCs is paramount and in this paper we have filled that gap.


\begin{table*}[t]
\caption{Comparison of Our Study with Related Work}
\label{tab:gap}
\centering
\resizebox{1.5\columnwidth}{!}{%
\begin{tabular}{@{}lllllllll@{}}
\toprule
\textbf{}            & \textbf{Type} & \textbf{Reason} & \textbf{Source} & \textbf{\begin{tabular}[c]{@{}l@{}}Ceremony/\\ Event\end{tabular}} & \textbf{Carrier} & \textbf{Form} & \textbf{\begin{tabular}[c]{@{}l@{}}Impact on \\ Artefacts\end{tabular}} & \textbf{\begin{tabular}[c]{@{}l@{}}Challenging \\ Metrics\end{tabular}} \\ \midrule
\multicolumn{9}{l}{\textbf{Requirements Changes Taxonomies in Traditional Software Development:}}                                                                                                                                                                                                                                    \\ \midrule
McGee and Greer \cite{McGee2009ATaxonomy, McGee2011SoftwareStudy}     &               &                 & \checkmark          &                                                                    &                  &               &                                                                         &                                                                         \\
Nurmuliani et al. \cite{Nurmuliani2004AnalysisCycle}   & \checkmark             & \checkmark              & \checkmark              &                                                                    &                  &               &                                                                         &                                                                         \\
Harker et al. \cite{Harker1993TheEngineering}       & \checkmark             &                 &                 &                                                                    &                &               &                                                                         &                                                                         \\
Iniprom and Prompoon \cite{Inpirom2013DiagramUML} &               &                 &                 &                                                                    &                  &               & \checkmark                                                                       &                                                                         \\ \midrule
\multicolumn{9}{l}{\textbf{Requirements Changes Taxonomies in Agile Software Development:}}                                                                                                                                                                                                                                          \\ \midrule
Saher et al. \cite{Saher2018}        & \checkmark             &  \checkmark             & \checkmark               &                                                                    &                  &               &                                                                         &                                                                         \\
\rowcolor[HTML]{EFEFEF} 
\textbf{Our study}   & \checkmark    & \checkmark      & \checkmark      & \checkmark                                                         & \checkmark       & \checkmark    & \textbf{}                                                               & \checkmark                                                              \\ \bottomrule
\end{tabular}%
}
\end{table*}

\section{Study Design}
\label{sec:SD}

The mixed-methods approach used for our study is outlined in Fig. \ref{fig:method}. This study was conducted with the participation of agile practitioners across the world. First we conducted an interview-based preliminary study to understand the landscape of RCs in agile projects. Findings of the preliminary interviews were combined with a literature review to construct the survey questionnaire. Once the questionnaire was finalized, a pilot run was conducted before distributing the survey to the agile community in the software development industry world-wide.

\subsection{Interview-Based Preliminary Study and Literature Review}\label{sec:interview}
We conducted 10 semi-structured (N=7 face-to-face, N=3 online) interviews with agile practitioners in New Zealand (N=8) and Australia (N=2). Each interview lasted 50-60 minutes. The participants had 19.75 years of mean total experience in software development  (min. total experience=2 years; max. total experience=56 years) and 7.26 years of mean total agile experience (min. agile experience=1 year; max. agile experience=18 years). Their job roles were Scrum Master (N=5), Business Analyst (N=2), Manager (N=2), Tester (N=1), Architect (N=1), Senior Consultant (N=1) and Head of Global Projects (N=1). Some participants played more than one role. The participants had experience in Scrum (N=10), XP(N=5), Scrum XP combo (N=4), Kanban (N=8), Feature Driven Development (N=3), Spotify (N=2), Dynamic Systems Development (N=1), and Company based Method (N=1).

We analysed the collected data from the interviews using Grounded Theory (GT) analysis procedures including open coding and constant comparison \cite{Strauss1998BasicsTechniques.}. The findings resulted in categories: \emph{reasons, types, sources, carriers}, and \emph{ceremonies/events}. 

We then conducted a literature review and combined findings from the interview-based study with closely related work of McGee and Greer's \cite{McGee2009ATaxonomy} and Nurmuliani et al.'s \cite{Nurmuliani2004AnalysisCycle} (summarized in Section \ref{sec:RW}) to develop an in-depth survey questionnaire. The survey consisted of 3 open-ended and 37 closed-ended questions. Furthermore, each close-ended question included one open-ended ``Other'' option as well for the participants to enter any other responses they wanted to include apart from the options we provided for the particular question. We followed Kitchenham et al.'s \cite{Kitchenham2002PreliminaryEngineering, Kitchenham2008PersonalSurveys} and Punter et al.'s \cite{Punter2003ConductingEngineering} guidelines to design the survey. We followed Smith et al.'s work \cite{Smith2013ImprovingSurveys} on ``improving developer participation rates in surveys'' to support survey distribution. Table \ref{tab:survey_questions} shows sample questions for each type. 

\begin{table*}[!t]
\centering
\caption{Sample Survey Questions}
\label{tab:survey_questions}
\begin{tabular}{@{}ll@{}}
\toprule
\multicolumn{1}{c}{\textbf{Question}}                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              & \textbf{Question Type    }                                                                                 \\ \midrule
\begin{tabular}[c]{@{}l@{}}A requirements change can occur due to,\\ $<$Bug (Error arising in the codebase), Design improvement, Erroneous requirements, Functionality enhancement, \\ Missing requirements, Need for refactoring, Obsolete functionality, Outstanding technical debt, Product strategy, \\ Redundant functionality, Requirements clarification, Resolving conflicts, Scope reduction, Other$>$\end{tabular}                                                                                                                                                                                                                                                                                             & \begin{tabular}[c]{@{}l@{}}Close-ended (Multiple \\ selection with one\\ text entry)\end{tabular} \\ \\


Thinking about the specific (current/past) project, typically requirements changes make up to what percentage of \\ the total work items? \\
$<$0\% (We don't receive any requirements changes), Less than 25\%, 26-50\%, 51-75\%, More than 75\%$>$ & Close-ended (Single selection) \\ \midrule
\begin{tabular}[c]{@{}l@{}}\textit{If the participant's response to the question on the amount of requirements changes he/she received as a percentage of}\\\textit{ total work items indicated more than 50\%:}\\ It looks like you receive a considerable amount of requirements changes. \\ Does using agile methods enable you to respond to these requirement changes? If yes, how? \\ If not, why not?\\ \\ I\textit{f the participant's respond to the question on the amount of requirements changes he/she received} \\ \textit{as a percentage of total work items indicated less than 50\%:}\\ It looks like you don't receive a lot of requirements changes. So, why do you think practicing \\ agile is appropriate for your project?\end{tabular} & Open-ended                                                                                        \\ \bottomrule
\end{tabular}
\end{table*}

\subsection{Data Collection}
After the survey questionnaire was finalized, we sent the survey to 2 Research Fellows and 2 Ph.D. students in Australia and New Zealand who had software development industrial experience. This pilot run helped us to get feedback in terms of time for completion and any other aspects such as wording. We then distributed the survey via:

\begin{itemize}
    \item posting the survey link on professional software development groups and in our profiles in social media such as \emph{LinkedIn, Twitter,} and \emph{Facebook};
    \item sending the survey link to our known contacts in the software development industry; and
    \item \emph{Agile Alliance} posting the survey link on their \emph{LinkedIn, Twitter,} and \emph{Facebook} channels.
\end{itemize}

The survey was available online for a period of a month. 106 participants had started the survey and 42 participants fully completed the survey. Two responses from the completed responses were removed due to their feedback given at the end of the questionnaire mentioned that they completed the survey only to see what the questions were and that their answers were arbitrary.
We targeted only agile practitioners. We confirmed this by the participants' demographics and their self confirmation on practicing agile prior to begining the survey. As given in Table \ref{tab:participant_demograhics}, participants of our survey included developers, agile coaches/scrum masters, testers, business analysts, product owners, tech leads, and managers.

\begin{table*}[t]
\centering
\caption{Demographics of the Survey Participants (P\#: Participant ID; XT: Total Experience in Software Development Industry in Years; XTA: Total Experience in Agile in Years; XA: Experience with Agile Software Development Methods; SL: Sri Lanka; Au: Australia; USA: United States of America; CO: Colombia; NZ: New Zealand; SG: Singapore; UK: United Kingdom; NL: Netherlands; In: India)}
\label{tab:participant_demograhics}
\resizebox{\textwidth}{!}{%
\begin{tabular}{@{}rlllrrll@{}}
\toprule
\multicolumn{1}{l}{\textbf{P\#}} & \textbf{Age Group} & \textbf{Gender} & \textbf{Country} & \multicolumn{1}{l}{\textbf{XT}} & \multicolumn{1}{l}{\textbf{XTA}} & \textbf{XA}                                                                                                                                                                                                                              & \textbf{Role in the Project}                                                                             \\ \midrule
P1                                & 26 - 30            & Male            & SL               & 2.5                             & 2                                & Scrum, Kanban, ScrumBan                                                                                                                                                                                                                                                                  & Developer                                                                                                \\
P2                                & 20 - 25            & Male            & SL               & 2.5                             & 2.5                              & Scrum                                                                                                                                                                                                                                                                                    & Developer                                                                                                \\
P3                                & 26 - 30            & Female          & SL               & 2                               & 2                                & Scrum                                                                                                                                                                                                                                                                                    & Agile Coach/Scrum Master, Developer                                                                      \\
P4                                & 26 - 30            & Male            & SL               & 3.5                             & 3.5                              & Scrum, Kanban                                                                                                                                                                                                                                                                            & Developer                                                                                                \\
P5                                & 26 - 30            & Female          & SL               & 2                               & 1                                & Scrum                                                                                                                                                                                                                                                                                    & Tester                                                                                                   \\
P6                                & 26 - 30            & Female          & SL               & 2                               & 2                                & Scrum                                                                                                                                                                                                                                                                                    & Tester                                                                                                   \\
P7                                & 26 - 30            & Male            & SL               & 3                               & 1                                & Scrum                                                                                                                                                                                                                                                                                    & Developer                                                                                                \\
P8                                & 20 - 25            & Female          & AU               & 2                               & 1                                & Scrum, XP                                                                                                                                                                                                                                                                                & Developer                                                                                                \\
P9                                & 20 - 25            & Female          & SL               & 2.5                             & 2.5                              & Scrum, Feature Driven Development                                                                                                                                                                                                                                                        & Tester                                                                                                   \\
P10                               & 20 - 25            & Male            & SL               & 5                               & 8                                & \begin{tabular}[c]{@{}l@{}}Scrum, XP, Scrum XP combo, Kanban, Crystal, \\ Feature Driven Development, \\ Dynamic System Development\end{tabular}                                                                                                                                            & Agile Coach/Scrum Master                                                                                 \\
P11                               & 26 - 30            & Female          & SL               & 3.5                             & 2.5                              & Scrum                                                                                                                                                                                                                                                                                    & Tester                                                                                                   \\
P12                               & 26 - 30            & Female          & SL               & 2.5                             & 2.5                              & Scrum                                                                                                                                                                                                                                                                                    & Business Analyst                                                                                         \\
P13                               & 41- 45             & Male            & USA              & 20                              & 10                               & Not specified                                                                                                                                                                                                                                                                        & Developer                                                                                                \\
P14                               & 31 - 35            & Female          & CO               & 9                               & 3.5                              & Scrum                                                                                                                                                                                                                                                                                    & Business Analyst                                                                                         \\
P15                               & 31 - 35            & Male            & SL               & 6                               & 1                                & Scrum, Kanban                                                                                                                                                                                                                                                                            & Developer                                                                                                \\
P16                               & 31 - 35            & Male            & SL               & 10                              & 10                               & Scrum                                                                                                                                                                                                                                                                                    & \begin{tabular}[c]{@{}l@{}}Agile Coach/Scrum Master, \\ Product Owner, Developer, Tech Lead\end{tabular} \\
P17                               & 26 - 30            & Male            & AU               & 4                               & 2                                & Scrum                                                                                                                                                                                                                                                                                    & Developer                                                                                                \\
P18                               & 26 - 30            & Female          & SL               & 2.5                             & 2.5                              & Scrum                                                                                                                                                                                                                                                                                    & Agile Coach/Scrum Master                                                                                 \\
P19                               & 31 - 35            & Male            & NZ               & 10                              & 7                                & Scrum, XP, Kanban                                                                                                                                                                                                                                                                        & Agile Coach/Scrum Master                                                                                 \\
P20                               & 46 - 50            & Male            & AU               & 16                              & 5                                & Scrum                                                                                                                                                                                                                                                                                    & Product Owner                                                                                            \\
P21                               & 26 - 30            & Female          & SL               & 2                               & 2                                & Scrum                                                                                                                                                                                                                                                                                    & Tester                                                                                                   \\
P22                               & 26 - 30            & Female          & AU               & 3                               & 2                                & Scrum, Kanban                                                                                                                                                                                                                                                                            & Developer                                                                                                \\
P23                               & 36 - 40            & Male            & SL               & 12                              & 8                                & Kanban                                                                                                                                                                                                                                                                                   & Developer                                                                                                \\
P24                               & 26 - 30            & Male            & SL               & 5                               & 2.5                              & Scrum, Kanban, ScrumBan                                                                                                                                                                                                                                                                  & Tester                                                                                                   \\
P25                               & Above 50           & Male            & AU               & 30                              & 15                               & \begin{tabular}[c]{@{}l@{}}Feature Driven Development, \\ Dynamic System Development, \\ Primarily the Values \& Principles of \\ The Agile Manifesto \\ \end{tabular} & Manager                                                                                                  \\
P26                               & 26 - 30            & Female          & NZ               & 1                               & 1                                & Scrum                                                                                                                                                                                                                                                                                    & Tester                                                                                                   \\
P27                               & 31 - 35            & Male            & SL               & 8                               & 1                                & Scrum, Kanban                                                                                                                                                                                                                                                                            & Developer                                                                                                \\
P28                               & 20 - 25            & Male            & AU               & 30                              & 20                               & Scrum, XP, Scrum XP combo, Kanban                                                                                                                                                                                                                                                        & Product Owner, Manager                                                                                   \\
P29                               & 26 - 30            & Female          & SG               & 2                               & 2                                & Scrum                                                                                                                                                                                                                                                                                    & Developer                                                                                                \\
P30                               & 26 - 30            & Male            & SG               & 2                               & 1                                & Crystal                                                                                                                                                                                                                                                                                  & Developer                                                                                                \\
P31                               & 31 - 35            & Male            & UK               & 3                               & 3                                & Scrum, Kanban, SAFe                                                                                                                                                                                                                                                                      & Business Analyst                                                                                         \\
P32                               & 41- 45             & Male            & USA              & 23                              & 15                               & Scrum, XP, Kanban                                                                                                                                                                                                                                                                        & Developer, Manager                                                                                       \\
P33                               & 36 - 40            & Male            & NL               & 10                              & 5                                & Scrum                                                                                                                                                                                                                                                                                    & Product Owner                                                                                            \\
P34                               & 31 - 35            & Female          & SL               & 9                               & 5                                & Scrum, Kanban                                                                                                                                                                                                                                                                            & Agile Coach/Scrum Master                                                                                 \\
P35                               & 20 - 25            & Female          & IN               & 3.5                             & 3                                & Scrum, XP, Kanban, Feature Driven Development                                                                                                                                                                                                                                            & Developer                                                                                                \\
P36                               & 31 - 35            & Male            & SL               & 9                               & 4                                & Scrum                                                                                                                                                                                                                                                                                    & Tester                                                                                                   \\
P37                               & 41- 45             & Female          & NZ               & 25                              & 5                                & Scrum, Kanban                                                                                                                                                                                                                                                                            & Product Owner                                                                                            \\
P38                               & 31 - 35            & Male            & SL               & 8.5                             & 4                                & Scrum, Kanban, Feature Driven Development                                                                                                                                                                                                                                                & Agile Coach/Scrum Master                                                                                 \\
P39                               & 31 - 35            & Female          & IN               & 13                              & 2                                & Scrum                                                                                                                                                                                                                                                                                    & \begin{tabular}[c]{@{}l@{}}Agile Coach/Scrum Master, \\ Product Owner\end{tabular}                       \\
P40                               & 26 - 30            & Male            & SL               & 4                               & 4                                & Scrum                                                                                                                                                                                                                                                                                    & Developer                                                                                                \\ \bottomrule
\end{tabular}%
}
\end{table*}

Participants had 1 to 30 years of total experience in the software development industry and their agile experience ranged from 1 - 20 years in Scrum, Kanban, ScrumBan, XP, Scrum XP combo, Crystal, Feature Driven Development, Dynamic System Development, and SAFe. One of the participants (P13) had not mentioned the agile methods that he had experience in and another participant (P28) had selected his age group as 20-25 even though his total experience in software development industry was indicated as 30 years. As we did not collect any contact information of the participants, we were not able to follow up to find the true information in both cases.

The majority of the participants (N=26) were from Asia (N(Sri Lanka)=22, N(Singapore)=2, N(India)=2). 9 participants were from Oceania (N(Australia)=6, N(New Zealand)=3), 3 participants were from North America (N(United States of America)=2, N(Colombia)=1), and 2 participants were from Europe (N(United Kingdom)=1, N(Netherlands)=1).


\subsection{Data Analysis}
Quantitative data were analysed using \emph{Qualtrics} and \emph{Microsoft Excel} while qualitative data were analysed using \emph{Microsoft Excel} and \emph{MAXQDA}. Qualitative data followed the coding approach given in GT \cite{Strauss1998BasicsTechniques.} where concepts and categories were generated through constant comparison across different dimensions such as separate/hybrid and degree of proper use.



An example of the GT analysis is shown in Fig. \ref{fig:GT}. The \textbf{codes: prioritization, regular customer feedback, frequent team meetings, releasing beta versions of the software,} and \textbf{short and small targets with deadlines} led to the \textbf{concept: agile practices}, and the \textbf{codes: micro-management, and defining requirements in advance} led to the \textbf{concept non-agile practices}. These concepts led to the \textbf{sub category: practices} through its \textbf{dimension of separate/hybrid use (axial coding)}. Finally the \textbf{category: requirements changes origination strategies} was emerged from the sub category.

\begin{figure}[b]
    \centering
    \includegraphics[width=\columnwidth]{figures/method/GT.pdf}
    \caption{Emergence of Category ``Requirements Changes Origination Mitigation Strategies'' using Theory Data Analysis}
    \label{fig:GT}
\end{figure}


\subsubsection{Factors Intensifying the Challenging Nature of Requirements Changes}
Apart from complexity, cascading impact, size, effort required, definition, priority, and access to customer given in the conceptual framework, our further analysis resulted in identifying the challenging nature of RCs become intensified due to \textit{forced cross-functionality, organizational needs, complex development,} and \textit{time-boxed nature of agile} as summarized in Table \ref{tab:other_challenges}. However, improvements can be done within the team so as to avoid such discomforts.
     
     \begin{table}[]
\caption{Preliminary Suggestions on Factors Intensifying the Challenging Nature of Requirements Changes}
\label{tab:other_challenges}
\resizebox{\columnwidth}{!}{%
\begin{tabular}{@{}l@{}}
\toprule
\textbf{Requirements Changes Become Challenging Further Due to} \\ \midrule
\rowcolor[HTML]{C0C0C0} 
\textbf{Forced Cross-Functionality}                                                   \\
Business analysts forcing to complete the development           \\
Lack of analysis by developers                                  \\
Developers being disengaged from thinking                       \\
\rowcolor[HTML]{C0C0C0} 
\textbf{Organizational Needs       }                                     \\
Company policies                                                \\
Regulatory                                                      \\
Legal aspects                                                   \\
Service level agreements                                        \\
Business rules                                                  \\
\rowcolor[HTML]{C0C0C0} 
\rowcolor[HTML]{C0C0C0} 
\textbf{Time-boxed nature of agile }                                     \\ \bottomrule
\end{tabular}%
}
\end{table}

    Business analysts forcing to complete the development, lack of analysis by developers, and developers being disengaged from thinking sums up to forced cross-functionality:
    \begin{center}
    \textit{``..disengaged from thinking \& expecting others to do the thinking \& exploring of expected business value (“I just want to write code, man!”)'' - P25 [Manager]}
    \end{center}

Organizational needs such as company policies, regulatory, legal aspects, service level agreements, and business rules, which are not under the control of the agile team make the RCs more challenging to the team. Furthermore, we found that time-boxed nature of agile also can worsen the situation. However, these concepts are not matured enough as these were mentioned only by one or two participants. Therefore, it is required to study them more on this in the future.


\subsubsection{Other Reasons for Requirements Changes Origination}
Apart from the above mentioned reasons, we found the following additional reasons reported for the origination of RCs in open-ended responses:

\begin{itemize}
    \item Inadequate communication
    \item Inadequate documentation
    \item Rushed analysis when defining requirements
    \item Wrong set of initial requirements
\end{itemize}

\textbf{Inadequate communication:}
\textit{``Individuals and interactions over processes and tools''} is a core value in agile \cite{Beck2001ManifestoDevelopment}. In order to have better interactions, better communication is expected to prevail. However, if communication among the stakeholders is at an inadequate level, origination of RCs can be expected as reported by the participants. In this case, it is required for the team to be mindful and overcome this issue so that unexpected RCs do not originate.

\textbf{Inadequate documentation:}
\textit{Even though agile encourages ``working software over comprehensive documentation''} \cite{Beck2001ManifestoDevelopment}, as reported by the participants, inadequate documentation is a reason for some RC origination. Documenting \emph{the requirements} to a sufficient level is therefore recommended.

\textbf{Rushed analysis when defining requirements:}
Even though the root causes are unknown for rushing the analysis of requirements, it causes the RCs to originate later:
\begin{center}
    \textit{``The people defining what the software should do have either rushed their analysis...`` - P25 [Manager]}
\end{center}

\textbf{Wrong set of initial requirements:}
Having the wrong set of initial requirements unsurprisingly also causes RCs. RCs are necessary to redirect the software development in the correct direction so as to meet the actual customer requirements:
\begin{center}
    \textit{``If the requirements change, that means the previous set of requirements was wrong, and who wants to build the wrong thing?'' - P32 [Developer/Manager]''}
\end{center}
\subsubsection{Sources of Functional Requirements Changes}


\begin{table*}[t]
\fontsize{14}{16}\selectfont
\caption{Sources of Requirements Changes (\includegraphics[scale=0.2]{figures/Scale.pdf}; FR: Functional Requirement; NFR: Non-Functional Requirement)}
\label{tab:source}
\resizebox{\textwidth}{!}{%
\begin{tabular}{@{}llllllllllllllllllllll@{}}
\toprule
\multicolumn{1}{c}{\textbf{}}                & \multicolumn{3}{c}{\textbf{Defect Reports}}                                                             & \multicolumn{3}{c}{\textbf{\begin{tabular}[c]{@{}c@{}}Individual Developer's \\ Detailed Analysis\end{tabular}}} & \multicolumn{3}{c}{\textbf{\begin{tabular}[c]{@{}c@{}}Product Backlog\\ Reviews\end{tabular}}}          & \multicolumn{3}{c}{\textbf{\begin{tabular}[c]{@{}c@{}}Technical Team \\Discussions\end{tabular}}}                                                 & \multicolumn{3}{c}{\textbf{User Reviews}}                                                               & \multicolumn{3}{c}{\textbf{Marketing Team}} & \multicolumn{3}{c}{\textbf{\begin{tabular}[c]{@{}c@{}}User-Support \\Discussions\end{tabular}}} \\ \midrule
\multicolumn{22}{l}{\textbf{Functional Requirements Changes}}    \\ \midrule
FR Addition                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsFRA.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualFRA.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBFRA.pdf}}                                                                          & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamFRA.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsFRA.pdf}}                                                            & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamFRA.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportFRA.pdf}}   \\
FR Modification                              & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsFRM.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualFRM.pdf}}                                                                                     & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBFRM.pdf}}                                                                         & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamFRM.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsFRM.pdf}}                                                             & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamFRM.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportFRM.pdf}}    \\
FR Deletion                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsFRD.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualFRD.pdf}}                                                                                     & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBFRD.pdf}}                                                                   & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamFRD.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsFRD.pdf}}                                                                   & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamFRD.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportFRD.pdf}}   \\
FR Bug Fix                                   & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsFRBF.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualFRBF.pdf}}                                                                            & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBFRBF.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamFRBF.pdf}}                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsFRBF.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamFRBF.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportFRBF.pdf}}    \\
FR Combination                               & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsFRC.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualFRC.pdf}}                                                                                     & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBFRC.pdf}}                                                                      & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamFRC.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsFRC.pdf}}                                                                & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamFRC.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportFRC.pdf}}  \\ \midrule
\multicolumn{22}{l}{\textbf{Non-Functional Requirements Changes}}    \\ \midrule
NFR Addition                                 & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsNFRA.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualNFRA.pdf}}                                                                                     & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBNFRA.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamNFRA.pdf}}                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsNFRA.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamNFRA.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportNFRA.pdf}}   \\
NFR Modification                             & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsNFRM.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualNFRM.pdf}}                                                                                     & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBNFRM.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamNFRM.pdf}}                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsNFRM.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamNFRM.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportNFRM.pdf}}    \\
NFR Deletion                                 & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsNFRD.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualNFRD.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBNFRD.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamNFRD.pdf}}                                                            & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportNFRD.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamNFRD.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportNFRD.pdf}}    \\
NFR Bug Fix                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsNFRBF.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualNFRBF.pdf}}                                                                                 & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBNFRBF.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamNFRBF.pdf}}                                                      & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsNFRD.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamNFRBF.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportNFRBF.pdf}} \\
NFR Combination                              & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsNFRC.pdf}}                                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualNFRC.pdf}}                                                                   & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBNFRC.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamNFRC.pdf}}                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsNFRC.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamNFRC.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportNFRC.pdf}}                                                                                     \\ \midrule
FR-NFR Combination                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/defect_reports/DefectReportsCOMBO.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/individual/IndividualCOMBO.pdf}}                                                                    & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/product_backlog/PBCOMBO.pdf}}                                                  & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/technical_team/TechTeamCOMBO.pdf}}                                                                   & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/user_reviews/UserReviewsCOMBO.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/marketing_team/MarketingTeamCOMBO.pdf}}                                                                           & \multicolumn{3}{l}{\includegraphics[width=5.2cm,height=0.6cm]{figures/source/support/SupportCOMBO.pdf}}                                                                                         \\ \bottomrule
\end{tabular}%
}
\end{table*}



\textbf{FR Addition:}
FR additions occur from \textit{defect reports} (48.48\%), and \textit{marketing team} (51.52\%), less than average of time as reported by the majority of participants. FR additions occurring from \textit{user-support discussions} was equally found as same number of responses (33.33\% each) were given for the options: ``less than average, average'', and ``more than average''. Due to having the same number of responses for both options, it is unable to suggest the exact frequency of FR additions which occur from \textit{user-support discussions}. FR additions occur from \textit{individual developer's detailed analysis} (48.48\%), \textit{product backlog reviews} (54.55\%), \textit{technical team discussions} (54.55\%), and \textit{user reviews} (54.55\%), on an average mostly. 

\textbf{FR Modification:}
It can be seen that FR modifications originate in \textit{technical team discussions} (35.71\% each) more than average and on average, in \textit{individual developer's detailed analysis} (53.57\%), \textit{product backlog reviews} (53.57\%), \textit{user reviews} (57.14\%), and \textit{user-support discussions} (46.43\%), it is on average, and in \textit{defect reports} (50\%) and \textit{marketing team} (53.57\%) it is less than average. 

\textbf{FR Deletion:}
Our findings indicate that, FR deletions originate less than average from \textit{defect reports} (56\%), \textit{individual developer's detailed analysis} (52\%), \textit{marketing team} (60\%), and in \textit{user reviews} (50\%). Additionally, they originate from \textit{product backlog reviews} (52\%), \textit{technical team discussions} (60\%), and \textit{user-support discussions} (44\%) on average.

\textbf{FR Bug Fix:}
FR bug fixes can be found less than average from \textit{marketing team} (58.62\%) and they can be found in \textit{defect reports} (44.83\%), \textit{individual developer's detailed analysis} (55.17\%), \textit{product backlog reviews} (44.83\%), \textit{technical team discussions} (51.72\%), \textit{user reviews} (44.83\%), and \textit{user-support discussions} (41.38\%) on average.

\textbf{FR Combination:}
Our findings show that FR combinations occur in \textit{individual developer's detailed analysis }(50\%), \textit{product backlog reviews} (50\%), and in \textit{user-support discussions} (37.5\%) on an average. Moreover, occurrence of FR combinations is less than average from \textit{marketing team} (43.75\%) and \textit{technical team discussions} (37.5\%). However, it is not clear whether FR combinations occur in \textit{defect reports} and \textit{user reviews} on an average or less than average as same amount of responses were found (defect reports=50\% each, user reviews=43.75\% each).

\subsubsection{Sources of Non-Functional Requirements Changes}

\textbf{NFR Addition:}
As reported by the majority of participants, NFR additions originate from \textit{individual developer's detailed analysis} (52.17\%), \textit{product backlog reviews} (47.83\%), \textit{technical team discussions} (60.87\%), and \textit{user reviews} (39.13\%) on an average and they originate less than average from \textit{marketing team} (65.22\%), and \textit{user-support discussions} (43.48\%). Same number of participants (17.39\% each) reported that NFR additions originate from defect reports on an average and more than average. However, as it is either ``average'' or ``more than average'', this suggests that NFR additions occur from \textit{defect reports} in a considerable amount.

\textbf{NFR Modification:}
NFR modifications originate from: \textit{user-support discussions} (36\%) more than average, \textit{product backlog reviews} (44\%), \textit{technical team discussions} (56\%), and \textit{user reviews} (40\%) on an average, and \textit{defect reports} (52\%), \textit{individual developer's detailed analysis} (48\%), and \textit{marketing team} (52\%) less than average. 

\textbf{NFR Deletion:}
NFR  deletions originate from \textit{product backlog reviews} (83.33\%), \textit{technical team discussions} (56\%), and \textit{user-support discussions} (66.67\%) on an average and they originate less than average from \textit{defect reports} (58.33\%), \textit{individual developer's detailed analysis} (50\%), and from \textit{marketing team} (41.67\%). However, it is required to look further the probability of NFR deletions to originate from \textit{user reviews} (out-team software-centric) as the same number of responses (33.33\% each) were found from our survey. 

\textbf{NFR Bug Fix:}
NFR bug fixes rise from \textit{defect reports} (53.33\%), \textit{individual developers' detailed analysis} (53.33\%), \textit{product backlog reviews} (60\%), \textit{technical team discussions} (53.33\%), and from \textit{user reviews} (53.33\%) on average and from less than average from \textit{marketing team} (46.67\%). However, it is unclear whether they originate on average or more than average from \textit{user-support discussions} as same number of responses were found (40\% each).

\textbf{NFR Combination:}
NFR combinations originate from \textit{defect reports} (57.14\%), \textit{marketing team} (57.14\%), \textit{product backlog reviews} (57.14\%), \textit{technical team discussions} (71.43\%), \textit{user reviews} (57.14\%), and from \textit{user-support discussions} (71.43\%). In addition, NFR combinations originate less than average from \textit{individual developer's detailed analysis} (57.14\%). 

\subsubsection{Sources of Combination of Functional and Non-Functional Requirements Changes:}
FR-NFR combinations originate from \textit{individual developer's detailed analysis} (58.33\%), \textit{product backlog reviews} (75\%), \textit{technical team discussions} (66.67\%), \textit{user reviews} (58.33\%), and \textit{user-support discussions} (50\%) on an average and from \textit{marketing team} (50\%) less than average. However, \textit{defect reports} is a gray source where half of the participants reported that it is on average and the other half reported that it is less than average for FR-NFR combinations to originate from defect reports. It is required to look into this further to know whether it is on average or less than average. 

\subsubsection{Sources of Requirements Changes According to the Source Category}
We summarize the above results according to the source category.

\textbf{FR Addition:} 3 out of the 4 sources (individual developer's detailed analysis, product backlog reviews, technical team discussions) from which FR additions occur on average, are in-team human-centric sources and the other (user reviews) is an out-team software-centric source.

\textbf{FR Modification:} 1 out of the 5 sources (user-support discussions) where FR modifications originate on average is out-team human-centric, one is out-team software-centric (user reviews), one is in-team software-centric (individual developer's detailed analysis), and the other two (product backlog reviews and technical team discussions) are in-team human-centric sources. Therefore, this indicates that sources of FR modifications are human-centric mostly.

\textbf{FR Deletion:} 2 out of 3 (product backlog reviews, technical-team discussions) are in-team human-centric sources and the other source (user-support discussions) is an out-team human-centric source. However, all these sources are human-centric.

\textbf{FR Bug Fix:} 2 out of these 6 sources (defect reports, individual developer's detailed analysis) are in-team software-centric and the remaining sources are in-team human-cenric (product backlog reviews, technical team discussions), out-team software-centric (user reviews), and out-team human-centric (user-support discussions). This indicates that majority of sources of FR bug fixes are human-centric. 

\textbf{FR Combination:} Taking the sources which had majority of responses for option ``average'', one is in-team software-centric (individual developer's detailed analysis) and the other (user-support discussions) is out-team human-centric. The unclear sources (defect reports and user reviews) are in-team software-centric and out-team software-centric. However, this suggests that the sources of FR combinations are mostly software-centric.

\textbf{NFR Addition:} Out of the 4 sources which had ``average'' as the highest response, 3 are in-team human-centric (individual developer's detailed analysis, product backlog reviews, technical team discussions) sources and the other (user reviews) is an out-team software-centric source. Similar to the other types of requirements changes, the majority of the sources for NFR additions are human-centric.
 
\textbf{NFR Modification:} The only source (user-support discussions) which had the most response for the option ``more than average'' is an out-team human-centric source. The other sources which had the highest number of responses for the choice ``average'' stipulate that two are in-team human-centric (product backlog reviews, technical team discussions) and the other (user reviews) is out-team software-centric. Therefore, it can be said that the majority of the sources of NFR modifications are human-centric.
 
\textbf{NFR Deletion:} All three sources which give rise to NFR deletions on average are human-centric (in-team human-centric:product backlog review,technical team discussions; out-team human-centric:user-support discussions).
 
\textbf{NFR Bug Fix:} Out of the 5 sources which had ``average'' as the highest response, 2 are in-team software-centric (defect reports, individual developer's analysis), 2 are in-team human-centric (product backlog reviews, technical team discussions) and the other is out-team software-centric. Therefore, not as the other types of sources, NFR bug fixes originate mostly from software-centric sources.

\textbf{NFR Combination:} The sources which give rise to NFR combinations on average are mostly human-centric (in-team human-centric:product backlog reviews, technical team discussions; out-team human-centric: marketing team, user-support discussions) and the other two are software-centric(in-team software-centric: defect reports, out-team software-centric: user reviews).

\textbf{FR-NFR Combination:} Out of the 5 sources for which participants selected the choice ``average'' the most, 2 are in-team human-centric (product backlog reviews, technical team discussions), 2 are out-team human-centric (user reviews, user-support discussions) and the other is in-team software-centric (individual developer's detailed analysis). Therefore, majority of the sources of FR-NFR combinations are human-centric.

 
\subsubsection{Ceremonies/Events Where Functional Requirements Changes Originate}

    \textbf{FR Addition:}
    Our findings show that FR additions originate on average during iteration planning (48.48\%), during iteration review (45.45\%), and after releasing the complete product (42.42\%). And it is unlikely for FR additions to occur during daily standup (63.64\%) and iteration retrospective (45.45\%) as most participants reported that the chance of FR additions' occurrence at those ceremonies/events is less than average.
    
    \textbf{FR Modification:}
     FR modifications originate on average during iteration planning (35.71\%) and during iteration review (57.14\%) whereas they originate less than average during daily standup (64.29\%), during iteration retrospective (57.14\%) and after releasing the complete product (46.43\%).
    
    \textbf{FR Deletion:}
    FR deletions originate during iteration planning (40\%), daily standup (48\%), iteration retrospective (60\%), and after releasing the complete product (44\%) is less than average.
    
    \textbf{FR Bug Fix:}
    FR bug fixes originate on average during iteration planning (44.83\%), daily standup (44.83\%), and during iteration review (55.17\%). There is less chance for the FR bug fixes to occur during iteration retrospective (55.17\%) and after releasing the complete product (41.38\%) as majority of the participants reported them as less than average.
    
    \textbf{FR Combination:}
    FR combinations also originate less than average during daily standup, iteration retrospective, and after releasing the complete product is less than average (50\% of resposes each) as reported by majority of participants. However, the same number of participants (43.75\% each) reported that FR combinations originate during iteration planning less than average and on an average of time. Therefore, it is vague to come to a conclusion about the frequency of FR combinations originating during iteration planning.
    
\subsubsection{Ceremonies/Events where Non-Functional Requirements Changes Originate}

    \textbf{NFR Addition:}
    NFR additions originate on average during iteration review (52.17\%) and after releasing the product (43.48\%). During daily standup (56.52\%) and iteration retrospective (65.22\%), NFR additions originate less than average as reported by majority of participants. However, the same number of participants (39.13\% each) reported that origination of NFR additions is less than average and on an average during iteration planning. Therefore, it is unclear if NFR additions originate during iteration planning on an average or less than average of time.
    
    \textbf{NFR Modification:}
    NFR modifications originate during iteration reviews (48\%) and after releasing the complete product (48\%) on an average. And also, during daily standup (52\%) and iteration retrospective (56\%) less than average as reported by the majority of the participants. Furthermore, it is less than average and on an average as reported by the most participants for the NFR modifications to originate during iteration planning (44\% each). Therefore, similar to NFR additions, we are unable to suggest if NFR modifications originate during iteration planning or not.
    
    \textbf{NFR Deletion:}
    NFR deletions originate during iteration planning (50\%), iteration review (66.67\%), and after releasing the complete product (58.33\%) on an average while NFR deletions originate during daily standup (41.67\%) and  during iteration retrospective (66.67\%) less than average as reported by majority of participants.
   
    
    \textbf{NFR Bug Fix:}
    NFR bug fixes originate on average during iteration planning (60\%), daily standup (53.33\%), iteration review (60\%), and after releasing the complete product (40\%). In addition, it is less likely for NFR bug fixes to originate during iteration retrospective 46.67\%) as reported by majority of participants.

    \textbf{NFR Combination:}
    The majority of responses were found as ``less than average'' for NFR combinations originating during iteration planning (71.43\%), iteration review (57.14\%), iteration retrospective (85.71\%), and after releasing the complete product (71.43\%). Same number of participants reported that NFR combinations originate less than average and on an average of time during daily standup (42.86\% each). Even though this is unclear, results indicate that it is less likely for NFR combinations to originate at any ceremonies/events except during daily standup. 

\subsubsection{Ceremonies/Events where Combinations of Functional and Non-Functional Requirements Originate}
    The chance of NFR-FR combinations to originate during iteration planning (50\%) and iteration review (66.67\%) is on average and during daily standup (41.67\%), iteration retrospective (58.33\%), and after releasing the complete product (58.33\%) is less than average.

\subsubsection{Other Events where Requirements Changes Originate}
A few other events where RCs originate were also reported by participants as given below.

\begin{itemize}
    \item \textbf{Quarterly planning meetings:} 
    When the duration of the entire product is  long,  such planning is required to be done. In this case, origination of RCs can be expected.

    \item \textbf{While coding:} 
    It is common to see the customers present if the team is onsite. In that case, the customer directly providing RCs during development can be expected, as reported by participant P28. Presence of a subject matter expert is possible at on-site or off-site. However, how the presence of user at the working premises and providing RCs is not clear. All these cases indicate that rather than following proper practices, free form of communicating requirements changes is done by various stakeholders:
    \begin{center}
        \textit{``The most common place is user/customer/SME directly working with the development team whilst coding the requirement.''  - P28 [Product Owner/Manager]}
    \end{center}

    \item \textbf{Workshops:} 
    When verbal communication (workshops) and interactions are prominent, there is a high chance for RCs to originate. As testers have high attention to detail when writing test cases, it is possible for RCs to originate:
    \begin{center}
        \textit{``BA’s “unboxing” (workshopping) new User Stories with Dev Team; Testers trying to build test cases.'' - P24 [Tester]}
    \end{center}

    \item \textbf{Customer demos:}
    Usually customer demos are expected to occur at iteration reviews. However, our findings suggest that separate sessions for customer demos exist and RCs originate at customer demos.

\end{itemize}



\subsubsection{Carriers who Bring Functional Requirements Changes}

\textbf{FR Addition:}
Customer (48.48\%) acts as the the carrier of FR additions more than average and product owner (48.48\%) plays the role of carrier on average as reported by the majority of participants. Other stakeholders (agile coach=63.64\%, developer=48.48\%, other agile team members=57.58\%, marketing team=63.64\%, user-support team=57.58\%) bring FR additions to the team less than average of time.

\textbf{FR Modification:}
Our findings show that customer (42.86\%) acts as the carrier of FR modifications more than average and product owner (53.57\%) being the carrier of FR modifications was on an average. Similar to the FR additions, agile coach (71.43\%), developer (53.57\%), other agile team members (64.29\%), marketing team (57.14\%), and user support team (57.14\%) bring FR modifications to the team less than average of time.

\textbf{FR Deletion:}
With regard to FR deletions, customer (42.86\%) acts as the carrier more than average, product owner (53.57\%) acts as the carrier in an average, and other stakeholders (agile coach=64\%, developer=52\%, other agile team members=56\%, marketing team=60\%, user-support team=72\%) act as the carrier less frequently as majority of participants reported that it is less than average.

\textbf{FR Bug Fix:}
Majority of responses were found for customer (48.28\%), developer (48.28\%), and product owner (41.38\%) acting as the carrier of FR bug fixes in an average whereas the other stakeholders (agile coach=48.62\%, other agile team members=44.83\%, marketing team=58.62\%, user-support team=44.83\%) play the role of carrier less than average of time.

\textbf{FR Combination:}
Customer (43.75\%) brings FR combinations to the team more than average of time, product owner (62.5\%) brings FR combinations on average, and other stakeholders (agile coach=68.75\%, developer=50\%, other agile team members=56.25\%, marketing team=62.5\%, user-support team=62.5\%) bring FR combinations to the team less than average of time.

\subsubsection{Carriers who Bring Non-Functional Requirements Changes}

\textbf{NFR Addition:}
Our findings confirm that customer (39.13\%) brings NFR additions to the team more than average, product owner (56.52\%) brings NFR additions to the team on an average and agile coach (56.52\%), developer (56.52\%), other agile team members (65.22\%), marketing team (69.57\%), and user-support team (60.87\%) bring NFR modifications to the team less than average.

\textbf{NFR Modification:}
According to the majority of responses,  customer (40\%) acts as the carrier of NFR modifications most of the time, product owner (48\%) acts as the carrier of NFR modifications on an average and agile coach (60\%), developer (56\%), other agile team members (56\%), marketing team (68\%), and user-support team (52\%) bring NFR modifications to the team less than average.

\textbf{NFR Deletion:}
Customer (41.67\%) and product owner (75\%) bring NFR deletions on an average to the team whereas other stakeholders (agile coach=58.33\%, developer=50\%, other agile team members=50\%, marketing team=66.67\%, user-support team=50\%) bring NFR deletions to the team less than average of time.

\textbf{NFR Bug Fix:}
Customer (53.33\%) brings NFR bug fixes to the team on average. Agile coach (66.67\%) brings NFR bug fixes to the team less than average as reported by the majority of participants. Developer (46.67\% each) and product owner (40\% each) bringing NFR bug fixes should be further studied as same number of responses were found for the options: less than average and more than average. Additionally, it is required to looked upon whether users-support team brings NFR bug fixes less than average, on average, or more than average as equal amount of responses (33.33\%) were found for the options.

\textbf{NFR Combination:}
Customer (42.86\%) and other agile team members (57.14\%) bring NFR combinations on the average. It is unclear if the product owner acts as the carrier of NFR combinations less than average or on average of time as same number of responses (42.86\% each) were found. Agile coach (57.14\%), developer (71.43\%), marketing team (71.43\%), and user-support team (71.43\%) bringing NFR combinations to the team is less than average of time.

\subsubsection{Carriers who Bring Combination of Functional and Non-Functional Requirements Changes}
The same number of responses (33.33\% each) were found for all three options: less than average, average, and more than average, customer being the carrier of FR-NFR combinations, it is required to look more for the most possible chance. Additionally, as the number of responses (50\% each) was divided between less than average and average for developer being the carrier, it is is required to further look into this as well. Other stakeholders (product owner=66.67\%, agile coach=66.67\%,  other agile team members=75\%, marketing team=66.67\%, user-support team=66.67\%) bring FR-NFR combinations less than average.

\subsubsection{Other Carriers who Bring Requirements Changes}
Apart from the carriers we provided for the participants to choose, carriers who fall under the category ``other agile team member'' as reported by the participants are listed below:

\begin{itemize}
    \item \textbf{Security team:} 
    In some cases, a security team exists in the project and they have the ability to identify NFR changes. Moreover, other stakeholders do not identify NFR changes as much as the security team, hinting that security teams are subject matter experts in NFRs whereas customer/product owner who brings other RCs often:
    \begin{center}
        \textit{``Our security team most often identifies NFR changes.'' - P37 [Product Owner]} 
    \end{center}
    
    \item \textbf{Business Analysts, Delivery Leads, Development Manager:} 
    These three roles are connected to interaction with external stakeholders such as customers and users. Therefore, it can be said that, due to their engagement with external stakeholders, they bring RCs at different circumstances such as critical requirements:
    \begin{center}
    \textit{``Other BAs, Delivery Leads \& Development Manager (especially on critical requirements).'' - P25 [Manager]} 
    \end{center}
\end{itemize}


\subsubsection{Documentation Forms of Functional Requirements Changes}
\emph{User stories} was reported as the most common form of documenting FR additions (51.52\%), FR modifications (53.57\%), FR deletions (44\%) and FR combinations (50\%). Majority of the participants (55.17\%) reported FR bug fixes are documented in the form of \textit{tasks}.

\begin{comment}


    \textbf{FR Addition:}
    From the responses given by the participants, FR additions were mostly documented in the form of user stories (51.52\%). 
   
    
    \textbf{FR Modification:}
    User stories were reported most (53.57\%) by the participants as the form used to document FR modifications. 
   
    
    \textbf{FR Deletion:}
    User stories were reported as the most common form (44\%) used to document FR deletions by the participants. 
   
    
    \textbf{FR Bug Fix:}
    Most participants (55.17\%) have chosen tasks as the form they use to document FR bug fixes.
    
    \textbf{FR Combination:}
    To document FR combinations, user stories were reported as the most common form (50\%).
\end{comment}

\subsubsection{Documentation Forms of Non-Functional Requirements Changes}
Majority of the participants reported that they use \textit{user stories} to document NFR modifications (44\%), NFR deletions (41.67\%), and NFR combinations (57.14\%); and tasks to document NFR additions (39.13\%) and NFR bug fixes (46.67\%).

\begin{comment}
    

    \textbf{NFR Addition:}
    Tasks were reported the most (39.13\%) as the form to document NFR additions.
    
    \textbf{NFR Modification:}
    Highest number of preference (44\%) was given for user stories by the participants to document NFR modifications.
    
    \textbf{NFR Deletion:}
    User stories were selected by most participants (41.67\%) followed by tasks (33.33\%) as the form for documenting NFR deletions.
    
    \textbf{NFR Bug Fix:}
    Most participants (46.67\%) reported that they use tasks to document NFR bug fixes.
    
    \textbf{NFR Combination:}
    User stories (57.14\%) and tasks (42.86\%) were reported as the forms for NFR combination documentation by the participants.
\end{comment}

\subsubsection{Documentation Forms of Combination of Functional and Non-Functional Requirements Changes}

\textit{User stories} and \textit{tasks} were equally reported (33.33\%) as the highest responded choice for documenting FR-NFR combination RCs.

\subsubsection{Requirements Changes as a Percentage of Total Work Items}

It was surprising that 55\% of the participants responded that  less than 25\% of the total work items in the project were RCs (Fig. \ref{fig:percentage_RC}). 25\% of the participants reported that RCs are between 25\% - 50\% of the total work items. In addition, 18\% and 2\% of the participants reported that RCs are between 51\% - 75\% and more than 75\% of the work items respectively. If agile is all about embracing changes, why only 1/4 of the total work items were RCs and why rest were fixed requirements? This gives rise to three questions to look into in the future,
\begin{itemize}
    \item Do the teams practice hybrid versions of agile and traditional software development even though they claim that what they practice is agile?
    \item Why do teams practice agile if 75\% of the total work items are fixed?
    \item If the remaining work items are neither RCs nor fixed, what are they?
\end{itemize}
These questions need to be investigated in future studies.

\begin{figure}[b]
        \centering
        \includegraphics[width=\columnwidth]{figures/Requirements Changes as a Percentage of Total Work Items/TotalWorkItems.pdf}
        \caption{Requirements Changes as a Percentage of Total Work Items}
        \label{fig:percentage_RC}
    \end{figure}
    
\subsubsection{Why Agile?}
We asked the participants why do they use agile irrespective of their response on agile's ability to respond to RCs. As given in Table \ref{tab:why_agile}, we found several reasons which we categorized as human-centric and software-centric reasons.

\textbf{Human-centric positive reasons:}
Even though a participant mentioned that agile helps to respond to RCs, several other reasons were provided by other participants. These reasons include, being able to deliver the product in a shorter time period (N=13), surface any issues quickly (N=2), receive constant customer feedback (N=9), increase productivity (N=17), split the tasks into granular tasks (N=1), active and close collaboration (N=2), continuous learning opportunities for the team (N=1), experiment with the tasks (N=1), have a team empowered with autonomy (N=1), and improve communication (N=1). However, the top three reasons for practicing agile as mentioned by \textit{State of Agile Survey} \cite{202014thAgile} are accelerating software delivery, enhance ability to manage changing priorities, and increase productivity whereas almost half of our participants disagreed with the fact that it enhances ability to manage changing priorities (N=19).

\textbf{Software-centric positive reasons:}
Agile helps to remove unnecessary modifications (N=1), improve the product continuously (N=2), enhance the visibility (N=1), and improve the product quality (N=1) as reported by the participants.
We also found that, some participants (N=8) practice agile due to either organizational needs or customer needs. That is, organization or customer require the project to be run in an agile environment.

\begin{comment}
Based on the above findings, we conceptualized the relationships among human-centric (HC) and software-centric (SC) positive reasons of using agile for software development as shown in Fig. \ref{fig:positives}. The relationships are;
\begin{itemize}
    \item \textbf{HC-HC: }Active and close collaboration improves communication and vice versa;
    \item \textbf{HC-HC: }Active and close collaboration increases productivity;
    \item \textbf{HC-HC: }Increased productivity helps to deliver in a shorter period of time;
    \item \textbf{HC-HC: }Experimentation allows the team to learn continuously;
    \item \textbf{HC-HC: }Continuous learning of the team helps to surface issues quickly;
    \item \textbf{HC-HC: }Continuous learning of the team helps to respond to RCs;
    \item \textbf{HC-HC: }Constant feedback from the customer helps to surface issues quickly;
    \item \textbf{HC-HC: }Constant feedback from the customer helps to respond to RCs;
    \item \textbf{HC-HC: }Empowered autonomy in the team allows the team to split the tasks into granular tasks;
    \item \textbf{HC-HC: }Splitting tasks to granular tasks improves productivity;
    \item \textbf{HC-SC: }Splitting tasks to granular tasks helps to remove unnecessary modifications in the product;
    \item \textbf{SC-SC: }Removing unnecessary modifications helps to improve the product continuously;
    \item \textbf{SC-SC: }Continuous product improvement improvement improves quality of the product;
    \item \textbf{SC-SC: }Improved product quality enhances the visibility of the product
\end{itemize}


\begin{figure}
    \centering
    \includegraphics[width=\columnwidth]{figures/Requirements Changes as a Percentage of Total Work Items/Positivesofagile.pdf}
    \caption{Positives of Agile (RC: Requirements Change; White Rectangles: Human-Centric Reasons; Gray Rectangles: Software-Centric Reasons}
    \label{fig:positives}
\end{figure}
\end{comment}

\subsubsection{Drawbacks of Agile}
The benefits of using agile are discussed much more in research literature than its drawbacks. Through our survey, we found that iteration pressure which is rooted due to working under sustainable pressure to deliver customer value \cite{Babb2014EmbeddingDevelopment} causes stress within team members (N=1). This is a major concern as agile is said to be a human-centric software development methodology. If such a methodology causes harm to the humans involved in it, then its human-centric property must be in question. Furthermore, we found that agile does not always allow teams to meet their customer's expectations. In such instances, practicing agile is de-prioritized:

\begin{center}
    \textit{``Agile becomes something else when it comes to client's needs and at that point, no one cares about Agile'' - P27 [Developer]}
\end{center}


\begin{table}[]
\caption{Why Practicing Agile?}
\label{tab:why_agile}
\resizebox{\columnwidth}{!}{%
\begin{tabular}{ll}
\toprule
\multicolumn{1}{c}{\textbf{Reason for Practicing Agile}} & \multicolumn{1}{c}{\textbf{Category}}      \\ \midrule
Responding to requirements changes              & \multirow{11}{*}{Human-Centric}   \\
Deliver in a shorter time period                &                                   \\
Surfacing any issues quickly                    &                                   \\
Constant feedback from customer                 &                                   \\
Increases productivity                          &                                   \\
Ability to split tasks into granular tasks      &                                   \\
Active and close collaboration                  &                                   \\
Continuous learning for the team                &                                   \\
Supports experimentation                        &                                   \\
Empowers team autonomy                          &                                   \\
Improves communication                          &                                   \\ \midrule
Helps to remove unnecessary modifications       & \multirow{4}{*}{Software-Centric} \\
Continuous product improvement                  &                                   \\
Enhances visibility                             &                                   \\
Improves product quality                        &                                   \\ \midrule
Doing agile for organizational/customer needs   & General                              \\ \bottomrule
\end{tabular}%
}
\end{table}
    
\subsubsection{Using Strategies to Minimize Requirements Changes}
We asked for the reason why less requirements changes were received from the participants who stated this. By analysing the data, we found that, they try to mitigate the origination of RCs and use different strategies as shown in Fig. \ref{fig:mitigation}. Defining requirements clearly and using practices and tools properly are the strategies we found.

\begin{figure}[b]
    \centering
\includegraphics[width=\columnwidth]{figures/Requirements Changes as a Percentage of Total Work Items/RCmitigation.pdf}
    \caption{Requirements Change Minimization Strategies}
    \label{fig:mitigation}
\end{figure}

\textbf{Defining requirements clearly:}
As reported by the participants, if RCs are welcomed, changes have to be made in the epics and/or user stories; which is not preferred by the teams. Moreover, changing these \textit{interrupts the team focus} and \textit{impacts the software delivery}. Therefore, it is needed to define the requirements more clearly:
\begin{center}
    \textit{``In my projects, clear requirements of the project is key..'' - P20 [Product Owner]}
\end{center}

\textbf{Proper use of practices:}
Teams mix and match agile (prioritization, regular customer feedback, frequent team meeting, releasing beta versions of the software, short and small targets with deadlines) and non-agile (micro-management, defining requirements in advance) practices to block RCs. Especially, non-agile practices which are not recommended by agile are in use as reported by the participants. According to participant P16, they achieve the accuracy with the help of \textit{micro-management}:

\begin{center}
    \textit{``Accuracy of project deliverables is because of micro level supervision'' - P16[Agile Coach/Scrum Master, Product Owner, Developer, Tech Lead] 
}
\end{center}


\textbf{Proper use of tools:}
As stated by the participants, using tools (E.g.: \textit{JIRA}) meaningfully, helps them to stop the RCs from originating. This is also one of the reasons why they prefer to have their projects use agile methods.

\subsubsection{Facing Difficulties After Accepting Requirements Changes}
We found that teams face difficulties after they accept RCs. As reported by the participants, the changes in epics/user stories due to large number of RCs make it difficult for them to work. In addition, they find it difficult to adjust their work when the RCs are received in the middle of an iteration and expected to develop the RCs in the current iteration in which they already have user stories to work on. Furthermore, participants reported that being difficult to adjust in the middle of the iteration results in impacting the product delivery and interrupting the team focus:

\begin{center}
    \textit{``Too many changes may not really work well with the agile framework because that would cause epic/use stories to change. Changing the user stories in the middle of the sprint may interrupt team focus and impact the delivery..'' - P20 [Product Owner]}
\end{center}

This suggests that even though the teams are practicing agile, they are expected to reshape the agile practices in order to fit accordingly to the respective circumstance. However, according to the Scrum Guide \cite{2015TheGuide}, no changes should be made that endanger the sprint goal.

\subsubsection{Using Techniques to Handle Requirements Changes}
Agile teams use various techniques to handle RCs as shown in Fig. \ref{fig:handling_techniques}. These include adding the RC to the product backlog, developing the RC as soon as received, following an acceptance criteria for RC, prioritization, re-estimating and changing the iteration plan. Additionally, we found that prioritizing based on changes in the market and based on team learning, and reviewing priorities every iteration as prioritization techniques. Furthermore, analysing the impact of the RC (step 1), estimating the effort of the RC (step 2), adding RC to iteration backlog (step 3), and removing existing user stories according to the priority and size of RC (step 4) as a step-wise technique of re-estimating and changing the iteration plan. We also found that, step 1 and 2 are used as acceptance criteria of RC.

\begin{figure}
    \centering
    \includegraphics[width=\columnwidth]{figures/Requirements Changes as a Percentage of Total Work Items/RCHandlingTechniques.pdf}
    \caption{Requirements Changes Handling Techniques (RC: Requirements Change)}
    \label{fig:handling_techniques}
\end{figure}

\subsubsection{Managing the Agile Environment While Being Attentive of Requirements Changes}
Keeping in the mind the fact that RCs exist in the development environment, participants mentioned,
\begin{itemize}
\item Not over focusing on agile principles;
\item Planning iterations precisely;
\item Being agnostic of prescriptive agile frameworks;
\item Customizing and evolving roles and process
\end{itemize}
help them to manage the development environment better. The overall idea of the above mentioned indicate that, not trying to practice ideal agile help the teams to better handle the entire environment in terms of RCs.







\subsection{Threats to Validity}
\label{sec:threats}
\input{sections/threats}


\subsection{Future Work}


\textbf{Researchers talking the language of agile practitioners:}
Our survey distribution approach included posting the survey link on social media and resistance to our survey was shown by a set of agile practitioners in a \textit{LinkedIn} group. This resulted in showing a gap between agile practitioners and agile researchers. The main gap we found was with respect to the terminology we used. Since our survey terminology contained the word ``requirement'', some of the practitioners were highly skeptical about using it as they preferred calling RCs ``user stories'' rather than ``requirements''. This is counter-intuitive as we considered user stories as a form of documenting requirements and RCs. A debate among some of the practitioners identified that there is no proper terminology set up to be used in agile environments and this hinders communication. It is necessary to look into this issue more in the future. Furthermore, practitioners seem to have different opinions on the definition of an RC. While some said all the requirements they receive are RCs, some others said there are no such entity as a requirements change in agile and they are all regular ``requirements". Another commented that all RCs turn out to be requirements in the end. Researchers need to understand that there is no proper definition for what agile teams receive as changes from customers or what we call requirements in general. Moreover, some practioners also showed their dislike of the concept of trying to manage RCs in agile as well.  

\textbf{Future Work:} Is agile as human-centric as it is known to be? As we found a participant mentioning that iteration pressure causes stress within team members, this requires further investigation majorly (Section \ref{sec:agile_helps}).






