A systematic literature review published in MDPI’s Software journal (April 2026) synthesizes 42 studies on decision-making in agile software engineering. Hannes Salin and Yves Rybarczyk (Dalarna University) screened 1,391 papers from 2014–2024 to map how decisions are modeled, made, and studied across the agile lifecycle.
The headline finding: research on agile decision-making is heavily lopsided.
- Planning is the most-studied stage (34 studies) with the greatest diversity of decision models; requirements follows with 20
- Analytical (15) and hybrid (11) models dominate; intuitive and consensus models are barely represented
- Coding, testing, and release/operations are “significantly underrepresented”
- Developers are the decision actors in over 78% of studies; managers appear mainly as escalation authorities — no reviewed study examines managers as agile decision-makers in their own right
- Group decisions dominate; individual autonomous decisions are under-theorized
The authors argue this is partly a research accessibility bias: planning ceremonies are formalized, artifact-driven, and observable, while coding and testing decisions are tacit, rapid, and embedded in the work — so they rarely get documented or studied. In socio-technical terms, agile’s “social subsystem” (collaboration, ceremonies) is well supported while its “technical subsystem” (implementation-time judgment) has no standardized toolkit.
Recurring methods include multi-criteria decision-making (AHP, Best–Worst Method), architectural evaluation (ATAM-style), consensus practices (workshops, retrospectives), and data-driven/ML approaches. Structured methods reliably improve clarity, transparency, prioritization accuracy, and role alignment — but only when backed by psychological safety and shared understanding. Communication gaps, conflicting priorities, autonomy-vs-control tension when scaling, and data quality problems keep biting.
The practical takeaway is pointed: extend structured decision support — explicit trade-off discussions, lightweight analytics, decision forums — into coding, testing, and release, where decisions carry real quality and risk weight. And clarify which decisions teams own, when escalation is expected, and how cross-team dependencies are handled. The paper also proposes a common nomenclature (models, methods, types, contexts, outcomes) to fix terminology so fragmented that studies in the same field can barely be compared.