Lightning app delivery & backlog (Avenir Télécom)

Context

Following an internal audit, Avenir Télécom's South-zone sales teams needed a Salesforce Lightning app better aligned with their daily work (leads, accounts, opportunities, quotes).

The mission wasn't to code the app but to define and equip its delivery: an implementation strategy for a small 3-person Salesforce dev team, a costed product backlog, a test plan, a best-practices reference — then, from the feedback of a 3-month pilot simulated by the scenario, consolidating the feedback into a prioritized evolutions backlog.

The scenario's team: a senior developer (Apex & API integrations), a mid-level developer (automation & workflows) and a junior developer (UI/UX, testing, documentation).

The product backlog (Scrum)

20 user stories written, costed and prioritized, with acceptance criteria and prerequisites. The most structuring ones:

The costing isn't decorative: every story is estimated and assigned to the right seniority level — API integrations and security go to the senior, automation to the mid-level, UI and tests to the junior. That's what makes the sprint plan sustainable rather than optimistic.

The test plan & the Apex reference

The test plan (20 classes: TestLeadsCRUD, TestComptesImport, TestOpportunites, TestRunAsUser, TestSuppressionRGPD…) comes with an Apex best-practices reference — a team standard, not a checklist:

• Systematic bulkification: no SOQL or DML inside a loop, collections everywhere (List / Set / Map).
• One trigger per object, logic delegated to handlers — One Trigger Framework + Service Layer pattern.
• Configuration externalized to Custom Settings / Custom Metadata instead of hardcoded.
• Async matched to the use case: Batch Apex (large volumes), Queueable (sequencing), Future (external calls), Scheduled (periodic).
• Security: systematic with sharing, CRUD/FLS checks in data-access methods.
• Minimum required coverage: ≥ 75%.

Security, from the backlog

Security isn't an end-of-project workstream — it's in the user stories:

• US13 — the GDPR purge is a story in its own right, with an audit log, not an improvised manual cleanup.
• US18 / US20 — the Apex run as user tests actually validate profile isolation: each profile is put under test to prove it only sees its own data. That's a test, not an assumption.
• with sharing and CRUD/FLS checks written into the reference, so applied by construction.

From pilot to evolutions backlog

The scenario then simulates a 3-month pilot with the South-zone field teams: the feedback provided by the brief was consolidated into a prioritized Kanban backlog, with WIP limits and Notion documentation dynamically linking product backlog ↔ test plan ↔ evolutions backlog:

• 3 evolutions — E1 two-way interface with the CaseIn request-management tool · E2 automatic daily backup to a dedicated SFTP · E3 Dev Org config hardening.
• 3 fixes — C1 account sync via SIREN Webservice · C2 standardized opportunity naming format · C3 immediate rep notification on lead assignment.
• 3 bugs reported by the simulated pilot — B001 broken lead → opportunity conversion (high priority) · B002 incorrect imported account data · B003 assignment notifications not sending (fixed).

The loop is closed: a bug reported by the pilot (B003) links to fix C3, which links back to story US1. A reviewer can follow the thread.

Decisions & assumed limitations

Assumed limitations:

• The product backlog is a costed specification, not an end-to-end executed deliverable — the value is in the quality of the framing and the test plan, tested against the feedback of a simulated pilot, not in a rollout across all of Avenir Télécom.
• B002 (incorrect imported account data) is tracked but not resolved within scope: identified, prioritized, left to the next sprint — flagged rather than hidden.

Results

What this project demonstrates

Not code depth, but delivery discipline: framing a scope, costing it and assigning it to the right level, writing a test plan that becomes a team standard, and closing the pilot → evolutions loop with full traceability. It's the dimension most often missing from a junior portfolio — and it's visible here, with the artefacts to back it.

Fil-rouge project from the RNCP Level 6 "Développeur Concepteur Logiciel" diploma (OpenClassrooms): imposed context, team and constraints, deliverable defended before a jury. It is expanded here with the team-strategy / testing / security-by-design / feedback-loop reading expected in a professional context — beyond the strict scope of the exercise.