Key Challenges in Agile Requirements Engineering
Agile Software Development (ASD) is becoming more popular in all fields of industry. For an agile transformation, organizations need to continuously improve their established approaches to Requirements Engineering (RE) as well as their approaches to software development. This is accompanied by some challenges in terms of agile RE. The main objective of this paper is to identify the most important challenges in agile RE industry has to face today. Therefore, we conducted an iterative expert judgement process with 26 experts in the field of ASD, comprising three complementary rounds.
In sum, we identified 20 challenges in three rounds. Six of these challenges are defined as key challenges. Based on the results, we provide options for dealing with those key challenges by means of agile techniques and tools. The results show that the identified challenges are often not limited to ASD, but they rather refer to software development in general. Therefore, we can conclude that organizations still struggle with agile transition and understanding agile values, in particular, in terms of stakeholder and user involvement.
KeywordsAgile Software Development Requirements Engineering Challenges Agile RE Stakeholder and user involvement Human-Centered Design
Agile Software development (ASD) gains in popularity in today’s business world due to enabling immediately changes in the direction of product development. These short-term changes in direction require a flexible approach to Requirements Engineering (RE) as well. In addition, agile methodologies (such as Scrum , Kanban  or Extreme Programming ) are often combined with Human-Centered Design (HCD)  activities in order to emphasize a value-driven approach to product development [5, 6]. To this end, the field of agile RE has emerged during the last decade.
Focusing on user needs and value delivery becomes an important aspect in product development due to the increasing competition in all areas. With regard to ASD, plan-driven organizations moved away to value-driven organizations. On the one hand, people in plan-driven organizations often negotiate about project plans, pricing models and the amount of features they can develop with the available resources. They are emphasizing the generated outputs such as number of created features during a time period. On the other hand, people in value-driven organizations discuss visions, experiences and human values as well as the way to address them through the product. They focus on the outcomes that the delivered outputs entail.
Compared to sequential approaches to RE, which comprise a requirement analysis phase before the development can even begin, agile RE is carried out along with the development itself. Therefore, continuous management of requirements is a crucial attribute. Requirements are regularly described from a user perspective in the form of epics and user stories  instead of creating a requirements document . Recent research is showing that there are several ways of running RE in an agile environment while involving users and stakeholders [5, 9, 10, 11, 12].
Performing agile RE can lead to challenges organizations have to deal with. In literature, there can be found some studies investigating challenges in agile RE (see [11, 12, 13, 14, 15]). However, the related work still lacks in giving a general overview of the challenges in current industry.
RQ1: What are the key challenges in Agile Requirements Engineering?
RQ2: How can we deal with the identified key challenges?
The paper is structured as follows: Sect. 2 briefly summarizes the related work and points out the research gap. Section 3 presents the applied research method and describes the iterative expert judgement process. Then, Sect. 4 identifies the findings and discusses both on their meaning and on the limitations of this study. Finally, Sect. 5 provides the conclusions as well as an outlook on future research.
2 Related Work
Challenges in agile RE reported by related work
Ramesh, Cao, Baskerville 
Multi-case study (16 companies)
Problems with cost and schedule estimation; inadequate or inappropriate architecture; neglect of non-functional requirements; customer access and participation; prioritization on a single dimension; inadequate requirements verification; minimal documentation
Bjarnason, Wnuk, Regnell 
Planning for agility; weak requirements prioritization; weak effort estimates; quality issues; system completed late; capturing innovation; lack of documented requirements; customer-proxy role; ensuring competence (RE, VV); motivating teams for requirements work; weak requirements at start
Inayat, Salim, Marczak, Daneva, Shamshirband 
Systematic literature review
Minimal documentation; customer availability; inappropriate architecture; budget and time estimation; neglecting non-functional requirements (NFRs); customer inability and agreement; contractual limitations; requirements change and its evaluation
Heikkila, Damian, Lassenius, Paasivaara 
Problems with client or customer representatives; insufficiency of user story format; difficulties in prioritization of requirements; growing technical debt; reliance on tacit requirements knowledge; imprecise effort estimates
Soares, Alves, Mendes, Mendonca, Spinola 
Systematic literature review
Requirement prioritization; non-functional requirements identification; lack of information; volatility of requirements; requirements definition; dependence among requirements; prediction of impacts of changes; user dependence; communication and collaboration with users; requirements validation
Analyzing the related work, we can state that the authors use two different kinds of research approaches in general. On the one hand, Ramesh et al.  and Bjarnason et al.  utilize case studies to investigate the challenges in the field. On the other hand, Inayat et al. , Heikkila et al.  and Soares et al.  report challenges in agile RE by analyzing primary studies with the aim to identify available evidence in existing research.
Ramesh et al.  results were published in 2010. However, as ASD is a rapidly changing research area and the body of knowledge has evolved over the last years, we need to clarify whether the reported challenges are still relevant today. For instance, NFRs may not be longer a challenge for industry since the concept of the Definition of Done and the usage of acceptance criteria are widely spread. Bjarnason et al.  carry out a case study in only one company, therefore the results may not be applicable to other companies and may not be representative in general. In comparison, Inayat et al. , Heikkila et al.  and Soares et al.  review primary studies by analyzing existing literature, which is a good approach to get an impression of relevant aspects from a theoretical viewpoint. Nevertheless, one could argue that this is not an appropriate approach to investigate the existing challenges in practice.
To this end, the aim of this study is to identify the most important challenges in agile RE industry has to face up today by getting insights from 26 experts in the field. To the best of our knowledge there is no existing study investigating these challenges by means of a qualitative study with practicing experts in ASD working for many different companies.
3 Research Method
Anonymity among experts to avoid influence of dominant individuals
Controlled feedback with statistical group response
The main benefit of our modified approach was utilizing the learnings from a previous iteration for carrying out the following ones.
3.1 General Study Design
We conducted the study in German since most of the experts are native speaker. Since we are aware that the term agile RE is not very accepted in the agile community and some experts understand this as a contradiction in itself, we decided not to ask for challenges in agile RE directly. On the contrary, we phrased our questions differently and described the context of our study within the introduction part of each questionnaire.
We used google forms for the first and second round, whereas limesurvey was used for the third round due to the complexity of the questionnaire. In general, we decided to use 7-point Likert items since this has been proven to be the best choice in terms of avoiding interpolations within related research fields . Besides, we adapted the quality criteria proposed by Diamond et al.  so as to ensure the quality of our study.
3.2 Panel of Experts
Many years of experience as professional in the field of ASD
Working experience in one or more of the following roles: Product Owner, Scrum Master, Agile Coach, Consultant for Agile Transition, Kanban Expert or Lean Startup Expert
The panel consisted of 26 experts who are working in 19 different companies located in Germany and Switzerland. In general, they had 2–10 years of experience working in ASD (average = 6.14 years). In comparison, experts have about 0–16 years of experience with RE (average = 6.65 years). Even though one expert stated that he had no experience with RE at all, we decided to include his answers into the study, since he has long experience in ASD and in general there do not exist a specific role of a requirements engineer.
Know-how of panel in terms of ASD
know-how very poor
know-how very high
3.3 Round 1
Exemplary item in round 1
Question round 1
Answer given by expert
What challenge do you perceive with requirements in terms of Agile Software Development?
Stakeholders affected by requirements or changing the system are not involved
Why do you consider this challenge as important?
In one of my projects, representatives of end users did not really knew the pain of end users. Even the early UI prototypes were tested by incorrect stakeholders, which led to risks of conflicts and failure
With respect to data analysis, each challenge was categorized by the authors during a workshop. Those items, which could not be categorized easily, were discussed within the group of authors. We used the following categories: stakeholder and user involvement, collaboration within the team, vision and big picture, iteration planning and estimation, granularity of requirements, dependencies of requirements, understanding agile and agile values, continuous delivery of value, roles and responsibilities, need for security, requirement validation, RE methods, format of requirements, clarity of requirements, prioritization, refinement, discovery and transparency.
Agile RE activities
Agile RE activity
Eliciting new ideas/requirements
Clarifying and analyzing new ideas/requirements
Measuring the value that the development will add to the product
Checking if requirement is implemented in the manner to deliver value
Capturing discussion and decisions around the requirement
3.4 Round 2
We checked each item of round one critically, whether or not it was appropriate for answering our RQs and being queried in the next round. Thus, items of round 1 were consolidated or excluded. In the end, we identified 34 items as relevant for assessing them in round 2. Based on those items, we created the questionnaire for the second round. The resulting questionnaire assessed 34 items related to the following topics: stakeholder and user involvement (6 items), understanding agile and agile values (6 items), RE methods (10 items), iteration planning and estimation (6 items) and format of requirements (6 items).
3.5 Round 3
We reduced the number of items when designing the questionnaire for the third round. Considering items from round 2, we assessed each item according to (a) its relevance in terms of our RQs, (b) the importance in terms of the attributes of agile RE, (c) the opinion of the experts and the comprehensibility of the items.
The final questionnaire comprised two parts. The first part queried in sum 20 potential key challenges of agile RE (see Appendix). The experts were asked to rate each item, whether or not it is a challenge in agile RE. Moreover, they had the option to choose giving no statement. Then, the second part evaluated those items that experts identified as challenge in terms of importance, following 7-point Likert items (totally important, important, rather important, neutral, rather unimportant, unimportant, totally unimportant, no statement). In addition, experts optionally had the chance to provide a solution for solving the challenge.
In sum, 22 experts filled in the questionnaire. We classified each of the 20 items as challenge in Agile RE since we derived all items from the results of the previous rounds. Besides, we calculated the number of experts who rated each item as a challenge. Then, we defined challenges as key in those cases where 2/3 of the experts’ answers were: “Yes, it is a challenge”. Finally, we calculated the importance for those items. The results of round 3 can be found in .
4 Results and Discussion
Summarizing the results of the three complementary rounds, we derived 20 challenges that companies have to cope with in terms of agile RE (see Appendix). We categorized such challenges into stakeholder and user (3 items), requirements management (7 items), methods and artifacts (5 items) and format of requirements (5 items).
4.1 (RQ1) What Are the Key Challenges in Agile Requirements Engineering?
Key challenges in agile RE
In agile software development functional or technical dependencies with other teams are a challenge because a considerable coordination effort is required
In agile software development it is a challenge that stakeholders understand that the development team can make independent (detailed) decisions
In agile software development it is a challenge not to lose sight of the big picture during the implementation of complex requirements
In agile software development continuous management of requirements is a challenge since not all of them are fixed at the beginning and they may change over the course of the project
In agile software development it is a challenge to work out user requirements and quality of use in cooperation with direct users (end users) of the product
In agile software development it is a challenge to involve stakeholders throughout the whole development process in regular iterations, so that product development will succeed
All challenges related to the category stakeholder and user are classified as key challenges (C2, C5, C6). Therefore, we can conclude that organizations still struggle to the agile transition. Evolving an agile mindset within a whole organization even in parts that are not close to development is still a challenge companies have to address.
Typically, agile transformation starts in development-oriented parts of an organization. Transforming an organization to become more agile implies a change within the whole organization. The results show that there is a gap between knowledge and understanding agile values  within organizations. Development-oriented techniques evolve rapidly. In comparison, there are still challenges involving stakeholders and users into the agile processes (C2, C5, C6).
Two challenges (C1, C4), related to category requirements management, are key in agile RE. On the one hand, companies have an issue with the continuous management of requirements. On the other hand, they have a problem with technical or functional dependencies due to raising effort in coordination. Besides, one challenge of methods and artifacts (C3) is a key challenge.
ASD is commonly used in environments where people have to solve complex adaptive problems . Concerning C1, C3, and C4 we can state that there are still challenges to be solved, due to the complexity of problems, which are not addressed by agile techniques properly. To this end, existing techniques and methods must be adapted or new techniques need to be found.
4.2 (RQ2) How Can We Deal with the Identified Key Challenges?
Experts recommend techniques, methods and tools in order to deal with the challenges in agile RE. Below, we will list the techniques and methods proposed by the panel for each key challenge.
C1: In agile software development functional or technical dependencies with other teams are a challenge because a considerable coordination effort is required.
More than three experts recommended using scaled frameworks such as LeSS, SAFe or Scrum of Scrum. Moreover, they proposed the use of the following techniques: creating a common understanding among all, enhancing continuous communication and collaboration, training the ability to solve dependencies, holding weekly coordination meetings, organizing teams in matrix management, building communities of practices for transcending topics, release planning (SAFe), team-transcending availability of product und sprint backlogs, involving temporary representatives in other teams, enforcing continuous integration, improving API-driven development and microservices.
C2: In agile software development it is a challenge that stakeholders understand that the development team can make independent (detailed) decisions.
The following techniques were suggested: continuous coordination and presenting possible solutions to stakeholder, providing transparency about rationales of the decisions, strengthening product owner with competency in decision making and helping stakeholders become aware of the consequences of interfering into detailed decisions.
More than three experts recommended providing alternative solutions for one requirement. In addition, it is useful to demonstrate that the recommended solution of a stakeholder is an alternative out of many. In previous rounds, more than one expert stated that product owner and stakeholder altogether decide what to be developed. In contrast, the development team decides how the requirement should be developed.
C3: In agile software development it is a challenge not to lose sight of the big picture during the implementation of complex requirements.
The following techniques were recommended: creating a shared understanding regarding the meaning of the big picture by means of a product vision, defining epics or subgoals in the beginning, managing the big picture as a responsibility of the product owner, providing transparency concerning changes among all, understanding connections among user stories by means of story mapping, visualizing customer journey in the beginning, involving users continuously in order to focus on the problem to be solved and identifying central contact person for related topics to enable rapid coordination. Moreover, the experts advised to use visualization by means of roadmaps, sketches of the system and processes, and value streams.
C4: In agile software development continuous management of requirements is a challenge since not all of them are fixed at the beginning and they may change over the course of the project.
The experts proposed the following techniques, methods and tools: collaborating closely with the requesting stakeholder, communicating regularly within the team, refining and prioritizing continuously the product backlog, grooming on demand (Kanban), describing in detail the requirements in the sprint backlog, reviewing the results regularly, discussing the maturity level of a requirement with the team, grouping user stories to epics, using Kano analysis, screening and scoring the theme, weighting relatively, utilizing spike stories to evaluate uncertainty in requirements and using ticketing tools (e.g. JIRA).
C5: In agile software development it is a challenge to work out user requirements and quality of use in cooperation with direct users (end users) of the product.
The experts recommended utilizing the following techniques: prototypes, interviews, observing users by the think aloud method, A/B testing, UX labs, analyzing usage behavior, friendly user tests, alpha/beta/silent launches, improving continuously a released version, utilizing a UX-board for play back user insights and testing hypotheses with real users. In addition, one expert suggested adapting user research to ASD by reducing the methods to the minimal, evaluate within the team without report creation, reduce financial restrictions for user involvement as well as problems of accessing real user by means of panels or a prior recruitment.
C6: In agile software development it is a challenge to involve stakeholders throughout the whole development process in regular iterations so that product development will succeed.
The following techniques were proposed: defining stakeholders and their involvement in regular iterations, proposing goals instead of prescribing solutions, involving all possible stakeholders in the beginning and reducing the amount of people over time.
More than eight experts suggested involving stakeholders by regular planning and review meetings to gather feedback and useful information. In light of this, they recommended clarifying the purpose of the meetings and the importance of the outcomes to be discussed beforehand.
4.3 Meaning of Findings
Comparing our findings to the identified challenges of the related work (see Table 1), we can conclude that 16 out of our challenges are not reported by the related studies.
Our key challenge C5 (user involvement) is reported by all related studies. In addition, three studies [11, 12, 13] report issues with non-functional requirements, which is comparable to our challenge C13. There is also a relation between the key challenge C4 (continuous requirements management) and the challenge “requirements change and its evaluation” reported by . Moreover, the key challenge C1 (technical or functional dependencies to other teams) is reported by  in a slightly different manner since they phrase it like “dependence between requirements”.
Moreover, the results show that the identified challenges are often not limited to ASD, but they rather refer to software development in general. Therefore, we can conclude that organizations still struggle with agile transition and understanding agile values, in particular, in terms of stakeholder and user involvement.
We are aware that the design of a questionnaire is important for the process of data gathering. To this end, we made several pretests of each questionnaire we used with participants matching our criteria of expert selection. Nevertheless, we observed two experts struggling with the user experience of the questionnaire tool (Google Forms) used in round 1. Therefore, we decided to use another tool (LimeSurvey) for the questionnaire in round 3, which was more complex than the previous two.
To carry out the study, the group of authors created summaries of the results and made decisions concerning the kind of items they had to query in the following rounds. That may lead to bias in the opinion building process of the panel. We tried to prevent this point by being very accurate in terms of data analysis and by creating the reports. In addition, we selected items for the following rounds through the selection criteria defined earlier.
5 Conclusions and Future Work
This paper has addressed the identification of the most important challenges in agile RE industry has to face up today. Moreover, we examined how to deal with those challenges. For that purpose, we carried out an iterative expert judgement process comprising three complementary rounds. The learnings from previous iterations were used for carrying out the following ones. Our panel consisted of 26 experts in the field of ASD working for 19 different companies.
We have contributed to the body of knowledge of software development by identifying 20 challenges industry has to address at present in terms of agile RE. Six of these challenges have been defined as key challenges. In addition, we have analyzed options to deal with those key challenges by means of agile techniques recommended by the experts.
Future research may specifically identify challenges in agile RE by means of an international panel of experts, for instance with experts from Scandinavian countries. Our aim is to conduct a comparative analysis among the statements of German-speaking experts with the viewpoint of international experts. In addition, we are creating a tool that supports practitioners solving the identified challenges using agile techniques. Therefore, we are working on agile RE patterns. Some experts stated that the queried challenges are not limited to ASD. To this end, future studies may analyze whether the challenges appear in terms of RE in general.
First of all, we would like to thank all experts for their participation and sharing their valuable knowledge. Moreover, we would like to thank all participants in our pretests for their collaboration. This research has been supported by the MeGUS project (TIN2013-46928-C3-3-R), Pololas project (TIN2016-76956-C3-2-R) and by SoftPLM Network (TIN2015-71938-REDT) of the Spanish Ministry of Economy and Competitiveness.
- 2.Anderson, D.J.: Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press, Sequim (2010)Google Scholar
- 3.Beck, K.: Extreme Programming Explained: Embrace Change. Addison-Wesley, Reading (2000)Google Scholar
- 4.International Organization for Standardization: ISO 9241-210:2010 - Ergonomics of human-system interaction - Part 210: Human-centred design for interactive systems (2010)Google Scholar
- 6.Schön, E., Winter, D., Uhlenbrok, J., Escalona, M.J., Thomaschewski, J.: Enterprise experience into the integration of human-centered design and Kanban. In: Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016), Lisbon, Portugal, pp. 133–140 (2016)Google Scholar
- 7.Cohn, M.: User Stories Applied: For Agile Software Development (2004)Google Scholar
- 9.Silva da Silva, T., Martin, A., Maurer, F., Silveira, M.: User-centered design and agile methods: a systematic review. In: 2011 AGILE Conference, pp. 77–86. IEEE (2011)Google Scholar
- 12.Soares, H.F., Alves, N.S.R., Mendes, T.S., Mendonca, M., Spinola, R.O.: Investigating the link between user stories and documentation debt on software projects. In: 2015 Proceedings of the 12th International Conference on Information Technology - New Generations, pp. 385–390. IEEE (2015)Google Scholar
- 14.Bjarnason, E., Wnuk, K., Regnell, B.: A case study on benefits and side-effects of agile practices in large-scale requirements engineering. In: Proceedings of the 1st Workshop on Agile Requirements Engineering - AREW 2011, pp. 1–5. ACM Press, New York (2011)Google Scholar
- 15.Heikkila, V.T., Damian, D., Lassenius, C., Paasivaara, M.: A mapping study on requirements engineering in agile software development. In: 2015 Proceedings of the 41st Euromicro Conference on Software Engineering and Advanced Applications, pp. 199–207 (2015)Google Scholar
- 18.Linstone, H.A., Turoff, M.: The Delphi Method - Techniques and Applications (2002)Google Scholar
- 20.Finstad, K.: Response interpolation and scale sensitivity: evidence against 5-point scales. J. Usability Stud. 5, 104–110 (2010)Google Scholar
- 21.Schön, E.-M., Winter, D., Thomaschewski, J., Escalona, M.J.: Results of “Challenges in Agile Requirements Engineering” (Round 1) (2017). doi:10.13140/RG.2.2.34571.28961
- 22.Schön, E.-M., Winter, D., Thomaschewski, J., Escalona, M.J.: Results of “Challenges in Agile Requirements Engineering” (Round 2) (2017). doi:10.13140/RG.2.2.32893.56802
- 23.Schön, E.-M., Winter, D., Thomaschewski, J., Escalona, M.J.: Results of “Challenges in Agile Requirements Engineering” (Round 3) (2017). doi:10.13140/RG.2.2.16116.35201
- 24.Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J., Thomas, D.: Manifesto for Agile Software Development. http://www.agilemanifesto.org/
- 25.Schwaber, K., Sutherland, J.: Scrum Guide. http://www.scrumguides.org/scrum-guide.html
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter’s Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter’s Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.