Artefacts in Agile Software Development

Wagenaar, Gerard; Helms, Remko; Damian, Daniela; Brinkkemper, Sjaak

doi:10.1007/978-3-319-26844-6_10

Cited by 6 publications

(9 citation statements)

References 21 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Communication with management is thus to be expected; Scrum teams do not operate in a vacuum. In a previous study we already found that Scrum teams use project plans and progress information for control purposes [31]. And our current results show the structural character of this communication.…”

Section: Discussionsupporting

confidence: 76%

Competencies outside Agile Teams’ Borders: The Extended Scrum Team

Wagenaar¹,

Overbeek²,

Helms³

2016

Annals of Computer Science and Information Systems

Self Cite

View full text Add to dashboard Cite

Abstract-According to the Scrum process framework a Scrum team should have all necessary competencies to accomplish its work. Fragmented and anecdotal evidence hints at Scrum teams still needing additional, external competencies. To contribute to theories on Scrum team composition and practitioner's concerns in staffing a Scrum team we investigated Scrum teams' cross-functionality: To whom do Scrum teams turn for additional competencies, which competencies are involved and how are Scrum teams aware of additional competencies they need? To this extent we analysed the communication in three Scrum teams during one of their Sprints. Our results show that additional competencies are called for, not only on an ad hoc basis, but also on a structural basis. To include those structural competencies the notion of an extended Scrum team is introduced.

show abstract

Section: Discussionsupporting

confidence: 76%

Competencies outside Agile Teams’ Borders: The Extended Scrum Team

Wagenaar¹,

Overbeek²,

Helms³

2016

Annals of Computer Science and Information Systems

Self Cite

View full text Add to dashboard Cite

show abstract

“…When we compare the artefacts in Fig. 2 with previous research on artefact models (Bass 2016;Gröber 2013;Wagenaar et al 2015), we encounter many similarities. Differences occur, but seem to be more a result of choices with regard to granularity rather than fundamental differences.…”

Section: Conclusion and Discussionmentioning

confidence: 75%

“…We define an artefact, in line with previous research, as a tangible deliverable produced during software development, including materials in both physical and electronic format (Wagenaar et al 2015). This definition certainly includes physical artefacts, such as story cards and the Wall (Sharp et al 2009), but allows in fact for a much broader spectre of artefacts.…”

mentioning

confidence: 99%

“…Recent studies on artefacts usage in ASD shows that agile developers use quite a number of artefacts (Bass 2016;Gröber 2013;Liskin 2015;Wagenaar et al 2015;Wagenaar et al 2017). Some of them are inherent to an ASD method, for instance, user story or backlog, but others are not, recalling bygone memories from a Waterfall era, that advocated program design first and documenting it thoroughly, using, for instance, a design and a test document (Royce 1970).…”

mentioning

confidence: 99%

See 1 more Smart Citation

Working software over comprehensive documentation – Rationales of agile teams for artefacts usage

Wagenaar

Overbeek

Lucassen

et al. 2018

J Softw Eng Res Dev

Self Cite

View full text Add to dashboard Cite

Agile software development (ASD) promotes working software over comprehensive documentation. Still, recent research has shown agile teams to use quite a number of artefacts. Whereas some artefacts may be adopted because they are inherently included in an ASD method, an agile team decides itself on the usage of additional artefacts. However, explicit rationales for using them remain unclear. We start off to explore those rationales, and state our primary research question as: What are rationales for agile teams to use artefacts? Our research method was a multiple case study. In 19 agile teams we identified 55 artefacts and concluded that they in general confirm existing research results. We introduce five rationales underlying the usage of artefacts in ASD: (1) Adoption of ASD leads to agile artefacts, (2) teaminternal communication leads to functional and technical design artefacts, (3) quality assurance leads to test-related artefacts, (4) agile teams impose governance on their own activities, and (5) external influences impose user-related material. With our contribution we substantiate the theoretical basis of the Agile Manifesto in general and contribute to the current research with regard to the usage of artefacts in ASD in particular. Agile teams themselves may from this research extract guidelines to use more or less comprehensive documentation.

show abstract

“…Instead, face-to-face communication should be encouraged in order to convey information. Nevertheless, Agile practitioners have increasingly changed their attitude towards documentation [22] and are producing a variety of artifacts that are not inherent to ASD [2,16,23]. According to Wagenaar et al [24], practitioners need additional artifacts for four reasons: i) they provide team governance, ii) they are useful for internal communication, iii) they are needed by external parties, and iv) they are useful for quality assurance.…”

Section: Introductionmentioning

confidence: 99%

What Makes Agile Test Artifacts Useful?

Fischbach¹,

Femmer²,

Méndez

et al. 2020

Proceedings of the 14th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)

View full text Add to dashboard Cite

Background: The artifacts used in Agile software testing and the reasons why these artifacts are used are fairly well-understood. However, empirical research on how Agile test artifacts are eventually designed in practice and which quality factors make them useful for software testing remains sparse. Aims: Our objective is twofold. First, we identify current challenges in using test artifacts to understand why certain quality factors are considered good or bad. Second, we build an Activity-Based Artifact Quality Model that describes what Agile test artifacts should look like. Method: We conduct an industrial survey with 18 practitioners from 12 companies operating in seven different domains. Results: Our analysis reveals nine challenges and 16 factors describing the quality of six test artifacts from the perspective of Agile testers. Interestingly, we observed mostly challenges regarding language and traceability, which are well-known to occur in non-Agile projects. Conclusions: Although Agile software testing is becoming the norm, we still have little confidence about general do's and don'ts going beyond conventional wisdom. This study is the first to distill a list of quality factors deemed important to what can be considered as useful test artifacts. CCS CONCEPTS • Software and its engineering → Agile software development; • General and reference → Empirical studies.

show abstract

Artefacts in Agile Software Development

Cited by 6 publications

References 21 publications

Competencies outside Agile Teams’ Borders: The Extended Scrum Team

Competencies outside Agile Teams’ Borders: The Extended Scrum Team

Working software over comprehensive documentation – Rationales of agile teams for artefacts usage

What Makes Agile Test Artifacts Useful?

Contact Info

Product

Resources

About