User stories (US) are short sentences written in natural language, structured around 3 dimensions (WHO/WHAT /WHY ). They describe functionalities of the to-be software system and constitute the primary requirements artifacts used in agile methods. Originally, a few US templates have been suggested but these were written in a completely informal manner without guidance. In time some research has been made to furnish better guidelines when creating US and develop frameworks to increase their overall quality. Some of these frameworks are based on conceptual modeling, some others on linguistic approaches. The application of these frameworks in real life contexts nevertheless remains an open issue. To evaluate their applicability several experiments have been conducted in various settings. The present paper aims to summarize these experiments and suggest some others for future work.
User stories (US) are artifacts often used in agile methods (i.e., Extreme Programming and Scrum) and tools (i.e., Jira) to describe user desiderata during the requirements’ elicitation stage preceding the implementation of the system. These artifacts are purposed to document major functionalities and/or indispensable features that the to-be system needs to satisfy; they are commonly built around the WHO-dimension (i.e., explicating the role asking for the functionality), the WHAT -dimension (i.e., describing the functionality), and the WHY -dimension (i.e., justifying the reasoning for implementing the functionality). The benefits of utilizing these artifacts are mostly associated to the understandability and readability that they yield to the requirements’ gathering process especially when perceived individually or in small sets.
Nevertheless, the utilization of such a simple requirements’ specification format does come at a cost. A lot of freedom is given in their creation which is in a sense very positive for users nonfamiliar with technical aspects but could lead to poor consistency in the way they are expressed and the overview and consistency of the requirements they express. Also, US do not provide visually-aided requirements representations that would help with the sorting of multiple (and extended) sets of US and would provide alternative modeling configurations for the impending system. The following section provides a discretionary collection of experiments purposed to delineate some of the factors that may be influencing a more qualitative appropriation of US artifacts on behalf of novice modelers.
To begin with, the studies of Dapiaz et al. [
The problem of poor representability concerning the nature, granularity, and
interdependence of the constituted elements within a US set has been acknowledged in the study
of Wautelet et al. [
The study performed by Wautelet et al. [
Role name : String dimension : String = WHO
1..n WHAT
WHY
Element of EPIC US Links Means-end link
Decomposition link Hard-goal
Soft-goal
Task
Capability
Contribution link(+,-) (a) Icons used for representing user story’s elements
Role_1 Hard_Goal_1
US1: As Role_1, I want Task_1, so Task_2 Figure t2ha:t HUarsdi_nGogal_R1 ationale Tree to Structure UTsaesk_r1 Stories’ Sets.
Capability_1 US2: As Role_1, I want Capability_1, so that Task_2 Soft_Goal_1 build and use a Rationale Tree diagram1 out of an existing US set. Both groups had to start by
US3: As Role_1, I want Soft_Goal_1, recognizing and tagging elements of the RWole_H2O-, WHAT-, WHY-dimensions of a given US set to
Task_3
the conUsSt4r:uAscRtosle_o2f,ItwhanetCuapnabiilfieityd_2,model of [
User Stories (US) Strategic Rational Diagram (SRD) diference in the ability to build a Ration(aSlRTDr)ee between novice modelers and more experienced researchers since all test subjects produced artifacts that would describe rather well the software ²problem.
The experiment of Wautelet et al. [
# #!$ & # " % Tree diagrams. The experiment was performed on 34 master-level students composed of 2 groups, one using the raw US set while the other using the QUS-compliant one. The exact goals were i) to identify the concepts of non-functional requirements, missing requirements, epics and themes; ii) to be able to build a Rationale Tree diagram; iii) to evaluate the impact of the Rationale Tree on the identification of these concepts; iv) to evaluate the impact of using an improved in quality (through QUS) US set on the ability of to identify the aforementioned concepts. Overall, the authors could not conclude with certainty whether the improvement of the quality on a US set could improve the ability of novice modelers to identify crucial constructs of a specific modeling case (i.e., missing requirements etc.). Nonetheless, the experiment was able to portray that improvements in the quality of US is correlated with an enhanced ability on behalf of the modelers to identify and represent elements like tasks, capabilities and links.
The studies of Tsilionis et al. [
While the experiments described in the previous section focus on conceptual modeling as an
approach to help writing better US or making better use of US, a diferent stream of research
has investigated the quality of US from a linguistic perspective. Even when highly structured
because of the use of predefined templates, US are essentially a textual format for describing
requirements, and are thus prone to ambiguity just as any other type of requirements described
in natural language. Recently, Amna and Poels performed a systematic literature review of the
research on ambiguity in US [
To help identifying issues with US that possibly result in ambiguity, we are developing a
framework that classifies these issues according to the linguistic level at which ambiguity
manifests itself and the consequence of this ambiguity in terms of requirements quality (i.e.,
vagueness, inconsistency, insuficiency, duplication). The framework illustrates the issues with
examples (as kind of anti-patterns) and also provides examples of how the issues can be resolved.
The issues themselves are based on quality criteria taken from the QUS framework proposed by
Lucassen et al. [
To test this idea (and the framework itself), a first ’laboratory’ experiment is planned. The experiment will involve advanced students, including both IT students and business students with a major in IT. These students have preliminary knowledge in Requirements Engineering (RE), US writing and reviewing, and Agile Software Development (ASD), and thus act as proxies for real developers. Participating students will be randomly assigned to one of two groups. Each group is required to review a set of US in which we have injected problems related to the issues covered by the framework. The treatment group will be instructed to make use of the framework to detect these problems, while the control group will be asked to do the same, without the help of the framework. Participants are required to tag the US dimension WHO/WHAT/WHY that is problematic, and will also be asked to provide a short explanation for the potential ambiguity issues they identify (i.e., why is it problematic?).
Both groups will first receive some training (e.g., a tutorial) to make them aware of requirements ambiguity and its consequences for software development. Prior to the experiment, a short questionnaire will be distributed to collect information regarding the participants’ profile. After the experiment, participants in the treatment group will be asked feedback regarding the usefulness of the framework. Apart from that we will compare the number of problems identified to the total number of problems injected (i.e., an absolute measure of how efective the framework is) and also make a comparison between both groups (i.e., a relative measure of efectiveness). More detailed analysis will be performed for the diferent linguistic levels of ambiguity and the requirements quality problems that might be caused by ambiguity in US.
This paper presented a review of experiments that have been conducted in US modeling. Those are typically designed to investigate the efectiveness of artifacts to comprehend the correct meaning of user stories. While conceptual models have been commonly used as artifacts to make better sense and use of US, linguistic approaches can help in identifying and ultimately avoiding badly written US. We are currently developing a framework based on such linguistic approach, and plan an experiment to evaluate its efectiveness and perceived usefulness.