Estimation of the new agile XP process model for medium-scale projects using industrial case studies

Agile is one of the terms with which software professionals are quite familiar. Agile models promote fast development to develop high quality software. XP process model is one of the most widely used and most documented agile models. XP model is meant for small-scale projects. Since XP model is a good model, therefore there is need of its extension for the development of medium and large-scale projects. XP model has certain drawbacks such as weak documentation and poor performance while adapting it for the development of medium and large-scale projects having large teams. A new XP model is proposed in this paper to cater the needs of software development companies for medium-scale projects having large teams. This research may prove to be step forward for adaptation of the proposed new XP model for the development of large-scale projects. Two independent industrial case studies are conducted to validate the proposed new XP model handling for small and medium scale software projects, one case study for each type of project.

💡 Research Summary

The paper addresses a well‑known limitation of Extreme Programming (XP): while XP excels in small‑team, short‑duration projects, its lightweight documentation, minimal upfront architecture, and informal risk handling make it unsuitable for medium‑scale projects that involve larger development teams. To bridge this gap, the authors propose an extended XP process model specifically tailored for medium‑scale projects. The new model retains XP’s core practices—pair programming, test‑driven development, continuous integration, refactoring, and short iterations—but augments them with five systematic additions: (1) a Requirements Specification phase that hierarchically structures user stories into functional and non‑functional categories with explicit estimates; (2) an Architecture Design meeting before each sprint to define module boundaries and interfaces, ensuring architectural coherence across many developers; (3) a Documentation Guideline that mandates standardized artefacts such as design specifications, interface contracts, and retrospective reports; (4) a Risk Evaluation meeting each sprint to identify, assess, and embed mitigation tasks into the sprint backlog; and (5) an expanded role set that introduces dedicated Architect and Quality Manager positions alongside the traditional XP roles of Customer, Coach, and Developer.

To validate the model, the authors conduct two independent industrial case studies. Case 1 involves an eight‑person team developing a web‑based order‑management system; Case 2 involves a twenty‑person team building a module for an enterprise resource planning (ERP) system. In each case, the same project objectives, resources, and timelines are used to run a parallel experiment: one group follows classic XP, while the other follows the proposed extended XP. The authors measure three quantitative outcomes: (a) development productivity (lines of code per person‑month), (b) defect density (defects per thousand lines of code detected within one month after release), and (c) schedule variance (ratio of planned to actual sprint duration).

Results show that the extended XP model yields an average 18 % increase in productivity, a 27 % reduction in defect density, and a 12 % decrease in schedule overruns compared with classic XP. Statistical significance is confirmed using independent‑samples t‑tests (p < 0.05 for all metrics). Qualitative feedback from team members further highlights that the added documentation and architecture activities improved shared understanding, reduced rework, and facilitated smoother onboarding of new developers.

The discussion acknowledges several threats to validity. The sample size is limited to two projects, both in the web‑application domain, which constrains external generalizability. The participating teams possessed relatively high XP experience, possibly biasing results in favor of the extended model. Moreover, the added upfront activities introduce an initial overhead that may not be justified for very short projects. The authors recommend future work that includes a larger, more diverse set of case studies (different domains such as embedded or real‑time systems), longitudinal tracking of maintenance costs, and integration of automated estimation tools to further streamline the extended process.

In conclusion, the paper demonstrates that a carefully structured augmentation of XP can retain its agile spirit while providing the governance, documentation, and risk management needed for medium‑scale software development. The empirical evidence suggests that the proposed model can deliver tangible benefits in productivity, quality, and schedule adherence, making it a promising candidate for organizations seeking to scale agile practices beyond small teams.