AgileCritPath: Identifying Critical Tasks in Agile

Environments
Rachel Vital Glaucia Melo Toacy Oliveira Paulo Alencar Don Cowan
PESC/COPPE David R. Cheriton PESC/COPPE David R. Cheriton David R. Cheriton
Universidade Federal School of Computer Universidade Federal School of Computer School of Computer
do Rio de Janeiro Science do Rio de Janeiro Science Science
Rio de Janeiro, Brazil University of Waterloo Rio de Janeiro, Brazil University of Waterloo University of Waterloo
[email protected] Waterloo, Canada [email protected] Waterloo, Canada Waterloo, Canada
[email protected] [email protected] [email protected]

Abstract—Planning and monitoring the execution of software proper identification of task dependencies is important to
development activities in agile environments are not trivial proce- maximize project efficiency and reduce risks [5], [6], [7], [8],
dures. One of the main flaws of agile planning is not considering [9], [10].
the dependencies that exist between project tasks. Dependencies
between tasks found in software development project plans may The critical need to manage dependencies found in agile-
lead to the emergence of critical paths, where tasks need to be based software development projects is a topic that has been
handled in a strict sequence because the completion of some tasks already explored in the literature [5], [11], [4], [12], but,
depends on the completion of others. Not managing such critical currently, empirical studies on the subject are still scarce.
paths may reduce team performance and delay product delivery. There is a clear need to investigate this topic further, given
We performed a study to demonstrate that not identifying
dependencies may impair team performance and even increase that the lack of knowledge about task dependencies may
the risk of costly project delays. The study is divided into three have consequences for project duration, coordination, risk, and
parts: (1) an exploratory study performed in the industry; (2) efficiency.
the development of a tool, AgileCritPath, as a way to support To understand the problem of identifying the dependencies
development teams in identifying critical project tasks; and (3) properly between agile projects and software development
an in vivo evaluation of AgileCritPath based on the Technology
Acceptance Model (TAM). The results of the exploratory study tasks, we conducted an exploratory study in a software devel-
provided empirical evidence that there is a need to identify and opment organization. Through this study, we obtained empiri-
control dependencies between the tasks in the development of cal evidence that this is a real problem that can negatively af-
software in agile environments. Using the AgileCritPath tool, fect software development organizations, especially when they
allowed us to introduce the Critical Path Method concepts in use agile methods. After performing the exploratory study, we
an agile software development organization. Moreover, the in
vivo evaluation demonstrated the benefits of managing tasks used the techniques of the Critical Path Method (CPM) to
dependencies. inform a team in a specific software development organization
Index Terms—Software Engineering, Critical Path Method, that already uses agile methods about the critical tasks. We
Agile, Software Development. have also developed a tool, which we call AgileCritPath,
to evaluate the adoption of CPM in an organization. The
I. I NTRODUCTION
evaluation followed the Technology Acceptance Model (TAM)
The software development principles behind the “Manifesto [13] approach.
for Agile Software Development” are widely used in software This paper is structured as follows. After a brief introduction
development project management. Although the adoption of in Section I, Section II describes supporting concepts. Section
such agile principles brings numerous benefits, including the III presents an Exploratory Study. Section IV presents the
delivery of software products on time and budget [1], estimat- AgileCritPath tool and a TAM evaluation of this tool. Finally,
ing and planning projects using agile methodologies is still Section VI presents conclusions and future work.
a complex process. Part of this complexity comes from the
difficulty of identifying dependencies between tasks, which is II. BACKGROUND
a critical factor for coping with agile project failures [2]. The increased adoption of agile practices has caused tradi-
Dependencies between tasks often lead to decreases in tional project management to be redefined.
team’s agility level [3] and can adversely impact the delivery Many agile methods provide some level of management
time of software products. For Bick and his colleagues [4], for tasks, but out of the main techniques applied [14] none
managing task dependencies is a fundamental issue in agile guarantees that teams follow what was planned. Cohn [2], in
software development, because it can be used as a basis to his book ”Agile Estimating and Planning”, addresses the main
define the coordination between project tasks. Additionally, flaws of agile planning. Among them, the author cites that
DOI reference number: 10.18293/SEKE2019-004 tasks are not independent and that it is an error for the agile
teams to plan the tasks as if they were separate, with no need development projects that use agile methods; (2) applied
for task coordination. concepts based on the Critical Path Method to identify critical
In agile methods, the technical work of the development tasks in projects that use agile methods; (3) collected, analyzed
team is defined through tasks. Each team estimates tasks and, and discussed the results. The exploratory study is divided into
generally, they represent a small part of the expected work [2]. the following steps: definition of the study, data collection,
Tasks can be visualized using the Kanban board presented in data analysis, and presentation of results.
Figure 1. Kanban boards visually depict work at various stages
of a process using cards to represent tasks and columns to A. Definition
represent each stage of the process. Cards are moved from
The study was conducted in a Brazilian software develop-
left to right to show progress and to help coordinate the teams
ment company that has a staff of 30 employees, most of whom
performing the work. The Kanban board is a visual approach
are software developers. The organization has been using agile
that teams use to monitor task execution.
methods for at least 10 years. Teams are small, usually groups
of 3 to 8 people.

B. Data collection
The task execution log has been extracted from the Red-
mine1 project management tool. Through the organization’s
task management system, we were able to identify which tasks
were planned and which tasks were performed. We retrieved
data from three iterations of the same project for analysis.

C. Data analysis
Fig. 1. Kanban board example. In this step, we identified the dependencies between tasks.
The dependency identification was performed with the help of
Progress monitoring is an essential activity in Software an experienced developer who was familiar with the scope of
management, whereby it ensures that a project plan advances the tasks, the processes of the organization, and knew the tech-
according to budget, schedule, and quality expectations [15], nological architecture used in the project. Task dependencies
[16]. The implementation of progress monitoring mechanisms were classified into Process and Context dependencies, follow-
in an agile environment is fundamental to the success of the ing a classification suggested in a taxonomy of dependencies
project. [5].
Although the Kanban framework is widely adopted in
organizations, it does not show task dependencies. It is not D. Results and discussion
possible to see on the Kanban board which tasks can block
From the analysis of the data, the projection of the maxi-
the execution of others and, for this reason, the flow of task
mum effort rate per period was obtained. Therefore, regardless
execution becomes unclear to the team.
of the number of people on the team, we can not plan
The Agile Kanban method lacks a mechanism for progress
activities with effort higher than the maximum effort rate. For
tracking. Thus, it needs to be integrated with other methods
the calculation of the maximum effort rate, we consider the
because it does not have a standard definition for software
estimated effort of the tasks performed by the team and their
development and its specific practices have not yet been
respective dependencies.
rigorously defined [12].
However, although managers can have, based on the Kanban Figure 2 illustrates the planning performed by the team (blue
board, support to understand progress status and progress line) and the maximum effort rate of the tasks (red line). The
better, they can not get information about the impact of the red line represents the shortest time to complete the activities
execution of the flow of tasks, especially when it comes to and indicates the maximum rate of production (speed) at which
task dependencies. the team can work. Regardless of the number of people, the
tasks will not be completed before this deadline (red line). In
III. E XPLORATORY S TUDY - I DENTIFYING CRITICAL this case, we can see that the team planned a delivery that can
TASKS not be performed on the expected date.
To correctly understand the dynamics of the organization Table I presents the number of dependencies identified in
concerning project planning in an agile environment, we con- the study and the number of tasks defined by the team, which
ducted an exploratory study in a specific software development are extracted through the task execution log. The number of
organization. Exploratory studies have proved to be adequate dependencies is higher than the number of tasks, within the
in software engineering to study new ideas [17]. three analyzed iterations.
Through the exploratory study, we have: (1) observed the
existence of dependencies between tasks in real software 1 redmine.org
 without delaying the release. In agile environments, Critical
Tasks are identified by building a network diagram of tasks.
This network diagram is built to represent task dependencies.
Figure 3 presents an example of a network diagram with seven
tasks. The solid lines represent dependencies between tasks,
and the dashed lines represent the association of the tasks
from the beginning to the end of the graph. Critical tasks are
identified as the tasks that make up the longest delivery path.

Fig. 2. The burndown graph with maximum effort rate.

TABLE I
P ERCEIVED DEPENDENCIES .

% Process Business
Release Task Dep
Dep Dep Dep
Release 2.12 100 96 96% 52 44 Fig. 3. Network Diagram with Critical Tasks.
Release 2.13 69 77 112% 53 24
Release 2.14 70 84 120% 67 17
B. Proposed Model
Our results show that handling task dependencies may not Figure 4 illustrates in detail the mechanism used to find out
be straightforward when there are many tasks. Another factor the Critical Task in GitHub projects.
we noticed was that there were several tasks, and consequently,
dependencies, that are were not planned but were identified
during the iteration execution.
During the analysis of the Iteration execution log, we
verified that some tasks were discovered during the execution
of the iteration and, consequently, the execution flow of the
tasks changed because the new tasks had dependencies that
should have been considered. This shows that the identification
of critical tasks should occur throughout an iteration, and not
only at the end.
Based on the exploratory study we conclude that there is
evidence that when considering task dependencies it is possible
to find the critical tasks, which if delayed, can have serious
consequences, including the product release delays. Because
of this evidence, we decided to develop the work further and Fig. 4. Illustration of AgileCritPath.
implement AgileCritPath, a tool that could help developers
identify critical tasks. The tool implementation and details are In step (1), the application connects to the task manager to
presented in Section IV. load all tasks and their dependencies. In step (2), the associa-
tions between tasks are created according to the dependencies.
IV. T HE AGILE C RIT PATH T OOL In step (3), the resulting graph is created. Tasks without
The AgileCritPath tool implements the Critical Path Method predecessors are automatically linked to the initial node of the
to be used in agile environments and support teams to identify graph. The tasks without successors are automatically linked to
and prioritize critical tasks that can block the execution of the final node of the graph. In step (4), the Depth-First Search
other tasks and cause costly project delays. (DFS) algorithm is applied to find all paths in the graph. While
reading the path, the total effort to complete the task flow is
A. Identifying Critical Tasks calculated.
During the exploratory study, we identified that some tasks All the found paths are displayed in descending order,
compromise or block the flow of execution of other tasks. from the longest path to the shortest path, according to the
These tasks are referred to as Critical Tasks because they can calculated effort for each path. Next to the path listing is the
decrease the agility level of the team. status of the task, the developer responsible for the execution
The critical path is the longest duration path through the net- of the task, and the effort of each task that makes up the path.
work. The tasks that lie on the critical path cannot be delayed The path size is calculated by the sum of the planned effort
reported in the individual tasks that are part of the path. If the Planning in an agile environment is different from ap-
task is finished, we consider the effort to complete the task. proaches used in traditional plan-oriented software develop-
Knowing all the paths in the network task is important ment models [18]. Rather than employing plans in projects
because we can identify the “Near-Critical Paths”. Other based on a set of predefined factors and constraints, agile
important paths through are considered the “Near-Critical models rely on the human factor to self-organize. In this work,
Paths” if they are at risk of becoming the Critical Path. To we seek to offer systemic support, allowing the information
make this information visible to the team, we display all the to be accessible to all team members, and the decisions about
paths found in the task network. the order of task execution to be made at any time.

V. T HE AGILE C RIT PATH T OOL E VALUATION

The evaluation of the AgileCritPath tool was performed
according to the Technology Acceptance Model (TAM). The
TAM approach was proposed by Davis in 1989 [19] and
suggests the acceptance of a new IT technology depending
on two variables: (1) perceived ease of use and (2) perceived
utility usefulness. For Davis, people tend to use or not use
technology to improve their performance at work - perceived
utility. However, even if a person understands that a particular
technology is useful, its use may be impaired if the application
is too complicated, so effort does not compensate for use -
perceived ease.

A. Procedures
Fig. 5. Query results.
The general objective of using TAM was to evaluate the po-
tential of the AgileCritPath tool in an industrial environment.
Figure 5 presents the result of querying the paths of a task The evaluation was performed in a company that has been
network from a GitHub repository. working in the area of software engineering for 20 years and
adopts development processes based on agile practices. The
C. Architecture model project used in the evaluation was selected by the organization.
AgileCritPath was developed following the architecture pre- The selected company uses Redmine as a task management
sented in Figure 6. tool. For the execution of the study, we modified our tool so
it could access Redmine.

B. Execution
The study was performed in-vivo. In-vivo studies are studies
that involve people in their own working environment under
realistic conditions [20]. Case studies made in an industrial
environment are an important type of in-vivo study since they
allow the analysis of a particular process in the context of a
software life cycle [21] .
To ensure that the study did not impact the organization’s
software development process, we restricted ourselves to ob-
serving the tasks performed in the team’s daily routine and
Fig. 6. The AgileCritPath architecture. added to their lists the activities required to use the tool, as
presented in Figure 7.
The application works autonomously and connects to the Figure 7 presents the activities performed in the organiza-
task manager through an integration API (task manager API). tion. The activities in red are the activities we included so that
The Extract, Transform and Load (ETL) module performs the CPM could be used by the team.
necessary information processing, according to the information At the iteration planning meeting, the team began to include
available in the task manager. An ETL module was developed task dependencies. During the execution of the iteration,
to meet the integration requirements with GitHub, ZenHub and the team performs daily meetings (daily Scrum meeting).
Redmine. The ETL loads objects from the application domain, As suggested in Scrum [22], daily meetings should last 15
which works in isolation from the task management tools. The minutes, where the team discusses what has been done in
Core ACP module loads a task-oriented graph and implements the last 24 hours, the plan for the next 24 hours, and what
a Depth-First Search algorithm that searches for all paths in task impediments (anything that keeps a team from being
the task network. productive) occurred. The meeting is held in front of a
 The participants were asked to identify the benefits and
limitations of the tool. The key highlighted benefits were: the
visualization of dependencies between tasks, as a facilitator to
determine which tasks should be prioritized, and the improved
visualization of the total planned effort to complete critical
path tasks. As a tool limitation, the participants recognized
that it would be nice if the tool could display estimated versus
realized information of the tasks in progress and could provide
more metrics for monitoring work progress.
During the daily meetings using the tool, we were able to
capture observations made by the team as follows:
• The team observed that using the tool allows everyone
on the team to get a sense of what tasks are critical;
• The team found it interesting to leave the critical tasks to

Fig. 7. The activities performed during an iteration.

the most experienced developers on the project, especially
when the deadlines for these tasks are tight;
• Visualizing the critical path is also a way of evaluating
Kanban board. The visualization of the paths calculated by the most complex points of the project;
the AgileCritPath tool was presented at the end of the daily • The team observed that the task priority they provide at
meetings. the time of task planning did not make sense and, in some
During the planning and execution of the iteration, the cases, the team acknowledges that they might have had
participants had access to the AgileCritPath tool, and in the a greater gain prioritizing critical path tasks;
daily meetings, the tasks that were part of the critical path were • The team evaluated the critical path analysis as a tool
presented to the team. The iteration lasted two weeks, and at complementary to the Kanban framework because in the
the end, the participants were asked to answer the questions Kanban framework they could not keep track of the
directed towards the evaluation of the tool. dependencies between the tasks.
At the end of the iteration, the participants completed The lack of knowledge about dependencies between planned
the Participation Consent and Clearance Form, Participants tasks in agile environments emerges in a misaligned business
Characterization Form and the TAM Model Evaluation. The plan that the team may not be able to execute. Also, the
forms were completed individually and without any contact lack of awareness about the dependencies that exist between
between participants. the tasks of the software development process constitutes
C. Discussion a possible explanation for inefficient team coordination and
project delays.
A team of six employees participated in the study. Partici-
The AgileCritPath tool enables organizations to use depen-
pation was free and voluntary. The questionnaire was sent to
dency information across tasks to improve task prioritization
all developers of the company. The participants, in general,
in agile environments by identifying which dependencies can
have a bachelor’s degree, except for one participant, who is in
compromise or block the flow of task execution.
the process of concluding a bachelor’s degree. The academic
experience varies greatly among the research group since In this study, the evaluation of the usability of the Agile-
the team has 2 senior, 1 junior and 1 trainee members. All CritPath tool in the industry was conducted. Usability is one
participants are familiar with the basics of project management of the aspects related to the quality of use of systems, being
and are knowledgeable about the Scrum methodology. one of the most important acceptance criteria for interactive
From the results of the study, based on the Perceived Utility applications in general, and in particular for Web applications
evaluation criterion, we verified that the participants agreed [23]. The acceptance of technology is related to the quality
that the use of the tool could improve the productivity and and use of its systems, the quality of the provided information
quality of the work of the team members. All participants rec- and user satisfaction [24]. Through the use of the acceptance
ognized the tool as useful for performing their tasks. Regarding model, it was possible to evaluate the use of the AgileCritPath
the Perceived Usability Facility variable, the team indicated tool in an industrial environment.
that identifying dependencies between tasks and identifying
VI. C ONCLUSION
the Critical Path as reasonably difficult activities. Even though
the team has indicated difficulties in identifying dependencies Agile approaches are based on the idea that developers can
and evaluating the critical path, 75% of respondents felt self-organize and perform their work collaboratively [4]. How-
inclined to use the tool during the planning and execution of ever, some studies suggest that large and complex software
tasks. Despite having to make a more significant effort in task development projects can benefit from the combination of the
dependency identification, the team recognized the benefits flexibility inherent in agile teamwork and models that support
that the use of the tool can provide. a plan-oriented structure [25], [26], [27].
 Bick et al. [4] and Badampudi et al. [18] propose that [3] C. D. W. Lomas, J. Wilkinson, P. G. Maropoulos, and P. C. Matthews,
organizations should continue to adopt agile methods, includ- “Measuring design process agility for the single company product
development process.” vol. 9, no. 2, pp. 105–112.
ing the established practices of traditional methodologies that [4] S. Bick, K. Spohrer, R. Hoda, A. Scheerer, and A. Heinzl, “Coordination
guarantee more predictability, reliability, stability and effective challenges in large-scale software development: A case study of planning
use of resources. In addition, through analysis of dependencies, misalignment in hybrid settings,” vol. 44, no. 10, pp. 932–950.
[5] D. E. Strode, “A dependency taxonomy for agile software
the team can evaluate the shorter time for product delivery. development projects,” vol. 18, no. 1, pp. 23–46. [Online]. Available:
Not considering the dependencies between tasks can generate http://dx.doi.org/10.1007/s10796-015-9574-1
delivery plans that are not aligned with the reality of the [6] M. Korkala and F. Maurer, “Waste identification as the means for
improving communication in globally distributed agile software devel-
organization. opment,” vol. 95, pp. 122–140.
Considering dependencies on software projects is crucial to [7] M. Shen, G.-H. Tzeng, and D.-R. Liu, “Multi-criteria task assignment in
identifying critical tasks. Critical tasks are tasks that can delay workflow management systems,” in System Sciences, 2003. Proceedings
of the 36th Annual Hawaii International Conference on. IEEE, pp.
the execution of others and thereby delay the delivery of the 9–pp.
product. In this paper, we present an exploratory study that [8] J. Duggan, J. Byrne, and G. J. Lyons, “A task allocation optimizer for
demonstrated that in a real software development scenario, software construction,” vol. 21, no. 3, pp. 76–82.
[9] Y. Jiang and J. Jiang, “Contextual resource negotiation-based task
the number of dependencies could be large and difficult to allocation and load balancing in complex software systems,” no. 5, pp.
manage. Through the results of the exploratory study, we 641–653.
proposed the use of the Critical Path Method (CPM) concepts [10] J. Sutherland and K. Schwaber, “The scrum guide. the definitive guide
to scrum: The rules of the game.”
to identify critical tasks in agile projects. Critical Path Method [11] W. Aslam and F. Ijaz, “A quantitative framework for task allocation in
has already consolidated in traditional project management distributed agile software development,” vol. 6, pp. 15 380–15 390.
models. In Agile Environments, this technique can help the [12] H. Alaidaros, M. Omar, and R. Romli, “Identification of criteria affecting
software project monitoring task of agile kanban method,” in AIP
team identify critical tasks, and thus direct their efforts toward Conference Proceedings, vol. 2016. AIP Publishing, p. 020021.
tasks that can impact the development of other tasks. [13] Y. Lee, K. A. Kozar, and K. R. Larsen, “The technology acceptance
The proposal presented in this article was materialized in the model: Past, present, and future,” vol. 12, no. 1, p. 50.
[14] VersionOne. 12th annual state of agile report. [Online].
AgileCritPath tool, which allows development teams to have a Available: https://explore.versionone.com/state-of-agile/versionone-
view of dependencies between the tasks and, therefore, identify 12th-annual-state-of-agile-report
at any time which tasks are critical. The tool is compatible [15] M. L. Despa, “Comparative study on software development methodolo-
gies,” vol. 5, no. 3, pp. 37–56.
with any agile methodology and can support development [16] Hazır, “A review of analytical models, approaches and decision support
teams to make decisions easily and quickly. The tool was tools in project monitoring and control,” vol. 33, no. 4, pp. 808–815.
developed in open source format and is available on GitHub [17] P. Runeson and M. Höst, “Guidelines for conducting and
reporting case study research in software engineering,” vol. 14,
(https://github.com/RachelVital/CritPath). no. 2, pp. 131–164. [Online]. Available: http://link-springer-
The evaluation of the use of the tool was based on the TAM com.ez29.capes.proxy.ufrj.br/article/10.1007/s10664-008-9102-8
[18] D. Badampudi, S. A. Fricker, and A. M. Moreno, “Perspectives on
technological acceptance model. During the evaluation, we productivity and delays in large-scale agile projects,” in International
were also able to gather insights and encourage the adoption Conference on Agile Software Development. Springer, pp. 180–194.
of the tool in the industry. Through the responses obtained in [19] F. D. Davis, “A technology acceptance model for empirically
testing new end-user information systems : theory and results,”
the TAM application, we were able to evaluate that, despite the http://hdl.handle.net/1721.1/15192, 7 1986, thesis (Ph. D.)–
additional effort to identify the dependencies, the use of the Massachusetts Institute of Technology, Sloan School of Management,
CPM in agile environments proved to be relatively simple and 1986.; MICROFICHE COPY AVAILABLE IN ARCHIVES AND
DEWEY.; Bibliography: leaves 233-250.
viable in the selected organization. At the end of the evaluation [20] G. H. Travassos and M. O. Barros, “Contributions of in virtuo and
of the use of technology, we could verify that the whole team in silico experiments for the future of empirical studies in software
was able to perceive the utility of the identification of critical engineering,” in 2nd Workshop on Empirical Software Engineering the
Future of Empirical Studies in Software Engineering, pp. 117–130.
tasks. [21] F. Shull, J. Carver, and G. H. Travassos, “An empirical methodology for
As future work, we plan to evaluate the use of AgileCritPath introducing software processes,” in ACM SIGSOFT Software Engineer-
in continuous software development and DevOps environ- ing Notes, vol. 26. ACM, pp. 288–296.
[22] P. Deemer, G. Benefield, C. Larman, and B. Vodde. The scrum primer
ments. The application of the acceptance model could also version 2.0.
be conducted in other software development companies. [23] E. Insfran and A. Fernandez, “A systematic review of usability evaluation
in web development,” in International Conference on Web Information
ACKNOWLEDGMENT Systems Engineering. Springer, pp. 81–91.
[24] S. Petter, W. DeLone, and E. R. McLean, “The past, present, and future
The authors thank the Natural Sciences and Engineering of” IS success”,” vol. 13, no. 5, p. 341.
[25] J. B. Barlow, J. S. Giboney, M. J. Keith, D. W. Wilson, and R. M.
Research Council of Canada (NSERC), the Emerging Leaders Schuetzler. Overview and guidance on agile development in large
in the Americas Program (ELAP) and MITACS. organizations.
[26] L. Cao, K. Mohan, P. Xu, and B. Ramesh, “How extreme does extreme
R EFERENCES programming have to be? adapting XP practices to large-scale projects,”
in System Sciences, 2004. Proceedings of the 37th Annual Hawaii
[1] J. Lynch. Standish group 2015 chaos report - q&a with jennifer lynch. International Conference on. IEEE, pp. 10–pp.
[Online]. Available: https://www.infoq.com/articles/standish-chaos-2015 [27] N. Ramasubbu, A. Bharadwaj, and G. K. Tayi, “Software process
[2] M. Cohn, Agile Estimating and Planning. Pearson Education, google- diversity: conceptualization, measurement, and analysis of impact on
Books-ID: BuFWHffRJssC. project performance.”