Agile methods don’t work for ERP projects. This shortcut — heard far too often in project kickoff meetings — reflects a shallow reading of both terms. An ERP is not a software product built from scratch; Scrum is not a magic recipe you can paste over any project without adaptation. But the idea that the two are fundamentally incompatible is simply wrong.
This practical guide is for ERP project managers, CIOs, and consultants who want to modernise their methodology without wishful thinking. You’ll see how to adapt agile principles to the real constraints of an ERP deployment: inter-module dependencies, cascading configuration, a single go-live event, and key-user availability. The goal is not to run pure Scrum on SAP S/4HANA — it’s to take what genuinely works in agile and integrate it intelligently into your project.
Why ERP Resists Pure Agile
The ERP–Agile Paradox: Real Constraints
An ERP is a tightly coupled system. The general ledger depends on the chart of accounts, which determines inventory valuation, which feeds management accounting. This cascade of dependencies makes it difficult to carve out truly independent increments — the cornerstone of classical Scrum. If a sprint modifies the validation logic for purchase orders, the impact immediately ripples through accounts payable and potentially through statutory reporting.
Add to this the go-live constraint. In a SaaS product project, you can release a feature to 10% of users, measure adoption, correct, then roll out further. In an ERP deployment, the cutover day is often binary: either everyone switches, or nobody does. A half-deployed ERP has no operational value. This directly contradicts the agile principle of a “usable deliverable at the end of every sprint.”
Finally, ERP vendors themselves historically structured their implementations around waterfall models. SAP proposed a linear ASAP approach for decades. Microsoft Sure Step, the official methodology for Dynamics, followed the same sequential model. These methods shaped the habits of systems integrators for twenty years.
What Classic Waterfall Projects Consistently Miss
Waterfall ERP delivery produces late deliverables and infrequent user feedback. The user acceptance testing phase arrives after months of configuration, when key users are seeing the system for the very first time. Gaps between what was specified and what is actually needed surface late — when corrections are expensive.
The second problem is accumulated validation debt. In a typical waterfall project, business processes are validated on paper during design, then again during acceptance testing. Between those two moments, during the build phase, the business team is barely involved. The result: months of work built on assumptions nobody tested under real conditions.
Agile doesn’t solve these problems by magic, but it forces them to be addressed earlier and more frequently.
Three Agile Models Adapted for ERP Projects
Adapted Scrum: 3-Week Sprints Scoped to a Functional Domain
The first adaptation concerns sprint length and scope. A classic Scrum sprint runs one to four weeks and targets a shippable software increment. In an ERP context, a three-week sprint scoped to a specific functional domain works better than a two-week sprint on raw configuration output.
In practice: a sprint covers the configuration of a specific business process (for example, the complete purchase-order-to-invoice cycle in the target ERP), its validation by the relevant key users, and documentation of the configuration decisions made. It’s not always a “deployable end-user feature” in the strict sense, but it is validated and documented configuration — which represents genuine progress.
A 200-person manufacturer deploying Odoo 17, for instance, might organise sprints around modules in this sequence: purchasing and stock in sprints 1 and 2, sales and CRM in sprint 3, accounting in sprint 4. This sequence respects functional dependencies while forcing regular validation checkpoints.
SAFe (Scaled Agile Framework) for Multi-Site Deployments
For large-scale projects covering multiple entities, multiple countries, or multiple business lines in parallel, Scrum alone is insufficient. SAFe (Scaled Agile Framework) provides a coordination layer for multiple agile teams working simultaneously.
In a multi-site ERP context, SAFe lets you synchronise sprints across different teams — finance, logistics, HR — through “Program Increments” (PIs) lasting 10 to 12 weeks. Each PI closes with an overall review and a PI Planning session for the next cycle. Inter-module dependencies are managed on a shared PI Board across teams.
SAFe makes sense when the project involves more than five parallel teams and a budget above €2 million. Below that threshold, its organisational overhead typically outweighs the benefits.
The Waterfall/Agile Hybrid: When It’s Justified
The hybrid model retains a waterfall design phase (scope definition, module selection, process mapping), then switches to agile for the build and testing phases. This model is particularly well suited when:
- regulatory requirements mandate exhaustive documentation before any configuration begins (banking, pharma, defence);
- the go-live is a simultaneous multi-country cutover that cannot tolerate scope uncertainty;
- the integrator is working on a fixed-price contract and needs a stable specification to manage contractual risk.
The danger with the hybrid model is a gradual drift back to pure waterfall, with the “agile phase” shrinking into a disguised acceptance testing exercise. To prevent this, the client-side Product Owner must stay involved in sprint reviews throughout the build phase, even if scoping was locked down upfront.
Building the ERP Functional Backlog
User Stories vs. Configuration Epics
In an ERP context, the backlog does not contain user stories in the SaaS sense (“as a buyer, I want to create a purchase order from my mobile”). The ERP backlog is organised around configuration epics corresponding to complete business processes, decomposed into configuration stories.
Example epic: “Three-level purchase order approval workflow.” Associated stories: configure approval groups, set up authorisation workflows, create order types, configure currencies and tax rules, run the full cycle with key users.
This granularity allows you to estimate effort in consultant-days per story, prioritise blocking stories for module dependencies, and track real progress sprint by sprint.
Prioritising with MoSCoW in an ERP Context
The MoSCoW technique (Must have, Should have, Could have, Won’t have) applies well to ERP backlogs — with one important nuance: in an ERP, a “Must have” is often imposed by regulation or core business processes, not by user preference.
A statutory compliance process (VAT returns, audit trails, statutory financial reports) is always a Must have, even if end users rarely think about it. A supplier self-service portal is typically a Could have for the initial go-live.
The practical rule: if the absence of the feature would prevent the business from operating legally or operationally on go-live day, it’s a Must have. Everything else can be deferred.
Managing Inter-Module Dependencies
Inter-module dependencies in ERP follow a fairly consistent pattern: general ledger accounting sits downstream of almost every transactional module (purchasing, sales, inventory, payroll). Chart-of-accounts setup and accounting rules must therefore precede configuration of any module that generates journal entries.
A simple tool for visualising these dependencies: a module precedence table. For each module, list the modules that must be validated before it. This table drives sprint sequencing and team dependencies in a SAFe context.
Adapting Scrum Ceremonies for ERP
Sprint Planning: Defining Deliverables in an ERP Context
The core difficulty of ERP sprint planning is defining what “deliverable” means at sprint end. An ERP module is not deliverable until all its core processes are configured and validated. The solution is to define “vertical slices” within a module.
For the purchasing module, for example: sprint 1 covers the core purchasing cycle (purchase order, goods receipt, supplier invoice) for domestic suppliers; sprint 2 adds intra-EU suppliers with reverse-charge VAT and deposit tracking. Each sprint produces a functional subset that can be validated independently.
Sprint Reviews with Key Users: A Working Format
The sprint review is the most valuable ceremony in the ERP Scrum cycle. It brings together the business key users relevant to the sprint scope — not the whole company, just the three to five people who will validate the configured process. Recommended duration: two hours maximum.
A workable format: 15 minutes recapping sprint scope, 60 minutes of hands-on demonstration in the test environment (consultant drives, key user validates or challenges), 30 minutes prioritising open items for the next sprint, 15 minutes formal sprint sign-off.
Sign-off must be formalised in writing. A sprint acceptance record signed by the key user represents a commitment, not just a meeting impression.
Post-Module Retrospectives
The post-module retrospective differs from a standard sprint retrospective. It runs when a complete module goes into partial production (module go-live before the full cutover) or when all sprints for a module are complete. It examines three dimensions: what worked well in how the team organised its work, recurring blockers, and adjustments needed for the next modules.
Definition of Done for a Configured ERP Module
The DoD in an ERP context must cover at minimum: configuration in the test environment is documented (screenshots, description of parameterised rules); full-cycle tests have been run and results are tracked; the relevant key users have validated the sprint review; test data has been purged and reference data is migrated in the tested scenario.
Without an explicit DoD, sprints end “roughly done” and the tail effect adds several weeks to the project before go-live.
Five Mistakes to Avoid When Mixing Agile and ERP
1. Running pure Scrum on SAP S/4HANA without adaptation. SAP Activate — the official SAP methodology for S/4HANA — is already a hybrid approach with defined phases (Discover, Prepare, Explore, Realize, Deploy, Run). It incorporates Fit-to-Standard Workshops that serve as sprint reviews. Overlaying vanilla Scrum generates conflicts between Activate artefacts (Accelerators, Templates) and Scrum artefacts (Product Backlog, Sprint Backlog). Enriching Activate with agile elements is far more effective than starting from scratch.
2. Neglecting configuration documentation. A backlog is not a configuration record. The decision to set up a suspense account for cash-basis VAT must be documented in a configuration document — not just left as a Jira ticket comment. Without that documentation, every consultant who touches the system after go-live starts from zero.
3. Skipping regression testing between sprints. When sprint 4 configures the accounting module, it may modify settings that affect the purchasing and sales modules configured in sprints 1 and 2. Without systematic regression testing, these regressions are discovered only during full acceptance testing — too late to resolve comfortably.
4. Underestimating the key-user learning curve. Key users involved in sprint reviews are learning the ERP at the same time as they’re validating it. Attending a sprint review on a module you don’t yet understand is exhausting. Schedule training sessions before each sprint cycle on a new module — not just a global training programme at the end of the project.
5. Confusing Scrum velocity with ERP progress. Scrum velocity measures the volume of work delivered per sprint. In an ERP, a sprint may have low velocity (few stories closed) because an unresolved business decision is blocking configuration — not because the team is underperforming. Progress reporting to sponsors must clearly distinguish stories blocked by unresolved business choices from execution delays.
Recommended Tooling
Jira, Azure DevOps, Linear or Notion for the ERP Backlog
Jira remains the most widely used backlog tool for ERP projects, partly because many SAP and Microsoft partners already use it natively. Azure DevOps is often preferred in Microsoft environments (Dynamics 365). Linear works well for Odoo or NetSuite projects driven by agile-native tech teams. Notion is acceptable for small projects (fewer than five modules, a single team) but shows its limits on complex backlogs with cross-story dependencies.
Whatever tool you choose, the minimum viable setup is: an epic / story / sub-task hierarchy; dependency tracking between stories; configurable statuses reflecting the ERP lifecycle (To configure, In progress, Pending validation, Validated, Closed); and a “module” field to filter the backlog by functional scope.
An Adapted Sprint Planning Template
An effective ERP sprint planning session starts with the sprint story list (drawn from the prioritised backlog), the consultant assigned to each story, dependencies on other modules or teams, and the explicit validation criterion for each key user. The sprint plan must be shared with key users at least 48 hours before the sprint starts, so they can block their calendars for the review.
Configuration data itself must be version-controlled. Configuration exports (Odoo XML files, SAP transport requests, Dynamics deployment packages) should be stored in a versioned repository. Without this discipline, projects accumulate a traceability debt that explodes during version upgrades or post-go-live patches.
Adapting agile to ERP does not promise less complexity. It promises more frequent user feedback, earlier detection of gaps, and an organisation that forces regular collaboration between the project team and the business. These three benefits are well worth the methodological adaptation effort.
For further reading, see our guide on the five phases of a successful ERP project, which details deliverables and milestones at each stage, and our article on ERP project team roles and the RACI matrix, which clarifies client-side Product Owner responsibilities in an agile ERP context.
