Ambiguity in user stories: A systematic literature review

Abstract

Context

Ambiguity in user stories is a problem that has received little research attention. Due to the absence of review studies, it is not known how and to what extent this problem, which impacts the effectiveness of user stories in supporting systems development, has been solved.

Objectives

We review the studies that investigate or develop solutions for problems related to ambiguity in user stories. We investigate how these problems manifest themselves, what their causes and consequences are, what solutions have been proposed and what evidence of their effectiveness has been presented. Based on the insights we obtain from this review, we identify research gaps and suggest opportunities for future research.

Methods

We followed Systematic Literature Review guidelines to review problems investigated, solutions proposed, and validation/evaluation methods used. We classified the reviewed studies according to the four linguistic levels of ambiguity (i.e., lexical, syntactic, semantic, pragmatic) proposed by Berry and Kamsties to obtain insights from patterns that we observe in the classification of problems and solutions.

Results

A total of 36 studies published in 2001–2020 investigated ambiguity in user stories. Based on four patterns we discern, we identify three research gaps. First, we need more research on human behaviors and cognitive factors causing ambiguity. Second, ambiguity is seldom studied as a problem of a set of related user stories, like a theme or epic in Scrum. Third, there is a lack of holistic solution approaches that consider ambiguity at multiple linguistic levels.

Conclusion

Ambiguity in user stories is a known problem. However, a comprehensive solution for addressing ambiguity in a set of related user stories as it manifests itself at different linguistic levels as a cognitive problem is lacking.

Introduction

Agile Software Development (ASD) has proven its success in delivering high-quality software [1], [2], [3], supporting changes in requirements and priorities [4,5], accelerating software delivery [6], [7], [8], [9], and better aligning IT solutions to business needs [10,11]. A distinctive feature of ASD is the continuous attention paid to requirements in project teams’ practices like iterative planning, daily stand-up meetings, retrospectives, and iterative reviews [11], [12], [13]. Iterative planning enables Product Owners (PO) and developer teams to gradually refine their understanding of the initial requirements and discuss how to deliver a software product that meets those requirements. Progress is constantly monitored through daily stand-up meetings to discuss prioritization of the requirements and to assess whether meeting those requirements can be accomplished in time and within budget. Iterative reviews obtain feedback from the client on the software product in development and look back at what has been accomplished. Retrospective processes investigate what can be done better in the next iteration.

Those practices are facilitated by a communication instrument that refers to the requirements. Preferably, requirements are described using a language that is familiar to both POs and developers. In ASD, the user story technique is a widely used artifact to express commitments between the development team and (a type of) user [14,15]. User stories are written in a semi-structured natural language from a user‘s perspective on the required software system's functionality [15], [16], [17]. Throughout the project lifecycle, user stories help to share the understanding of the expected system goals and functions [4,16,18,19]. Further, user stories are beneficial for monitoring progress towards developing the required system functionality, identifying persisting problems, and improving customer satisfaction [20], [21], [22], [23], [24].

Despite empirical support for these benefits (e.g., [18,19,25,26]), several studies showed that user stories are prone to ambiguity [24,[26], [27], [28]]. Based on these studies, we describe ambiguity as problems regarding the articulation of requirements as user stories, which cause doubtful, imprecise, and multiple interpretations of these requirements. These problems typically originate in different ways of articulating requirements and differences in application domain knowledge.

Although ambiguity of requirements impacts the system development process and its outcomes, we are not aware of any secondary study that reviewed and synthesized the state-of-the-art of the academic research that addresses this problem specifically for user stories. Therefore, in this paper, we investigate how research has dealt with user story ambiguity and what the outcome of this research is. Based on this review, we assess whether any research gaps remain and whether they provide interesting research opportunities.

To achieve these objectives, we perform a literature review of the published research on ambiguity in user stories. Following the Systematic Literature Review methodology [29], we investigate the following research questions:

RQ1: How are ambiguity problems defined?

RQ2: What solutions are proposed for ambiguity?

RQ3: What evidence of the effectiveness of these solutions is available?

Using a linguistic classification of ambiguity issues, we contribute novel insights into the current knowledge of understanding, avoiding, and resolving ambiguity in user stories. Further, based on the review, we identify research opportunities to enhance the effectiveness of the user story technique in supporting Requirements Engineering (RE) activities in ASD projects.

This paper is divided into seven sections. This first section presents and motivates the goal of our review study. Section 2 presents a simple, fictitious example that illustrates what ambiguity in user stories could be and how it could arise, as background for our study. Section 3 reviews related work on ambiguity in requirements, not specifically confined to user stories. Section 4 describes our research methodology. Subsequently, Section 5 presents the results of our systematic literature review. Section 6 discusses the results, exhibits the limitations of the research, and formulates recommendations for future research. Finally, Section 7 concludes the paper.