Why Agile fits Oracle Cloud projects
Oracle Cloud projects used to run on waterfall — 6 months of design, 6 months of build, 3 months of testing. Today’s implementation pace doesn’t support this. Agile delivers working integrations and applications incrementally, allowing course correction before the entire build is complete.
Sprint structure for integration projects
Sprint 0 (2 weeks): environment setup, architecture decisions, development standards, integration inventory, connection configurations. No deliverables to business users — infrastructure sprint.
Feature sprints (2 weeks each): typically 3-5 integrations or 1-2 VBCS features per sprint, depending on complexity.
Hardening sprint (2 weeks): performance testing, security review, user acceptance testing, documentation completion.
Writing user stories for integrations
As a [Finance Manager],
I want [supplier invoice data automatically imported from the supplier portal into Fusion AP],
so that [invoices don't require manual keying and are processed within 24 hours of receipt].
Acceptance criteria:
- Invoice imports run every 4 hours during business hours
- Duplicate invoices are detected and rejected with notification
- Failed imports are retried once and escalated after 2 failures
- 100% of imported invoices appear in Fusion AP within 15 minutes of the import run
Good integration user stories specify the trigger, transformation, error handling, and measurable outcome.
Estimation for OIC integrations
Use story points on an empirical scale based on your team’s velocity:
- 1-2 points: simple REST-to-REST with minimal mapping (e.g. GET order status and return to VBCS)
- 3-5 points: scheduled integration with error handling, moderate mapping (e.g. employee sync)
- 8-13 points: complex orchestration, multiple systems, business rule logic (e.g. FBDI automation with monitoring)
Don’t estimate in hours — it leads to constant re-negotiation when estimates are missed.
Managing client expectations
Demo at the end of every sprint, not just at UAT. Showing working software every two weeks builds confidence, surfaces misunderstandings early, and keeps stakeholders engaged. A sprint demo that reveals a requirement misunderstanding in week 4 is far less costly than discovering it in month 6.