Keywords

1 Introduction

Agile software development methodologies, such as Scrum, are being adopted by many software companies, due to their lightweight and adaptive nature, seeking mainly deal with the lack of predictability that is common within the traditional development process. According to agile principles the highest priority is to satisfy the customer through early and continuous delivery of valuable software [13].

Nonetheless, due to lack of awareness about usability issues during agile development, the focus is not specifically on creating a design with good usability [11]. Customers often focus in core functionalities. Especially when customers are involved in providing constant feedback during software development, they are able to verify, for instance, the ease of use of a system under development [25]. However, the usability can be better assessed from the end-user experience perspective [23].

Agile approaches emphasize different design styles, once the quality of design is essential to maintaining agility. Design is considered a continuous activity that should be performed throughout the software development process rather than to be an entirely up-front activity [13]. The interest of integrating the User Experience Design (UXD) into agile methodology practices has been increased in the last decade in order to provide high quality user experience, and usability as an important item to add more value to the software [18].

Many strategies have been employed, including some UX professionals who have found ways to incorporate successfully UXD into their agile projects [2, 30]. However, few proposals concern to incorporation of design methods and more suitable artifacts to support the communication between designers and agile teams working closely. Artifacts in an agile environment are important mechanisms to maximize the transparency of information, and support decisions during the software development [27], while the UXD artifacts are produced to outline useful solutions from understanding users’ needs, tasks, and context of use [3].

Considering that the shared use of artifacts by both teams (designers and programmers) is an important instrument to support the integration of the UXD methods into agile practices, this paper presents a proposal to the incorporation of UX aspects including usability recommendations in the elaboration of user stories, from interaction scenarios. User story is one of the most popular artifacts for specifying and communicating agile requirements. In most cases, however, the user stories do not address usability aspects, and take no account of real users’ needs and behaviors [15]. Recently, in the course of a research project in a software industry, we detected that the Scrum teams were having difficulties to insert UX aspects in their stories to define user interaction requirements. In this paper, we describe the solution found to help practitioners to write user interaction stories called UserX Stories.

The remainder of this paper is organized as follows: Sect. 2 introduces the background about agile requirements engineering, including usability aspects; Sect. 3 some considerations about methodology, and research issues; Sect. 4 presents the research context, the steps to build and evaluate the artifact adapted from user stories, discussing the outcomes found in practice; and finally Sect. 5 presents the conclusions and points out directions for further works.

2 Background

Agile development is more flexible concerning elicitation and management of requirements than traditional software development, for the purpose of a quick reaction to changes in order to match customer needs [13]. The main practices used in the agile methodologies to transfer ideas from the customer to the development team are the face-to-face communication and frequent feedback [26]. These practices allow the adaptation of requirements that are discussed in detail with the customers during the development process. The agile requirement specification is not centralized in one phase before development; instead, this activity is evenly spread throughout development [4]. Rather than written specification for creating extensive requirements documents, agile methodologies usually adopt more simple techniques. In Scrum software projects [27], the most popular agile methodology, the user stories are artifacts adopted to define requirements in a high-level [8].

User stories are defined focusing on customer value, unlike other forms of requirements specification, which focus on system operations [25]. User stories are written throughout the agile project in a common language, intelligible to the users, in an effort to keep the attention and awareness on the needs of the users to emphasize their goals [8]. Everyone on the agile team participates in the writing of the stories with the goal of creating the list of features (product backlog) that describe the functionalities to be added over the course of the project [7]. Once that user stories contain just enough information to drive the development, more details about the requirements can be exploited by the development team through a conversation directly with the customer and/or other stakeholders [16]. Acceptance criteria are commonly added to user stories to guide the acceptance tests, in order to verify whether the stories were developed exactly how the customer expects [7].

According to Ramesh et al. [25] and Inayat et al. [16], a major concern about the iterative requirements engineering in agile development is the inadequate attention given to non-functional requirements - often ill-defined and ignored - during early development cycles. Overall, software engineers deal with usability as a non-functional requirement, believing that it can be considered later in the software development [28].

Usability requirements are qualitative attributes that specify user effectiveness, efficiency, or satisfaction levels that the system should achieve [23]. Some studies have highlighted the relationship between usability and functional requirements, aiming identify functional usability recommendations [19, 20]. According to these studies, usability features, especially those with functional implications, should be dealt as early as possible and included along with all the other requirements features, in order to provide a quality user experience and to avoid any rework and further unnecessary costs due to required adjustments.

3 Methodology and Research Issues

The last years, we have developed a project in partnership with a software industry to integrate UX in their software development process. This company has more than thirty years of experience in the development of ERP (Enterprise Resource Planning) systems for several market segments. Besides mechanisms and techniques to improve the usability of the ERP systems, other objective of this project has been to propose more suitable artifacts to support the integration of UX concepts within Scrum projects, agile method recently adopted by the company. Aiming to improve the communication of usability issues between UX designers and Scrum teams, we proposed previously a protocol for communication of design solutions and usability recommendations, whose findings can be seen in [5]. In this paper we present a new proposal of artifact incorporating UX aspects in user stories.

In order to carry out the research within the software industry, allowing us to work closely with the agile teams, we have applied a research approach called SoftCoDeR (Software Cooperative Design Research) [6]. This research approach is based on a qualitative method of Action Research called Cooperative Method Development (CMD) proposed by Dittrich et al. [10], matched with the Design Science Research framework proposed by Hevner et al. [14]. On one hand, CMD approach provides a structured process of research, in which three phases are defined: (1) Understanding Practice (qualitative empirical investigations), (2) Deliberate Improvements (aiming to solve the problems identified in the first phase) and (3) Implement and Observe Improvements (checking the effectiveness of the improvements). On the other hand, DSR provides the guidelines to design artifacts of value based on both real need of industry (relevance) and scientific knowledge (rigor of research).

In the following section, we describe the research context and the three phases of the SoftCoDeR approach that was applied to answer the specific research question concerning to the building and evaluating of the artifact adapted from user stories, integrating UX aspects elicited from interaction scenario.

4 UX Aspects on User Stories Elaboration

The aforementioned protocol for communication of design solutions and usability recommendations had been proposed specifically to supply a need of the designers of a formal procedure to report results of user testing to Scrum teams. The proposed protocol was based on two UX concepts: personas and Nielsen’s heuristics. Both UX concepts were primarily used to establish a common vocabulary among the developers, testers and UX designers.

Personas have been widely employed in the fields of usability and user experience as an artifact to describe groups of typical users by the creation of hypothetical archetypes. The personas can help create an empathy with users, facilitating the understanding on characteristics, behaviors and their deeper needs [24]. In addition to this, personas also can help in the development of interaction scenarios, and/or to describe tasks to the usability testing planning [9].

Nielsen’s heuristics are one of the most used usability guidelines for user interface design, developed by Nielsen and Molich in the early 90’s [22]. Also, these guidelines are commonly used to support the critical analysis in usability inspections (heuristic evaluation), and to check the problems identified in usability testing [12].

We have observed in practice that such concepts - personas and Nielsen’s heuristics - can to improve the level of awareness and concerns on usability aspects of UX designers and developers (programmers and testers) [5]. The incorporation of both concepts to report the usability problems identified in user tests increased the level of reliability of the agile teams regarding the recommendations proposed by designers. However, we observed that the product owners (POs) were having difficulties in understanding such usability concepts, and also they did not know how to incorporate UX issues in the product requirements.

Considering that the POs were most familiarized with user stories to deal with agile requirements, we have suggested an adaptation of this artifact incorporating the vision of the user experience by employing the same UX concepts used on protocol for communication of usability recommendations. Thereby, a research cycle was started in order to answer the following question:

RQ: How could personas and Nielsen’s heuristics concepts be incorporated into the User Stories?

4.1 Understanding Practice

In the first phase, we have carried out (i) an ethnographic study in order to understand how the user stories were being developed by POs; and (ii) a technical literature survey, aiming to investigate the use of user stories in agile practices.

Regarding user stories development (i), we found out that these were being written in a more traditional way, as the template popularized by Mike Cohn [7], shown in Fig. 1. Such user stories were stored in a software used for issue tracking and project management, instead of written on index cards or sticky notes.

Fig. 1.
figure 1

User Story template

Full size image

As for the results of literature review (ii), we found some recommendations about how to deal with usability issues and user stories together. Moreno and Yagüe [20], for instance, have identified three ways to incorporate functional usability requirements with user stories: (1) adding new stories to represent the requirements that are directly derived from usability (called usability stories); (2) adding or modifying tasks in US (detailing as needed); and (3) adding or modifying acceptance criteria. According to these authors, there are usability recommendations that: have positive impact on the final quality of use of software systems; can be considered as functional usability requirements that complement the traditional requirements; and can be documented as user stories - the usability stories - because both are similar. On the other hand, Barksdale et al. [1] have used conceptual maps to design a complete picture to the user, detailing the connections between user stories and scenarios. Scenarios are a type of design artifact commonly used to describe how a particular user uses the system for a specific task, considering the context and environment where it will be held [17]. The conceptual mapping was proposed to mitigate existing conflict between designers and agile teams to communicate usability and interaction requirements during the agile project. Still on scenarios, Sohaib and Khan [29] also recommended the use of them along with user stories during the exploration phase, and in addition, heuristic evaluation during acceptance testing.

4.2 Deliberate Improvements

Bearing in mind the research question, and from the outcomes of the literature review and the ethnographic study, we proposed to the teams a grammar - incorporating personas and Nielsen’s heuristics - to describe interaction stories, that we called UserX Story. The UserX Stories should be written from scenarios associated with user’s actions and respective feedback necessary to achieve goals supported by the system.

Figure 2 shows the first version proposed to the UserX Story, whose traditional grammar of the user story was modified, by replacing (1) <type of user> by <personas>, to provide a clear target for developers to focus on; and (2) <some reason> by <Nielsen’s heuristic(s)>, to highlight, from usability point of view, the positive impact on user interaction to achieve their goals.

Fig. 2.
figure 2

Initial proposal to UserX Story template (1st version)

Full size image

The initial proposal was discussed between the researchers, POs, Scrum Master and UX designer. From the discussions between researches and practitioners, the artifact had been improved, resulting in a second version to the UserX Story. In the second version (Fig. 3), the user stories would be expanded from the outcomes of the data collected in the user research phase. User research focuses on understanding user behaviors, needs, and motivations through observation techniques, task analysis, and other feedback methodologies, e.g. the usability testing and the recommendations pinpointed in the aforementioned communication protocol.

Fig. 3.
figure 3

UserX Story template (2nd version)

Full size image

The UserX Stories are told from the perspective of the persona, who needs a particular condition for interaction. Such a condition can meet multiple personas. The stories describe an interactive process wherein the persona has a goal to achieve, for this s/he acts on the interface (interaction), to perform tasks (steps /features to effect the action) in a particular context (usage pattern). The persona will assess whether the objective was achieved interpreting system feedback. Aiming to verify whether stories were developed such that it exactly met the user interaction needs, the acceptance criteria should describe the action, the set of conditions, and the Nielsen’s heuristics (action/feedback) that will be satisfied once the goal is successfully achieved.

The workshop entitled “Interaction Stories” was organized in order to make a warm up for the creation of stories adding the vision of UX through the use of personas and Nielsen’s heuristics. Table 1 shows some information about the six POs who attended the workshop. All the participants had more than ten years of experience in the IT field. However, five out of the six participants had little experience with agile methodology (less than a year).

Table 1. Overview of the workshop participants
Full size table

The workshop was divided into (i) explanation of the concept of user story, personas and Nielsen’s heuristics (ii) presentation of the UserX Story; and (iii) an exercise of writing stories from the proposed template, including the acceptance criteria. Some data collected with end-users during a workshop about “User Research” techniques previously performed with another group of participants, were provided as supplementary material to support the proposed exercise. Some personas were also included in this material. At the end of the workshop activities we discussed with the POs the next step for implementing the interaction stories in real projects, in order to evaluate the proposed artifact.

4.3 Implement and Observe Improvements

In this phase, the POs had one month to implement the UserX Story into one of their projects. After this period, researchers carried out individuals’ interviews with the POs to collect their experiences with the implementation of UserX Stories. Figure 4 shows an implemented UserX Story for the redesign of part related for the issuance of reports for a Tax Bookkeeping sub-module.

Most POs had shared the UserX Story with their respective Scrum teams, which reacted positively, approving the use of the interaction stories, as well as the proposed template. However, two POs had not implemented the UserX Stories in their projects, since they were working on small changes that were related exclusively to business rules (legal requirements), and such changes would have had no impact on user interaction.

As we have discussed with company’s practitioners, further tests will be needed to evaluate the procedures in which user stories are written from items reported in the protocol for the communication of usability recommendations. However, it was suggested that, firstly, the items reported in the protocol should be discussed between UX designer and Scrum team. And then, whether the Scrum team agrees with the recommended item, the item would be written in UserX Story template with the participation of the UX designer. Otherwise, the recommendation is discarded if, for example, there are technical limitations preventing it to be implemented.

One issue identified during interviews was related to the level of detail that acceptance criteria should be written. One of the POs commented that your criteria seemed quite detailed; thinking that reaching a greater level of detail should be the role of testers. Generally, acceptance criteria should be detailed enough to define when the user story is satisfied. Nonetheless, it is worth noting that there is some confusion about acceptance criteria and test cases. According Nazzaro & Suscheck [21], acceptance criteria should answer the question, “How will I know when I am done with the story?” and test cases answer the questions, “How do I test and what are the test steps?” Therefore, test cases can require more detail than acceptance criteria. Remembering that, the main focus of the acceptance criteria in UserX Story is satisfying usability guidelines.

Fig. 4.
figure 4

UserX Story and acceptance criteria implemented by a PO

Full size image

5 Conclusion and Further Work

The outcomes of this work are part of a set of actions performed together with professionals from a company developing ERP systems, whose main objective is the incorporation of interaction design into the software development agile process.

This paper presents a solution to incorporate UX aspects into user stories, aiming to guide and facilitate the work of the agile teams in terms of usability requirements. The UserX Stories are told from the perspective of the persona representing a group of users; and the heuristics are intended to reinforce the acceptance criteria to highlight the positive impact of user interaction if the conditions were satisfied.

Although the proposal of interaction stories has already been approved by the majority of company’s agile teams, more research is required in this area through the involvement of further organizations and agile teams. We found out that further tests will be needed to evaluate the cycle in which UserX Stories are written from results reported in usability tests. In the further works, we intend to draw up a set of guidelines to target the use of the UserX Stories. Another issue deserving further research refers to the granularity of the acceptance criteria.