Although goal modeling using i* provides several benefits to requirements analysis, it may be difficult to use it with agile methods. This paper proposes a method that combines i* with Scrum, integrating the initial phases of Tropos with Scrum practices. In summary, goals in a Strategic Rationale model are prioritized to a release and then refined into user stories. The stories are implemented in Sprints, following the Scrum activities. This paper also reports the use of this method to develop a mobile app that brings political decisions closer to the Brazilian electorate.
User story [
This paper proposes a method that combines goal modeling, using i*
models, with agile software development. We integrate the initial phases of
Tropos, Early Requirements and Late Requirements, with Scrum practices.
Differently from works that propose transforming i* models into user stories
[
Copyright © 2016 for this paper by its authors. Copying permitted for private and academic purposes.
To present the method, this paper is organized as follows: Section 2 presents Scrum and user story. Section 3 describes the method, and Section 4 presents an experience report of how the method was used to develop a mobile app. Finally, Section 5 presents a discussion and some conclusions. 2
Scrum is an agile framework for managing the development of complex
products and services [
A project using Scrum begins with the creation of a product backlog,
representing a list of requirements for the system. This backlog is created and
prioritized by the product owner, while the development team helps
estimating each item in it. The work on items of the product backlog is executed in
sprints. A sprint is a time-boxed iteration to create a product increment with
value to the customer or user. Based on the product backlog and the vision of
the product owner, the Scrum team agrees on a sprint goal, which may be a
specific set of backlog items or a set of features. The items of the product
backlog that will be developed in the sprint are organized in a sprint backlog,
along with a plan to deliver the product increment. To create this plan, Scrum
teams normally break each item into tasks, and estimate the effort to complete
each one of them [
While Scrum does not impose a requirement representation for the
product backlog, many teams use user stories [
In order to bring goal modeling into the Scrum framework, we propose a
method based on Tropos [
The first phase, Early Requirements, is similar to the one proposed in Tropos, but adapted to the Scrum framework. Therefore, a developer with requirements engineering skills and the product owner model the system’s stakeholders into social actors: defining roles and intentions. They create the Strategic Dependencies (SD) Model by listing the possible dependencies between each pair of social actors. Then, they make the Strategic Rationale (SR) Model by listing possible hardgoals, softgoals, plans (we use “plan”, from Tropos, instead of “task” to avoid a confusion with Scrum’s “task”), and resources within each social actor’s boundary and describing how these goals affect each other.
On Initial Late Requirements, the second phase, the developer and product owner introduce the system-to-be as a new social actor, and update the SD Model to include dependencies the initial actors may have with the system (which sometimes replace old dependencies). Similar to the first phase, they make the SR Model for the system defining goals that help accomplish the dependencies in which the system is a dependee.
The third phase, Goals Refinement, is the core of the method. This
phase should be executed as a release planning [
The fourth and fifth phases, respectively, Sprint Planning and Implementation, is executed in all sprints. Sprint Planning consists of the product owner selecting a subset of user stories (therefore, a set of plans and goals) with a theme in mind and considering the team velocity. The team should split each item into tasks and create a sprint backlog.
As in Scrum, an Implementation phase follows each Sprint Planning phase, and implementation methods should vary according to team and project. Yet, the phase starts by the assignment of developers to the sprint backlog items. The progress of development should be available to the team by pointing out which items (plans, user stories, and their tasks or components) have been completed. 4
The method was created and used during a capstone project of a Computer Engineering course at Universidade de São Paulo (USP). The idea was to develop a mobile app, named Appopuli, which brings political decisions closer to the Brazilian electorate. The team was composed of two final-year students, working as developers and product owners, and an advisor, working as a Scrum master.
During the Early Requirements phase, we identified the following actors: Electors, Politicians, Political Parties, and Press. We elicited a set of dependencies such as “an Elector depends on the Press to find news about candidates” and then the rationale for each actor, writing goals like “recognize good candidates” (an Elector goal).
During the Initial Late Requirements phase, we included the System actor and elicited dependencies such as “the Elector depends on the System to express their opinion.” The rationale of the System actor resulted not only in many hardgoals representing subsystems and components, but also in a few softgoals representing desirable functioning qualities.
In the Goals Refinement phase, we decided that dependencies with the Political Parties and the Press had lower priorities than the Electors’ and Politicians’. We also narrowed the scope of our project to the Municipal Chamber of São Paulo. Therefore, only 15 hardgoals out of 40 goals inside the System actor boundary were refined in order to create a minimum viable product during the sprints. This phase resulted in 30 plans such as “Rate a politician between 1 and 5 stars,” which has a small set of user stories, including “an Elector may change the number of stars previously given to a politician.” An example of the refinement is presented in Fig. 1.
The rest of the development was divided in four sprints. Each sprint executed both the phases Sprint Planning and Implementation. Only one of the final-year students executed these phases, as the other student left for an exchange period. The first sprint focused on building a simple app that shows basic info on every alderman of São Paulo. Planning it meant choosing which user stories would be implemented. For instance, picking “a user may search aldermen by name” rather than “a user may search aldermen by political party.” Differently from the method, we split the user stories into tasks during the Implementation phase. The three other sprints were planned similarly.
During Implementation, each sprint backlog was managed through the list of tasks to satisfy a set of user stories. Some tasks were described as the classes and methods to be implemented. The App was developed for Android phones, using Java; the server side of the application was developed in Ruby, using the framework Ruby on Rails and a PostgreSQL database. By the end of the fourth sprint, users could: sign up at the Android app; choose aldermen and proposed laws to follow; see any activity from followed concerns on a timeline; check details of a proposed law (including their original PDF documents); among other functionalities. 5
This paper proposes a method that combines goal modeling, using i* and based on Tropos, with the agile framework Scrum. We also describe the use of this method to develop a mobile app. The proposed method is based on the idea that goals are more stable than requirements. Therefore, the goal model will not change frequently, and it would be possible to use it in release planning with few changes during sprints. Yet, the benefits of goal modeling would allow a better understanding of the system to be built, help reasoning about alternatives, and prioritize the development based on goals. These benefits should compensate the addition of an artifact – which is a disadvantage from an agile perspective.
As this is an initial proposal, there are some important future works. The method should be improved by including some guidelines and a more detailed description, specially in the Goal Refinement phase. In addition, it should be evaluated in a project with a real product owner and a bigger development team. Finally, the benefits of the method should be analyzed considering its impact to agility.
Acknowledgements. We thank Diego Henrique dos Reis Marques for his participation in the project.