284 Y. Lin et al. / Multi-Agent System for intelligent Scrum project management
ements of the SandBox, which are then placed in the
backlog. These features are called user stories.Itisnat-
ural in this spirit that Scrum emphasizes the possibil-
ity at the end of each sprint to leverage feedback from
project stakeholders and indicators to bring forth posi-
tive change. This retrospective is an opportunity to as-
sess the sprint that just ended either on a technical or
an organizational point of view.
The use of a kind of blackboard (dashboard)isrep-
resentative of the Scrum philosophy. Informations col-
lected on this dashboard should be synthetic and p erti-
nent. In this dashboard, the team uses a p articular time-
line that maps the duration of each sprint on which are
listed the major events that have marked the period. As
activities are dynamic by nature, the timeline allows
representing the work already done and the next steps
that have to be achieved to complete the sprint.
Like other software development methods, Scrum
Masters estimate the effort that the team will provide
to achieve the expected goals. This kind of planning
is based on the concept of release, which is in fact the
time period matching sprint. The release plan is up-
dated at the end of each sprint. Planning for the release
is based on the estimation of the content of the backlog
and the ability of the team to reach the sprint.
3.2. Use cases analysis
The goal of our Scrum tool is to provide an as-
sistance platform for distributed Scrum users. On the
one hand, the system aims at modeling and automat-
ing human activities and concepts during develop-
ment projects following the Scrum methodology. More
specifically, it aims at managing data/knowledge about
elements and events appearing during the Scrum pro-
cess. On the o ther hand, the system monitors projects
by estimating both the cost and the time of each task
whatever its granularity. Moreover, the system can
monitor each human worker in order to compute his
efficiency and provides suggestions to Scrum Masters
for helping them taking decisions.
Figure 1 presents the analysis of the Scrum tool in
terms of use cases. Obviously, the presented cases and
actor are only a part of the complete analysis.
The only actor presented in Fig. 1 is Scrum mas-
ter. A scrum master use of the tool consists in manag-
ing projects with the tool assistance. This project man-
agement usage implies three use cases included in the
“Manage Scrum Project” one. These three use cases
are: “Define stories”, “Assign stories” and “Compute
indicators”.
The “Compute indicators” case is an abstract use
case. It generalizes cases that compute any indicator,
which may help the Scru m master during project man-
agement. Three use cases are inherited from this ab-
stract case: “Compute workers efficiency”, “Compute
estimated cost” and “Compute estimated time”. Each
one computes a different indicator. The first computes
for each worker it efficiency in terms of finishing tasks
on time. The second computes the estimated cost of
the project. The third computes the estimated time and
thus estimated end date for the project.
3.3. Features of the Scrum tool
Based on the conventional functions of Scrum soft-
wares, in the presented Scrum tool, a user should,
firstly, register himself. Once identified, the user will
have a role assigned within the Scrum project. With
the confirmation of identifier and password, a logged
user can create new projects as Scrum Master or op-
erates on all invoked projects. Each role has specifics
allowed operations. The possible roles were described
in Section 3.2. Among these roles one can cite: Scrum
Master, Product Owner or Developer, and, for exam-
ple, each developer could update it spent time (in hours
or workdays) on his or her assigned tasks.
In the meanwhile, each project owns the following
specific elements: a Dashboard (for representing the
project’s last activities), a Sandbox (for building tem-
porary user stories or tasks before being valid in Back-
log), a Backlog,aTimeline,aRelease plan,aSprint
plan,andaTe am.
Users could build and edit user stories, update the hi-
erarchy of tasks with estimated effort (hours/workdays)
in the Sandbox and Backlog, and could build and edit
sprints and releases to implement user stories or tasks
selected from Backlog for one project. Projects mon-
itoring is realized through specifics (for each project)
burn-down charts of sprints and releases. The function-
alities previously described are, more or less, present
in existing Scrum software tools and also in the tool
presented in this paper.
Considering the distribution of the users of our
Scrum tool and the distribution of projects’ data, the
system has been deployed as a web-based system using
Java technologies. This tool relies on the modeling of
Scrum Methodology by one Organizational Ontology,
K-CRIO, and, on a Multi-Agent System (MAS) ani-
mating the functionalities. Agents are used for updat-
ing estimated costs o f each project and each worker’s
efficiency, when any change happens in the project.