Conference PaperPDF Available

Are Daily Stand-up Meetings Valuable? A Survey of Developers in Software Teams


Abstract and Figures

The daily stand-up meeting is a widely used practice. However, what is more uncertain is how valuable the practice is to team members. We invited professional developers of a programming forum to a survey and obtained 221 responses. Results show that the daily stand-up meeting was used by 87% of those who employ agile methods. We found that even though the respondents on average were neutral towards the practice, the majority were either positive or negative. Junior developers were most positive and senior developers and members of large teams most negative. We argue that the value of the practice should be evaluated according to the team needs. Further, more work is needed to understand why senior developers do not perceive the meetings as valuable and how to apply the practice successfully in large teams.
Content may be subject to copyright.
Are Daily Stand-up Meetings Valuable?
A Survey of Developers in Software Teams
Viktoria Stray
, Nils Brede Moe
, and Gunnar R. Bergersen
University of Oslo, Gaustadalléen 23B, 0374 Oslo, Norway
SINTEF, Strindveien 4, 7465 Trondheim, Norway
Abstract. The daily stand-up meeting is a widely used practice. However, what
is more uncertain is how valuable the practice is to team members. We invited
professional developers of a programming forum to a survey and obtained 221
responses. Results show that the daily stand-up meeting was used by 87% of
those who employ agile methods. We found that even though the respondents on
average were neutral towards the practice, the majority were either positive or
negative. Junior developers were most positive and senior developers and
members of large teams most negative. We argue that the value of the practice
should be evaluated according to the team needs. Further, more work is needed
to understand why senior developers do not perceive the meetings as valuable
and how to apply the practice successfully in large teams.
Keywords: Daily meetings Stand up meeting Daily scrum
Communication Coordination Teamwork Team size Agile adoption
Agile practices
1 Introduction
Agile methods introduced the daily stand-up meeting (DSM) as a practice to improve
communication in software development projects. In Scrum, the meeting is mandatory,
time-boxed to 15 min and team members address: (1) what they have done the previous
work day, (2) what they will do today and (3) what obstacles are preventing them from
making progress [1]. Scrum recommends that the DSM should not be used for dis-
cussing solutions to obstacles raised. However, empirical studies have found that
spending time in the short meeting on discussing and solving problems is valuable [2,3].
DSMs are task oriented, generally unrecorded, and members gather to focus on a
narrow organizational goal. According to Boden [4], such meetings can be charac-
terized as informal. The practice gives team members an overview of what other team
members are doing and is therefore an important mechanism to increase information
sharing and team awareness [5]. The meeting is often conducted standing up to keep it
brief and avoid lengthy discussions, hence the term stand-up meeting. The practice is
also called frequent short meetings[6], morning roll call[7], and daily Scrum
meeting[1]. The DSM is an important practice for agile teams because it helps the
team in monitoring and managing its performance, which is important for the team to
©The Author(s) 2017
H. Baumeister et al. (Eds.): XP 2017, LNBIP 283, pp. 274281, 2017.
DOI: 10.1007/978-3-319-57633-6_20
self-manage [8]. Further, such meetings improve access to information that foster
employee empowerment [9].
While DSM is a relatively straightforward practice to adopt, it is challenging to
implement it successfully. Challenges include nding a suitable time of day, keeping
the time limit and whether it should be held daily and standing up [10]. We have
previously found DSMs to last 63% longer when team members sit rather than stand
during the meeting [5]. Another challenge is members reporting their status to the team
leader, resulting in team members not paying attention to each other [8].
Although the DSM is one of the most popular agile practices [11,12] and the only
daily team-based coordination mechanism, the practice has received little research
attention. Further, because meeting satisfaction is part of overall job satisfaction [13], it
is important to understand what makes this meeting valuable for team members. In a
recent, qualitative study of thirteen teams (in Norway, Poland, UK and Malaysia) we
found that the attitudes towards DSMs were slightly more positive than negative [5].
However, the level of satisfaction varied within the teams. Therefore, to understand
how to implement DSM, it is important to explore satisfaction with the practice on an
individual level. This leads to the following research question: What are the char-
acteristics of developers perceiving the daily stand-up meeting to be valuable com-
pared to those who do not?
Our work also answers a call for more empirical studies on the adoption rate of
agile software development methods [14].
2 Method
The target population for this study was professional software developers. Accordingly,
we posted the survey on Reddit, which is a social media website that allows scientists
to recruit a targeted population [15]. We chose two programming-related subreddits
(subforums) that provide news and discussions about computer programming
(r/programming, 710 000 subscribers) and web development (r/webdev, 130 000
subscribers). The survey was administered using the Qualtrics software which prevents
the survey to be completed more than once by the same respondent. Participation was
voluntary. Further, no compensation was offered, which increase the quality of the data
because the incentive to cheat is largely reduced [15]. The survey (available from took about three minutes to complete.
We received 316 responses, of which 243 contained data that could be analyzed.
Because we were interested in the opinions of software professionals currently working
in teams, we removed students and those not working or not working in a team. In total,
221 responses were used for the reported results. The majority of responses were from
the programming forum (n = 165). Nearly all the respondents were male (96.8%) with
a mean age of 31 years (n = 204, sd = 6.86). Among the respondents who answered
whether their team was distributed (n = 168), about two-thirds of the respondents
(63.1%) reported working in co-located teams, whereas the remaining had team
members distributed across sites (36.9%).
Are Daily Stand-up Meetings Valuable? 275
All Likert questions used a ve-point scale. All nominal-scale questions were
presented with a randomized order of categories because the order of response alter-
natives can inuence results [16]. Some questions were not compulsory, which resulted
in missing data for the reported variables. Analyses are reported using the R statistical
software [17]. To err on the side of caution, we use two-tailed analysis and chose
non-parametric statistical tests. The one-sample Wilcoxon test is used to check for
statistically signicant differences in distributions. When comparing frequencies
between two dichotomous variables that contain count data (i.e., frequencies) we used
Fishers exact test which reports the odds ratio (OR) effect size.
3 Results
In our study, the average number of DSMs conducted per week was ve, which
suggests that it is a daily meeting. Table 1shows descriptive statistics. We found no
difference regarding the frequency of meetings when it comes to being part of a
distributed team or not, or to team size. Among all the respondents, one-third reported
to work in teams with two to ve members, one-third in teams with six to eight
members and one-third in teams with nine or more members. We found a difference of
52% points with an odds ratio of 12.3 for agile teams using DSMs over non-agile teams
(p < 0.001, 95% condence interval for OR: 5.429.5).
Overall, 70.6% report that they attend DSMs (n = 221). Those who attend and
those who do not attend DSMs spend the same amount of hours in meetings (DSMs
included) and report similar values for programming skills. However, those who attend
DSMs spend almost one hour more each workday on programming (p = 0.046, attend:
M = 6.5 h, sd = 2.1; not attend: M = 5.6 h, sd = 2.7). Further, those who attend
DSMs work in larger teams (p = 0.03, attend: M = 6.90 members, sd = 4.7; M = 7.44
members, sd = 3.52); the median difference was 2 team members. Moreover, the
practice is regarded as more valuable by those who attend DSMs than those who do not
(p = 0.002, attend: M = 3.1, n = 123, not attend: M = 2.3, n = 29).
Table 1. Descriptive statistics
Unit n Mean (M) sd median
Time in meetings
Time programming
Team size
DSM valuable
Programming skill self
Programming skill peers
Frequency per day, DSMs included
Hours per day; DSMs included
Hours per day
Members including self
Likert: Negative (1)Positive (5)
Likert: Novice (1)Expert (5)
Likert: Novice (1)Expert (5)
276 V. Stray et al.
We now report on only those respondents who attend DSMs. While the mean
perceived value by these respondents towards the practice was neutral (3.1), only
18.7% chose this middle category on the Likert scale. Most respondents were either
positive (44.7%) or negative (36.6%). We coded responses of 4 and 5 as positive,
responses of 1 and 2 as negative, and removed those who responded neutral to be
able to better understand differences between these two groups. We found no relation
between working in a co-located or distributed team and the perceived value of DSM.
However, those positive were signicantly younger (p = 0.008, positive: M = 29.6
years, n = 49; negative: M = 33.5 years, n = 42).
Figure 1shows the characteristics of the respondents who attend DSMs according
to whether they are positive (green, n = 55) or negative (red, n = 45) towards the
meetings they attend. The left part of the gure shows that those positive and negative
towards their DSMs spent about the same amount of time in meetings: 83 min for those
positive versus 77 min for those negative. However, there was a signicant difference
in meeting frequency; those positive attended fewer meetings per day (DSMs included)
than those negative. Those positive towards DSM report somewhat more time spent on
programming per day (24 min) than those negative. Being positive towards DSMs was,
to some extent, associated with working in smaller teams. As a post hoc analysis, we
investigated differences in attitudes further and found that teams with 12 or more
members were most strongly associated with negative attitudes towards DSMs.
The right part of Fig. 1shows a minor difference between how those positive and
negative towards DSM rated their own programming skills. However, those positive
rated the programming skills of their peers as signicantly higher compared to how the
Fig. 1. Characteristics of those positive and negative towards their DSMs being valuable.
Signicant differences are shown at the top and means are shown at the bottom of the gure (as
numbers). Outliers are omitted. Error bars represent the standard errors of the mean. + is
p < 0.10 and * is p < 0.05 (two-sided). (Color gure online)
Are Daily Stand-up Meetings Valuable? 277
negative rated their peers. Further, those negative also rated their own skills as sig-
nicantly higher than that of their peers, whereas it was, to some extent, the opposite
for those positive.
4 Discussion
The main explanation of the widespread use of DSM (70,6%) is the high adoption rate
of agile development methods among our respondents. Table 2shows that the agile
adoption rate in our survey is higher than what was found by Rodríguez et al. [11].
Rodríguez et al. did not report the adoption rate of DSM but concluded that it was one
of the most widely used practices. The last column in Table 2shows the adoption rate
of DSM in both agile and non-agile teams in our study. VersionOne [12] report the
DSM to be the most employed agile practice with an adoption rate of 83%.
VersionOnes sample mostly consisted of agile practitioners. In comparison, our DSM
adoption rate among those using agile or agile in combination with Lean was 87.3%.
Our results indicate that the practice has spread to companies not using agile methods
because 35.4% of the respondents who work in non-agile teams also report using DSM.
Thus, being agile implies that DSMs are used to a large extent which supports that
DSM is a practice that distinguishes agile from non-agile teams [17].
For our research question, What are the characteristics of developers perceiving
the daily stand-up meeting to be valuable compared to those who do not?, our results
indicate that those positive towards DSM are more junior developers. This inference is
supported by age, how they rate their own programming skills and their self-reported
skills compared to the perceived skill of their peers. Those positive towards DSM also
participate in fewer meetings than those negative. The same variables also indicate that
those negative towards DSM are more senior developers. One explanation for why a
senior developer regards DSM as less valuable is because seniors may already know
what goes on in the team and does not get any new information in the meeting. The
personal gain from the meeting is thus reduced. Moreover, being able to have quick
problem-solving discussions in the DSM make developers perceive the DSM as more
valuable [5]. Senior developers often work on more complex tasks, and it might be that
high complexity problems are seldom discussed at the meeting because they require too
Table 2. Usage rates of agile methods and DSM adoption according to development method
Development method Agile adoption
in our survey
Agile adoption in
Rodríguez et al. [11]
DSM adoption
in our survey
Agile and/or Lean 73.6% 57.8% 87.3%
Only agile 54.9% 33.6% 89.0%
Agile and Lean 18.7% 21.6% 82.4%
Only Lean 0.0% 2.7% 0.0%
Neither agile nor Lean 26.4% 42.2% 35.4%
Total 100.0% 100.0%
278 V. Stray et al.
much time. It is more likely that the problems a junior developer encounter are more
easily solved in a DSM.
A second explanation is that senior developers attend more meetings than junior
developers. The DSM then becomes an additional daily interruption, which reduces the
satisfaction with such meetings. Perceiving the meeting to have too high frequency
negatively affects the attitude towards DSMs [5]. Moreover, meeting load affects
employees well-being [18] so companies should be sensitive to the number of meetings
the developers have to attend. While it has been claimed that DSMs eliminate the need
for other meetings [1], we found no difference between hours spent in meetings for
those who attend or do not attend DSMs.
In a self-managing team, the team goal should be more important than the indi-
vidual goal, and then a developer should rate the DSM value depending on the team
needs. One respondent commented: I think some people need the daily stand-up
format. So even though I personally dont feel like I need it, I feel it benets us all to do
it because of the different personalities.Because we do not know the perspective of
the respondent we do not know if the respondents are considering the value from an
individual or team perspective, or a mixture of the two views.
We found that larger teams are more likely to have DSMs. Paradoxically, the larger
the team, the less is the satisfaction with DSM. Large teams using DSMs should
therefore pay special attention to improving the quality of these meetings. In particular,
developers were negative towards DSM when teams consisted of 12 or more team
members. Previous research also found a negative correlation between the number of
meeting participants and the attitude towards DSM [5].
The main limitation of this study concerns the representativeness. Although the
distribution of self-reported programming skill in this study is nearly identical to our
earlier study of programming skill of developers [19], the sample and target population
may differ. For example, it is possible that only those who knew or had a strong
(polarized) opinion of DSMs responded to the survey. This may bias results in favor of
more respondents reporting using DSM and more variability in opinions than is
actually present in the target population. Another potential concern is that we had
subjects from two different programming forums, but the results we report still hold
when analyzing the data from the two forums separately.
5 Conclusion and Future Work
The present study investigated the perceived value of daily stand-up meetings (DSMs)
and reports the adoption rate of the practice. Among those who use agile methods, the
majority conducts DSMs. Although it is a common practice, the perceived value of the
meeting varies with junior developers being more positive and senior developers more
negative towards the DSMs they attend. A possible explanation is that junior devel-
opers receive more relevant information and assistance in solving problems during the
meeting. In contrast, senior developers often work with larger, more complex and
independent tasks that are more difcult to share with team members on a daily basis.
Agile teams are expected to be self-managed, and the need of the team should be more
important than that of the individual. The value of the practice should, therefore,
Are Daily Stand-up Meetings Valuable? 279
be evaluated according to the team needs. Consequently, senior developers should be
made more aware that DSMs are benecial for the junior developers as well as the team
as a whole. Another result was that developers in larger teams see the meeting as less
valuable than developers in smaller teams. Because the work in large teams is often
loosely coupled, the information shared during the meeting may be less relevant for the
individuals. Consequently, large teams in particular need to invest resources in
improving the practice to make it valuable.
Future work should investigate other criteria of the participants, such as role and
domain. Because the perceived value of meetings affects job satisfaction, there is a
need to understand why senior developers and large teams do not perceive the meeting
as more valuable. The DSM is a widely adopted practice and is an important mech-
anism for information sharing and team awareness, thus, how to apply the practice
successfully in large teams should also be studied.
Acknowledgments. We are grateful to the survey respondents and to the reviewers. This work
was supported by the Smiglo project, which is partly funded by the Research Council of Norway
under the grant 235359/O30.
1. Schwaber, K., Beedle, M.: Agile Software Development with Scrum. Prentice Hall, Upper
Saddle River (2002)
2. Stray, V.G., Moe, N.B., Aurum, A.: Investigating daily team meetings in agile software
projects. In: The 38th EUROMICRO Conference on Software Engineering and Advanced
Applications (SEAA 2012), Cesme, Turkey, 17 August 2012
3. Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P., Still, J.: The impact of agile
practices on communication in software development. Empirical Softw. Eng. 13, 303337
4. Boden, D.: The Business of Talk: Organizations in Action. Polity Press, Cambridge (1994)
5. Stray, V., Sjøberg, D., Dybå, T.: The daily stand-up meeting: a grounded theory study.
J. Syst. Softw. 114, 101124 (2016)
6. Rising, L.: Agile meetings. STQE, pp. 4246 (2002)
7. Anderson, D.J.: Agile Management for Software Engineering: Applying the Theory of
Constraints for Business Results. Prentice Hall, Upper Saddle River (2003)
8. Moe, N.B., Dingsøyr, T., Dybå, T.: A teamwork model for understanding an agile team: a
case study of a Scrum project. Inf. Softw. Technol. 52, 480491 (2010)
9. Allen, J.A., Lehmann-Willenbrock, N., Sands, S.J.: Meetings as a positive boost? How and
when meeting satisfaction impacts employee empowerment. J. Bus. Res. 69,18 (2016)
10. Stray, V.G., Lindsjørn, Y., Sjøberg, D.: Obstacles to efcient daily meetings in agile
development projects: a case study. In: The ACM/IEEE International Symposium on
Empirical Software Engineering and Measurement (ESEM 2013), Baltimore, USA, 13
September 2013
11. Rodríguez, P., Markkula, J., Oivo, M., Turula, K.: Survey on Agile and Lean Usage in
Finnish Software Industry. ACM, New York (2012)
12. VersionOne: VersionOne 10th Annual State of Agile Report.
280 V. Stray et al.
13. Rogelberg, S.G., Allen, J.A., Shanock, L., Scott, C., Shufer, M.: Employee satisfaction with
meetings: a contemporary facet of job satisfaction. Hum. Resour. Manag. 49, 149172
14. Stavru, S.: A critical examination of recent industrial surveys on agile method usage. J. Syst.
Softw. 94,8797 (2014)
15. Shatz, I.: Fast, free, and targeted: reddit as a source for recruiting participants online. Soc.
Sci. Comput. Rev., pp. 113 (2016)
16. Schwarz, N., Hippler, H.J.: Response alternatives: the impact of their choice and
presentation order (1991)
17. Murphy, B., Bird, C., Zimmermann, T., Williams, L.: Have agile techniques been the silver
bullet for software development at Microsoft? In: The Proceedings of the 2013 ACM/IEEE
International Symposium on Empirical Software Engineering and Measurement (ESEM
2013), Baltimore, USA, 7 July 2013
18. Luong, A., Rogelberg, S.G.: Meetings and more meetings: the relationship between meeting
load and the daily well-being of employees. Group Dyn. Theor. Res. Pract. 9,5867 (2005)
19. Bergersen, G.R., Sjøberg, D., Dybå, T.: Construction and validation of an instrument for
measuring programming skill. IEEE Trans. Softw. Eng. 40, 11631184 (2014)
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0
International License (, which permits use, sharing,
adaptation, distribution and reproduction in any medium or format, as long as you give appro-
priate credit to the original author(s) and the source, provide a link to the Creative Commons
license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapters Creative
Commons license, unless indicated otherwise in a credit line to the material. If material is not
included in the chapters Creative Commons license and your intended use is not permitted by
statutory regulation or exceeds the permitted use, you will need to obtain permission directly
from the copyright holder.
Are Daily Stand-up Meetings Valuable? 281
... Daily meetings were perceived of lesser value for the time spent in the meetings Stray, Moe, and Bergersen (2017) Junior developers perceived daily meetings more positively than senior developers Higher frequency of daily meetings was viewed negatively ...
... Few studies have explicitly focused on the characteristics of DSMs as a central concept, e.g. Stray, Lindsjørn, and Sjøberg (2013), Stray, Sjøberg, and Dybå (2016), Stray, Moe, and Bergersen (2017), and Stray, Moe, and Sjoberg (2020). Stray, Sjøberg, and Dybå (2016) have empirically investigated DSMs and theorised propositions for conducting effective DSMs, such as software team characteristics (self-management and knowledge sharing), and physical characteristics of DSMs (e.g. ...
... Stray, Moe, and Sjoberg (2020) outlined DSMs effectiveness in solving problems but decreasing productivity of developers by breaking their day into slots. Stray, Moe, and Bergersen (2017) found that senior developers perceived DSMs more negatively than junior developers. However, there remains a gap in understanding the mixed responses of junior versus senior developers towards DSMs, in terms of why junior developers perceive DSMs more positively than senior developers and in which perspectives. ...
Full-text available
Daily stand-up meetings (DSMs) are the most popular technique in agile methodologies and are deemed crucial for communication among the individual agile software developers to perform. Only a handful of studies in the past have shown the effect of the characteristics of DSMs on the attitude of agile developers. Little is known about how agile developers experience DSMs in their roles as junior/senior developers, and what feelings evoke these experiences. The purpose of this study was to describe and interpret agile developers’ lived experiences with DSMs in their diverse roles. We conducted a hermeneutic phenomenological study with 19 professional agile developers. The lived experiences across the interviews revealed as an interaction between four categories: rationalising irrelevancy of DSMs, experiencing challenges with DSMs, conflicted opinion on the advantages of DSMs, and finding solutions. Developers experienced DSMs were too short to facilitate clear problem identification, or solve problems, or have a meaningful outcome. Senior developers experienced DSMs differently than junior developers in terms of sharing information, interest in other’s work, monitoring progress, and facilitating decision making. Based on these findings, we discuss the theoretical contributions of our study, and offer recommendations for practitioners. Free e-print link (limited copies):
... To our surprise, however, this does not seem to apply to all investigated practices. Although daily meetings are one of the most widely adopted agile practices [47], they apparently do not influence any of the social agile principles. Some scholars suggest that daily meetings may imply an additional overhead to the schedule of developers [48], as they frequently exceed the defined time limits [48,49] and are often used to discuss other problems, potential solutions [50], or topics of lesser relevance [49]. ...
... Our results suggest that the implementation of daily meetings may not necessarily contribute to the agility of the team. As daily meetings frequently lack clear focus and present a temporal burden, practitioners question their usefulness [47,49,50]. Considering that BITA was one of the key drivers for the success of ASD in our study, establishing BITA in daily meetings through joint, reciprocal exchange of information between developers and business could thus provide more benefits than solely promoting communication in the development team as a strategy for daily meetings. ...
Conference Paper
Full-text available
Although agile software development (ASD) is widespread, the contributions of individual agile practices to development success are still largely unclear. In this paper, we explore the hidden cause-effect relationships between the application of social agile practices, the realization of social agile principles, and the resulting contribution(s) to ASD success. To capture ASD success, we consider both the effects on developer acceptance and economic business values. Based on an initial ASD success model and data from a survey of 197 developers, we found that social agile practices such as reflection, business IT alignment, and self-organization seem to particularly promote ASD success. We also found indications that the realization of these principles is primarily driven by practices such as retrospective meetings and shared leadership, whereas prominent practices like daily meetings and pair programming seem to have no effect. Our results thus call for reassessment of agile practices and their use in practice.
... Recurring meetings are part and parcel of software development, with the Agile stand-up (daily Scrum) meeting being the prototypical example. These meetings have been studied extensively (e.g., [5], [7], [8]). One study explicitly focused on recurrence [9], conducting interviews with workers from a large research organization. ...
Conference Paper
Meetings have always been a significant part of working life and software development is no exception, with meetings of all kinds taking place daily. One type of meeting that is critical to software development that has not been widely studied to date is the recurring software maintenance meeting: a regularly scheduled meeting during which the primary product leads consider emerging issues and new directions for an already deployed and functioning software system. In this paper, we describe preliminary results of our ongoing analysis of ten consecutive recurring maintenance meetings of the architecture committee of a major healthcare software company. The results provide a foundation for further analysis in terms of first building a categorization of the kinds of discussions that take place. We present the setting, our approach to analysis, and preliminary observations. A primary outcome is that the kinds of discussions are much more varied than one might have initially expected.
... We plan to extend our work for providing incremental effort estimates (after 1 month, 2 months, and so on) in the future. Since developer acts as the primary source of source-code contributor, we plan to study novel developer-related factors, such as the developer's characteristics [Li et al. 2012;Stray et al. 2017;Yang et al. 2020], the developer's geographical location [Rastogi et al. 2018], and social interactions of developers [Iden and Bygstad 2018;Zhang et al. 2017], and test their effect on software development. ...
Full-text available
Software development effort estimation (SDEE) generally involves leveraging the information about the effort spent in developing similar software in the past. Most organizations do not have access to sufficient and reliable forms of such data from past projects. As such, the existing SDEE methods suffer from low usage and accuracy. We propose an efficient SDEE method for open source software, which provides accurate and fast effort estimates. The significant contributions of our article are (i) novel SDEE software metrics derived from developer activity information of various software repositories, (ii) an SDEE dataset comprising the SDEE metrics’ values derived from approximately 13,000 GitHub repositories from 150 different software categories, and (iii) an effort estimation tool based on SDEE metrics and a software description similarity model . Our software description similarity model is basically a machine learning model trained using the PVA on the software product descriptions of GitHub repositories. Given the software description of a newly envisioned software, our tool yields an effort estimate for developing it. Our method achieves the highest standardized accuracy score of 87.26% (with Cliff’s δ = 0.88 at 99.999% confidence level) and 42.7% with the automatically transformed linear baseline model. Our software artifacts are available at
... We plan to extend our work for providing incremental effort estimates (after one month, two months, and so on) in the future. Since developer acts as the primary source of source-code contributor, we plan to study novel developer-related factors, such as developer's characteristics [Li et al. 2012;Stray et al. 2017; Yang et al. The performance of PVA depends on its input parameters, viz., , , and (see Table 1). ...
Full-text available
Software development effort estimation (SDEE) generally involves leveraging the information about the effort spent in developing similar software in the past. Most organizations do not have access to sufficient and reliable forms of such data from past projects. As such, the existing SDEE methods suffer from low usage and accuracy. We propose an efficient SDEE method for open source software, which provides accurate and fast effort estimates. The significant contributions of our paper are i) Novel SDEE software metrics derived from developer activity information of various software repositories, ii) SDEE dataset comprising the SDEE metrics' values derived from $\approx13,000$ GitHub repositories from 150 different software categories, iii) an effort estimation tool based on SDEE metrics and a software description similarity model. Our software description similarity model is basically a machine learning model trained using the Paragraph Vectors algorithm on the software product descriptions of GitHub repositories. Given the software description of a newly-envisioned software, our tool yields an effort estimate for developing it. Our method achieves the highest Standard Accuracy score of 87.26% (with cliff's $\delta$=0.88 at 99.999% confidence level) and 42.7% with the Automatic Transformed Linear Baseline model. Our software artifacts are available at
... However, a meeting that is expected to be effective with less presence is a stand-up meeting. A daily stand-up meeting is characterised by its speed and high energy, which support the goal of establishing focus in a meeting (Stray, Moe, & Bergersen, 2017). Long meetings with low energy tend to distract, which is not effective for daily stand-up meetings. ...
... For example, the Job forms under week 0 are shifted to the emergency column, the Job forms to week 1 are shifted under week 0, and so on. Monday morning is when stand-up meetings are held, which is a very useful practice for coordinating work in MTO systems (Lane 2007;Stray, Moe, and Bergersen 2017). ...
COntrol of BAlance by CArd-BAsed NAvigation (COBACABANA) is a card-based system for job shop control. This paper presents a real industrial application of COBACABANA aimed at solving production control problems in an Italian manufacturer of valves and flanges, configured as a job shop system. To the best of our knowledge, this is the first industrial implementation of COBACABANA. Although COBACABANA can be extended to estimating delivery time allowances, this research focuses only on its shop floor control mechanism. In the case study, the COBACABANA boards and cards are carefully reviewed. The criticalities and limitations of traditional COBACABANA are fully explored and, subsequently, two new boards and a new form are introduced to facilitate its practicality and ease of implementation. The new tools enable planners to better monitor the pre-shop pool status and the progress of orders.
... Regarding development models for software, a recent study (Stray et al., 2017) states that 70% of all development projects follow the Agile development model. Combining it with our results, it seems that Agile has become such a widespread practice that the need to specifically ask for it is no longer relevant. ...
Full-text available
Software testing is an integral part of software development that provides better-quality products and user experiences and helps build the reputation of software companies. Though software testers perform a role that requires specific tasks and skills, in-depth studies of software testers lag behind research studies of other roles within software development teams. In this paper, we aim to create a profile of testers by presenting an empirical analysis of the skills the industry currently needs. We analysed data from 400 job adverts in 33 countries. We mapped the skills on a taxonomy comprising test-related, technical, and domain-specific skills. In addition, we looked at the demand for educational attainment, relevant certifications, and previous experience requirements. Our findings show that employers are mostly interested in skills related to test planning and design, test automation, functional testing, performance testing, and progress reporting. One third of the job advertisers were interested in people with the skills to operate test execution tools. Selenium was the testing tool most in demand. The testers must have strong technical abilities, including programming skills in Java, C#, and SQL. Also, they must handle project management tasks such as estimation, risk management, and quality assurance. Employers do not emphasise domain-specific knowledge, which indicates that they consider testing skills portable across industries. One in seven job adverts asks for a software testing certification. Our study helps clarify the complexity of the testing job and outlines the capabilities one needs to fulfil a software tester’s responsibilities.
Full-text available
Meetings that involve both collocated and remote participants can be hindered by various technological and human difficulties. Taking an ethnomethodological and conversation analytic approach, this paper investigates how participants establish and maintain progressivity in hybrid meetings ensuring the continuous flow of work. Based on video-recorded data from hybrid daily Scrum meetings at a software development company, we focused on instances where participants are interrupted by problems diminishing the meeting progressivity. Our micro analysis shows that in the meetings resolution of work-progress related trouble is prioritized over the resolution of technical problems. To establish and maintain progressivity, participants orient to the organizational imperatives while simultaneously circumventing technical problems arising in the meetings. In overcoming problems, the different layers of organizational goals and meeting goals are accounted for in the common effort to get work done by (a) reminding of the time budget; (b) sticking to the agenda (c) reconfiguring responsibilities to fill in for missing members; and (d) referencing shared resources that reflect team progress. This analysis suggests that to improve hybrid and/or online meetings, practitioners should aim to increase the social intelligibility of activities scheduled for meetings by defining improved and specific meeting frameworks that promote continuity and reduce ambiguity.
Context: A stable team is deemed optimal for agile software development project success; however, all teams change membership over time. Newcomers joining an agile project team must rapidly assimilate into the organisational and project environment. They must do this while learning how to contribute effectively and without seriously interrupting project progress. Objective: This paper addresses how newcomers integrate into an established agile project team and how agile practices assist with onboarding. Method: A single, qualitative case study approach was used, investigating a co-located agile project team in a large IT department who regularly onboard inexperienced newcomers. Analysis was abductive, consisting of inductive coding and theming using categories from an existing onboarding theory. Results: We describe the team's onboarding practices and adjustments and present an agile onboarding model that encompasses onboarding activities, individual adjustments, and workplace adjustments. Conclusions: A mixture of general and specific agile onboarding practices contribute to successful onboarding in an agile team. We provide practical guidelines to improve onboarding practice in agile teams. Our major new contribution is an extended model of onboarding for agile teams.
Full-text available
Recruiting participants is a necessary step in many studies. With the advent of online research techniques, scientists are looking for new places where participants can be recruited online, in order to overcome the limitations of current sources and avoid the issues associated with sample overuse. The social media website “Reddit” is a potential source for recruitment, as it allows for free and rapid data collection from large samples, while enabling researchers to target specific populations when needed. The ability to recruit for free is especially important because it enables students and early career researchers, for whom even low recruitment costs can be prohibitive, to benefit from the opportunity of conducting research that they otherwise would not be able to. The current article therefore aims to bring this prospective, untapped resource to the attention of the research community. The article discusses current online recruitment sources and their limitations, provides an overview of Reddit, validates its use for research purposes, examines participation data from previous studies which recruited through Reddit, highlights its advantages and limitations as a participant pool, and suggests guidelines that can improve recruitment and retention rates for scientists looking to use Reddit for their research.
Full-text available
Skilled workers are crucial to the success of software development. The current practice in research and industry for assessing programming skills is mostly to use proxy variables of skill, such as education, experience, and multiple-choice knowledge tests. There is as yet no valid and efficient way to measure programming skill. The aim of this research is to develop a valid instrument that measures programming skill by inferring skill directly from the performance on programming tasks. Over two days, 65 professional developers from eight countries solved 19 Java programming tasks. Based on the developers’ performance, the Rasch measurement model was used to construct the instrument. The instrument was found to have satisfactory (internal) psychometric properties and correlated with external variables in compliance with theoretical expectations. Such an instrument has many implications for practice, for example, in job recruitment and project allocation.
Conference Paper
Full-text available
Context: Most of the software organizations that use agile methods organize daily team meetings. Aim: Our aim was to understand how daily meetings are conducted and identify obstacles that reduce their efficiency. Method: We observed 56 daily meetings and conducted 21 interviews in three different teams in two countries. We used the repertory grid technique in the interviews and to analyze the results. Results: We identified thirteen obstacles. The four most prominent ones were: (1) The daily meetings lasted too long (on average, 22 minutes instead of the scheduled 15 minutes). (2) In the meetings that were not self-organized, team members reported to the Scrum Master instead of sharing information among all team members. (3) The interruption caused by daily meetings required substantially more time than the actual meeting time due to overhead before and after the meetings. (4) Several team members had negative attitudes towards the daily meetings. Conclusion: Organizers of daily meetings should evaluate whether the obstacles we have identified are present in their organization and consider our suggestions to remove or reduce these obstacles.
Conference Paper
Full-text available
An increasing amount of time is being spent at organizational meetings. One common type of meeting in software projects is the daily team meeting, which is the most important forum for coordinating and planning daily work. To better understand how software teams make decisions, communicate, and coordinate their work, we must uncover the micro-level interaction processes among the team members at these meetings. We analyzed transcriptions of eight daily meetings from two software development teams. The agile literature states that the daily meeting should focus on answering questions such as "What have I done? What will be done? What obstacles are in my way?" However, on average, only 24% of each of the meetings that we studied focused on this task. We found that 35% of the meeting was spent on elaborating problem issues and discussing possible solutions. Very little time was used for coordinating tasks. Our results indicate that many project decisions are made in daily team meetings and that this quick decision making requires team members to be experts. These experts need to have a shared understanding of who is responsible for what and of the information and requirements needed to solve the tasks.
Context Practitioners and researchers often claim that agile methods have moved into the mainstream for the last few years. To support this claim they refer to recent industrial surveys which tend to report high rates of agile method usage. However many of these industrial surveys are conducted by agile consultants, tool vendors, professional societies and independent technology and market research organizations. This raises some important concerns about the possible conflict of interest and the overall trustworthiness of these studies. Objective In response to the above concerns, a secondary study was carried out. Its objective was to examine industrial surveys published in 2011 and 2012, determine the extent to which we could trust their reported high rates of agile method usage and provide recommendations on how quality of research could be imporved in the future. Method Following a rigorous search procedure, nine industrial surveys on agile method usage published in 2011 and 2012 were extracted from both academia and industry. Their thoroughness in reporting and trustworthiness were evaluated using a newly proposed assessment framework based on Guba's four attributes of trustworthiness (truth value, applicability, consistency and neutrality) and a number of methods for assessing survey research in related fields as information, communication and management studies. Results The careful examination of the reviewed surveys shows that most of the studies have insufficient thoroughness in reporting and (subsequently) low trustworthiness. Only one (out of nine) study is considered as a scientific contribution in determining the current 2011/2012 rate of agile method usage. Conclusions The obtained results support our initial considerations about the trustworthiness of recent industrial surveys on agile method usage and suggest a number of recommendations for increasing the quality and value of future survey research in this regard.
Conference Paper
Earlier empirical studies have demonstrated the interest that agile methods have generated in the software industry. Currently, lean approaches are increasingly adopted for complementing agile methods in software processes. With the goal of providing up-to-day results that can be used by organizations implementing or planning to implement agile and/or lean methods, we have conducted a study on the current stage of agile and lean adoption and usage in the software industry. For this purpose, we conducted an extensive survey among Finnish software practitioners in 2011, using the membership registry of The Finnish Information Processing Association (FIPA)as a sampling frame. 408 responses were collected from 200 software intensive organizations in the study. The survey included questions for identifying the rate of agile and lean usage in software organizations as well as the implementation of specific methods and practices, goals in adopting agile and lean, reasons for not applying these methods and effects of the agile and lean usage. The results of the survey reveal that a majority of respondents' organizational units are using agile and/or lean methods (58%). Furthermore, lean appears as a new player, being used by 24% of respondents, mainly in combination with agile (21%). The reasons and benefits for using agile and lean methods appeared to correspond in most parts to the findings of the earlier research. Generally, the experiences of using agile and lean methods seem to be rather positive, although challenges, such as obtaining management support and limitations for scaling agile in distributed settings, were also identified.