No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Is Task Board Customization Beneficial? - An Eye Tracking Study
Abstract
The task board is an essential artifact in many agile development approaches. It provides a good overview of the project status. Teams often customize their task boards according to the team members' needs. They modify the structure of boards, define colored codings for different purposes, and introduce different card sizes. Although the customizations are intended to improve the task board's usability and effectiveness, they may also complicate its comprehension and use. The increased effort impedes the work of both the team and team externals. Hence, task board customization is in conflict with the agile practice of fast and easy overview for everyone. In an eye tracking study with 30 participants, we compared an original task board design with three customized ones to investigate which design shortened the required time to identify a particular story card. Our findings yield that only the customized task board design with modified structures reduces the required time. The original task board design is more beneficial than individual colored codings and changed card sizes. According to our findings, agile teams should rethink their current task board design. They may be better served by focusing on the original task board design and by applying only carefully selected adjustments. In case of customization, a task board's structure should be adjusted since this is the only beneficial kind of customization, that additionally complies more precisely with the concept of fast and easy project overview.
... Santos et al. [42] evaluated the effect of layout guidelines for i* goal models on novice stakeholders' ability to understand and review such models. Karras et al. [27] compared the original task board design with three customized ones. They investigated the impact of the different design alternatives on developers' work with and comprehension of a task board. ...
[Context:] The descriptions of interactions and system functions are two of the most important artifact types in requirements specifications. Their common notations are use cases and requirements which are related to each other. There are different variants to link a use case with its associated requirements due to a wide variety of use case templates. The main purpose of all linking variants is to highlight the interrelationships between use cases and requirements. Besides considering both artifacts for themselves, a reader needs to interrelate them to achieve a high understanding of the overall content. [Objective / Method:] Due to the effort to create and maintain links, we investigated the impact of different linking variants on the reading behavior in an eye tracking study with $15$ subjects. [Results:] Our findings indicate that all investigated variants cause comparable visual effort and share the most frequent sequential reading pattern. In all cases, the use case was read first and then the requirements. Nevertheless, the different variants result in divergent reading behaviors. Especially, links embedded in the table of a use case description significantly increase the number of attention switches from the use case to the requirements. [Conclusion:] These attention switches represent the reading behavior of interrelating the use case and the associated requirements which only occurred in case of the most detailed linking variant.
The paper
describes the complexity of the short-term planning process in lifecycle management of specialized software. The critical stages of sprint scope planning in projects, which works by Agile models were explored. Network planning methods have been adapted to determine the critical indicators in lifecycle management of specialized software. An algorithm for automated construction of a network model and its representation in PC memory is proposed, as a data structure. Based on it, algorithms for constructing and traversing graphs of the network model, determining early and late execution time, and determining the critical execution path and time reserves are proposed. Developed algorithms for constructing and traversing graphs of the network model to automate the calculation of its parameters will be embedded in the work of the expert decision support system in lifecycle management of specialized software. The developed expert system will allow making operative decisions on re-planning of duration and the maintenance of project works in real-time. The system was developed using the Java programming language. The results of the system are presented in the development environment IntelliJ IDEA.KeywordsSoftware lifecycle managementAgileSprint planningNetwork graphs
A wide variety of use case templates supports different variants to link a use case with its associated requirements. Regardless of the linking, a reader must process the related information simultaneously to understand them.Linking variants are intended to cause a specific reading behavior in which a reader interrelates a use case and its associated requirements. Due to the effort to create and maintain links, we investigated the impact of different linking variants on the reading behavior in terms of visual effort and the intended way of interrelating both artifacts.We designed an eye tracking study about reading a use case and requirements. We conducted the study twice each with 15 subjects as a baseline experiment and as a repetition. The results of the baseline experiment, its repetition, and their joint analysis are consistent. All investigated linking variants cause comparable visual effort. In all cases, reading the single artifacts one after the other is the most frequently occurring behavior. Only links embedded in the fields of a use case description significantly increase the readers’ efforts to interrelate both artifacts. None of the investigated linking variants impedes reading a use case and requirements. However, only the most detailed linking variant causes readers to process related information simultaneously.
A wide variety of use case templates supports different variants to link a use case with its associated requirements. Regardless of the linking, a reader must process the related information simultaneously to understand them. Linking variants are intended to cause a specific reading behavior in which a reader interrelates a use case and its associated requirements. Due to the effort to create and maintain links, we investigated the impact of different linking variants on the reading behavior in terms of visual effort and the intended way of interrelating both artifacts. We designed an eye tracking study about reading a use case and requirements. We conducted the study twice each with 15 subjects as a baseline experiment and as a repetition. The results of the baseline experiment, its repetition, and their joint analysis are consistent. All investigated linking variants cause comparable visual effort. In all cases, reading the single artifacts one after the other is the most frequently occurring behavior. Only links embedded in the fields of a use case description significantly increase the readers' efforts to interrelate both artifacts. None of the investigated linking variants impedes reading a use case and requirements. However, only the most detailed linking variant causes readers to process related information simultaneously.
Requirements traceability (RT) links help developers to understand programs and ensure that their source code is consistent with its documentation. Creating RT links is a laborious and resource-consuming task. Information Retrieval (IR) techniques are useful to automatically recover traceability links. However, IR-based approaches typically have low accuracy (precision and recall) and, thus, creating RT links remains a human intensive process. We conjecture that understanding how developers verify RT links could help improve the accuracy of IR-based approaches to recover RT links. Consequently, we perform an empirical study consisting of two controlled experiments. First, we use an eye-tracking system to capture developers' eye movements while they verify RT links. We analyse the obtained data to identify and rank developers' preferred source code entities (SCEs), e.g., class names, method names. Second, we use the ranked SCEs to propose two new weighting schemes called SE/IDF (source code entity/inverse document frequency) and DOI/IDF (domain or implementation/inverse document frequency) to recover RT links combined with an IR technique. SE/IDF is based on the developers preferred SCEs to verify RT links. DOI/IDF is an extension of SE/IDF distinguishing domain and implementation concepts. We use LSI combined with SE/IDF, DOI/IDF, and TF/IDF to show, using two systems, iTrust and Pooka, that LSIDOI/IDF statistically improves the accuracy of the recovered RT links over LSITF/IDF.
User stories are a well-established way to record requirements in agile projects. They can be used as such to guide the daily work of developers or be split further into tasks, which usually represent more technical requirements. User stories and tasks guide communication and collaboration in software projects. However, there are several challenges with writing and using user stories in practice that are not well documented yet. Learning about these challenges could raise awareness for potential problems. Understanding how requirements artifacts are used for daily work could lead to better guidelines on writing stories that support daily work tasks. Moreover, user stories may not be appropriate to capture all kinds of requirements that are relevant for a project.
We explore how to utilize requirements artifacts effectively, what their benefits and challenges are, and how their scope granularity affects their utility. For this, we studied a software project carried out in the Software Factory at the Department of Computer Science, University of Helsinki. We investigated the requirements artifacts and then interviewed the developers and the customer about their experiences. Story and task cards have helped the participants throughout the project. However, despite having a Kanban board and rich communication within the team, some requirements were still too implicit, which also led to misunderstandings. This and other challenges revealed by the study can guide future in-depth research.
Software-based tooling has become an essential part of globally disitributed software development. In this study we focus on the usage of such tools and task boards in particular. We investigate the deployment of these tools through a field research in 4 different companies that feature agile and globally distributed development teams. We interviewed a total of 15 developers and concluded that the paper-based task board currently still has many advantages when compared to its software-based solution. Our findings indicate that the majority of the investigated companies that use the agile method Scrum also work with a software tool to support Scrum. While distributed teams use a software only approach, a large portion of collocated teams we studied utilize a combination of a paper based task board and the archiving and integration properties of the software solution. We reflect on these findings through the lens of media synchronicity theory and conclude that this theory is useful for explaining the current use and future development of software tools to support agile globally distributed development teams.
Today, little is known about what tools software companies are using to support their Agile methods and whether they are satisfied or dissatisfied with them. This is due to lack of objective surveys on the subject. The surveys that have been conducted so far are of a subjective nature and have mostly been performed by tool vendors. They are very limited in number and focus mainly on company structure and adherence to a specific Agile method rather than on tool usage and needs. For this reason, many companies have difficulties to choose appropriate tools to support their Agile process. One such company is the Swedish telecommunications giant Ericsson. To account for this lack of data, Ericsson commissioned us to conduct an independent survey focusing on the tool usage and needs as experienced by the Agile software community today. In this paper, we report on the results of our survey. The survey covers 121 responses from 120 different companies coming from 35 different countries. Our results show that the most satisfactory tool aspect is ease of use, whereas the least satisfactory one is lack of integration with other systems. Finally, our results provide a list of features that are most desired by the software companies today.
Agile software development practices such as eXtreme Programming (XP) and SCRUM have increasingly been adopted to respond
to the challenges of volatile business environments, where the markets and technologies evolve rapidly and present the unexpected.
In spite of the encouraging results so far, little is known about how agile practices affect communication. This article presents
the results from a study which examined the impact of XP and SCRUM practices on communication within software development
teams and within the focal organization. The research was carried out as a case study in F-Secure where two agile software
development projects were compared from the communication perspective. The goal of the study is to increase the understanding
of communication in the context of agile software development: internally among the developers and project leaders and in
the interface between the development team and stakeholders (i.e. customers, testers, other development teams). The study
shows that agile practices improve both informal and formal communication. However, it further indicates that, in larger development
situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder
the communication. The study highlights the fact that hurdles and improvements in the communication process can both affect
the feature requirements and task subtask dependencies as described in coordination theory. While the use of SCRUM and some
XP practices facilitate team and organizational communication of the dependencies between product features and working tasks,
the use of agile practices requires that the team and organization use also additional plan-driven practices to ensure the
efficiency of external communication between all the actors of software development.
Scrum seems to work extremely well as an agile project management approach. An obvious question is why. To answer that question, we carried out a longitudinal case study of a distributed project using Scrum across Denmark and India. In our analysis of case study data we used three selected theoretical frameworks. We conclude that Scrum works so well because it provides communication, social integration, control, and coordination mechanisms that are especially useful for distributed and agile project management.
Abstract—A properly implemented Scrum framework enforces a few simple constraints that cause a team to self- organize into a state that achieves 5 to 10 times waterfall performance. Yet the majority of Scrum teams never achieve this design goal. Teams do not know how to sequence work to deliver working software at the end of a sprint. They do not know how to work with a Product Owner to get the backlog in a ready state before bringing it into a sprint and do not know how to self-organize into a hyper-productive state during a sprint. A pattern is emerging at MySpace in California and Jayway in Sweden, for bootstrapping high performing Scrum teams. Rigorous implementation of Scrum by an experienced coach creates a total immersion experience akin to Shock Therapy. Teams are trained on exactly how to implement Scrum with no deviations for several sprints. These teams consistently achieve better than 240% improvement in velocity within a few weeks. They are then able to self-organize on their own to continue to improve performance. For many developers and managers,
One possible reason for the continued neglect of statistical power analysis in research in the behavioral sciences is the inaccessibility of or difficulty with the standard material. A convenient, although not comprehensive, presentation of required sample sizes is provided. Effect-size indexes and conventional values for these are given for operationally defined small, medium, and large effects. The sample sizes necessary for .80 power to detect effects at these levels are tabled for 8 standard statistical tests: (1) the difference between independent means, (2) the significance of a product-moment correlation, (3) the difference between independent rs, (4) the sign test, (5) the difference between independent proportions, (6) chi-square tests for goodness of fit and contingency tables, (7) 1-way analysis of variance (ANOVA), and (8) the significance of a multiple or multiple partial correlation.
Much of the knowledge used within an XP team is tacit, i.e. it is hidden and intangible. Two tangible artefacts that carry information about the team's work are the index cards which capture stories and tasks to be implemented and the wall where they are displayed (which we refer to as the 'Wall'). It is widely acknowledged that these are key elements supporting the work of the XP team, but no systematic investigation of their role has been reported to date. In this paper, we focus on the use of these artefacts within one XP team. We use distributed cognition, a framework for analysing collaborative work, to explicate the information flows in, around and within the team that are supported by the index cards and the Wall. We then interrogate the models produced using this analysis to answer 'what if' questions.
[Context and motivation] Writing good specifications is difficult and takes time. There are several guidelines such as the Volere template to assist writing a good specification. They provide a table of contents which can be used like a checklist to consider all relevant aspects. Voluminous specifications take more time to write, and also more time to read. A larger specification is not always a better one. [Question/Problem] A requirements engineer should be aware of how readers make use of a specification and consider their interests in writing it. In addition, some people prefer reading on a screen while others hold a preference for paper printouts. Some parts or aspects may be read differently in both representations. [Principal ideas/results]: We have conducted an Eye Tracking study investigating how specifications are read. We compared paper-based with on-screen presentation, and different reading perspectives such as UI designers, tester, software architects etc. We derived study goals by using GQM down to the level of quantitative and statistical eye tracking analyses. [Contribution]: There is a two-fold contribution: (a) Observations and findings about the way specifications are read; e.g., we had expected paper-based reading to be faster. Instead, we found similar reading patterns on paper versus on screen. (b) Insights with respect to eye tracking as a research method for requirements engineering. We discuss strengths and shortcomings, and provide lessons learned.
Much of the knowledge used within an XP team is tacit, i.e. it is hidden and intangible. Two tangible artefacts that carry information about the team's work are the index cards which capture stories and tasks to be implemented and the wall where they are displayed (which we refer to as the 'Wall). It is widely acknowledged that these are key elements supporting the work of the XP team, but no systematic investigation of their role has been reported to date. In this paper, we focus on the use of these artefacts within one XP team. We use distributed. cognition, a framework for analysing collaborative work, to explicate the information flows in, around and within the team that are supported by the index cards and the Wall. We then interrogate the models produced using this analysis to answer 'what if' questions.
The experiment data from the operation is input to the analysis and interpretation. After collecting experimental data in the operation phase, we want to be able to draw conclusions based on this data. To be able to draw valid conclusions, we must interpret the experiment data.
Software requirements specifications play a crucial role in software development projects. Especially in large projects, these specifications serve as a source of communication and information for a variety of roles involved in downstream activities like architecture, design, and testing. This vision paper argues that in order to create high-quality requirements specifications that fit the specific demands of successive document stakeholders, our research community needs to better understand the particular information needs of downstream development roles. In this paper, the authors introduce the idea of view-based requirements specifications. Two scenarios illustrate (1) current problems and challenges related to the research underlying the envisioned idea and (2) how these problems could be solved in the future. Based on these scenarios, challenges and research questions are outlined and supplemented with current results of exemplary user studies. Furthermore, potential future research is suggested, which the community should perform to answer the research questions as part of a research agenda.
This paper describes the creation and evolution of various styles of task boards. It contains examples of how to create a board for both a greenfield project and an established legacy project. Additionally, it describes the forces which caused these boards to evolve over time.
Software requirements specifications (SRS) serve as an important source of information for software architects with regard to deriving suitable architectural design decisions. However, from a software architect's viewpoint, using these documents efficiently and effectively is often difficult. One could attribute these observations to the fact that SRS also have to address and satisfy the information needs of other document consumers involved in downstream activities like interaction design, user interface design or testing - which is, indeed, very challenging for requirements engineers. In this position paper, we present goals and initial results of explorative studies aimed at investigating information needs that should be fulfilled in SRS from the viewpoint of software architects. In these studies, we gained first insights into the relevance of certain artifact types (like descriptions of interactions or system functionalities) and their suitable representation in terms of notations. Furthermore, the analysis of these initial results revealed variances within the group of software architects regarding information needs. This has motivated the planning and conduction of further studies in the near future that will investigate factors such as expertise or individual motivation, which might influence the information needs from software architects' viewpoints.
This paper considers the use of public displays, such as whiteboards and papers pinned to walls, by different software development teams, based on evidence from a number of empirical studies. This paper outlines differences in use observed between traditional and agile teams and begins to identify the implications that they may have for software development.
Agile software development promotes feedback, discipline and close collaboration between all members of the development team,
and de-emphasises documentation, ‘big design up front’ and hierarchical processes. Agile teams tend to be co-located and multi-disciplinary,
and rely heavily on face-to-face communication and seemingly simple physical artefacts to support interaction. In this paper
we focus on the functionality of two key physical artefacts – the story card and the Wall – which, individually and in combination,
underpin the team’s activity. These artefacts have two main roles – one which enables a shared understanding of requirements
and one which facilitates the development process itself. We consider these roles from two perspectives: a notational perspective
and a social perspective. This discussion shows how the two perspectives – the notational and the social – intertwine and
are mutually supportive. Any attempt to replace these physical artefacts with alternative support for an agile team needs
to take account of both perspectives, and the complex relationships between them.
Mature eXtreme programming (XP) teams are highly collaborative and self-organising. In previous studies, we have observed that these teams rely on two apparently simple mechanisms of co-ordination and collaboration: story cards and the Wall. Story cards capture and embody the user stories which form the basis of implementation, while the Wall is a physical space used to organise and display the cards being implemented during the current development cycle (called an iteration). In this paper, we analyse the structure and use of story cards and the Wall in three mature XP teams, using a distributed cognition approach. The teams work in different commercial organisations developing different systems, yet we find significant similarities between their use of these two artefacts. Although simple, teams use the cards and the Wall in sophisticated ways to represent and communicate information that is vital to support their activities. We discuss the significance of the physical medium for the story cards and the Wall in an XP team and discuss the considerations that need to be taken into account for the design of technology to support the teams.
A flexible cooperative task board for supporting daily scrum meetings is described as an application of different hypermedia domains. In addition, change structure is introduced as a means to explicitly model changes in task management. It helps the scrum development team in a sprint retrospective to improve their planning.
Like other sciences and engineering disciplines, software engineering requires a cycle of model building, experimentation, and learning. Experiments are valuable tools for all software engineers who are involved in evaluating and choosing between different methods, techniques, languages and tools. The purpose of Experimentation in Software Engineering is to introduce students, teachers, researchers, and practitioners to empirical studies in software engineering, using controlled experiments. The introduction to experimentation is provided through a process perspective, and the focus is on the steps that we have to go through to perform an experiment. The book is divided into three parts. The first part provides a background of theories and methods used in experimentation. Part II then devotes one chapter to each of the five experiment steps: scoping, planning, execution, analysis, and result presentation. Part III completes the presentation with two examples. Assignments and statistical material are provided in appendixes. Overall the book provides indispensable information regarding empirical studies in particular for experiments, but also for case studies, systematic literature reviews, and surveys. It is a revision of the authors' book, which was published in 2000. In addition, substantial new material, e.g. concerning systematic literature reviews and case study research, is introduced. The book is self-contained and it is suitable as a course book in undergraduate or graduate studies where the need for empirical studies in software engineering is stressed. Exercises and assignments are included to combine the more theoretical material with practical aspects. Researchers will also benefit from the book, learning more about how to conduct empirical studies, and likewise practitioners may use it as a "cookbook" when evaluating new methods or techniques before implementing them in their organization. © Springer-Verlag Berlin Heidelberg 2012. All rights are reserved.
The task board is one of the most important information radiators used by an agile team to track their progress. When teams make the transition to using electronic team tracking tools, they often stop using the physical information radiators such as the task board. This transition from using a physical tool to an electronic tool can have unintended side effects for teams. In this experience report, the focus is on sharing the problems teams can encounter with transparency if they do not manage the transition to electronic tools well. We discuss the implications for agile development teams along with the strengths and weaknesses of physical and electronic information radiators.
Agile processes rely on feedback and communication to work and they often work best with co-located teams for this reason. Sometimes agile makes sense because of project requirements and a distributed team makes sense because of resource constraints. A distributed team can be productive and fun to work on if the team takes an active role in overcoming the barriers that distribution causes. This is the story of how one product team used creativity, communications tools, and basic good engineering practices to build a successful product.
Breaking down walls, building bridges, and Takin’ out the trash
- L Babik
- R Sheridan
Babik, L., Sheridan, R.: Breaking Down Walls, Building Bridges, and Takin' Out
the Trash, https://www.infoq.com/articles/agile-team-spaces
The Mystery of the Writing that isn't on the Wall
- M Petre
- H Sharp
- S Freudenberg
Petre, M., Sharp, H., Freudenberg, S.: The Mystery of the Writing that isn't on
the Wall: Differences in Public Representations in Traditional and Agile Software
Development. In: 5th International Workshop on Cooperative and Human Aspects
of Software Engineering. IEEE, Piscataway, NJ (2012)
A gallery of team rooms and charts
- B Wake
Wake, B.: A Gallery of Team Rooms and Charts, http://xp123.com/articles/
a-gallery-of-team-rooms-and-charts/
- J Sutherland
- S Downey
- B Granvik
Sutherland, J., Downey, S., Granvik, B.: Shock Therapy: A Bootstrap for Hyper-Productive Scrum. In: Agile Conference. IEEE, Piscataway, NJ (2009)