Work Package Decomposition Methodology (WBS)¶

This section describes how we break down complex CRM/ERP implementations into manageable and estimable Work Packages (WP). This methodology ensures consistent scope, accurate estimates, and transparent communication with the client.

1. Documentation Driven¶

Our documentation in docs-new serves as the blueprint for agents and the team. Before starting any work, a reference to standard functionality must exist.

Identification: Agents first verify if the entity/feature already exists in module documentation.
Validation: Scope is compared against standard module capabilities (e.g., /moduly/fakturace/).

2. WBS Numbering Convention¶

Each work package has a unique ID in the format: [MODULE]-[PROCESS]-[TYPE]-[SEQUENCE]

Code	Meaning	Examples
MODULE	Module Code	`CRM` (Sales), `FIN` (Finance), `WH` (Warehouse), `PROD` (Production)
PROCESS	Business Process	`L2O` (Lead-to-Opportunity), `O2C` (Order-to-Cash), `INV` (Inventory)
TYPE	Work Type	`ENT` (Entity), `WF` (Workflow), `API` (Integration), `MIG` (Migration)
SEQUENCE	Number	`001`, `002`...

Examples: * CRM-L2O-ENT-003 = Opportunity entity configuration * FIN-O2C-API-002 = Invoice push to Pohoda * WH-INV-WF-004 = Inventory reservation workflow

3. Package Types & Templates¶

Standard Package Scope (Guardrails)¶

To prevent "scope creep", we define what constitutes one WP. Anything beyond is a new WP.

WP Type	Standard Inclusions	Beyond Standard = New WP
ENT	Up to 25 fields, 2 relationships, 2 layouts	Additional fields, complex logic
WF	Up to 3 actions per step	Additional action groups
API	One object, one direction	Additional endpoint or direction
MIG	One object from one source	Additional object or source

Entity Specification Template (ENT)¶

## WBS: [ID]
**Entity:** [Name]
**Purpose:** [Description]

### Fields
| Name | Type | Required | Validation |
| :--- | :--- | :--- | :--- |
| name | varchar | Yes | max 150 chars |
| status | enum | Yes | New, Active, Closed |

### Acceptance Criteria
- [ ] Fields render correctly per role
- [ ] Validations work
- [ ] CRUD operations functional

4. Complexity Scoring Models¶

We use mathematical models for accurate effort estimation.

Entity Scoring (ENT)¶

Score dimensions 0-3 (Data, Relationships, UI, Logic, Security, Integration).

Formula (range 5-16h): $$ Hours = 3 + 0.6 \times Data + 0.8 \times Rel + 0.6 \times UI + 1.2 \times Logic + 0.4 \times Sec + 0.4 \times Int $$

Workflow Scoring (WF)¶

Score per "step" (Branching, External calls, Data, Timers, UI).

Formula (range 1-4h/step): $$ Hours = 0.8 + 0.6 \times Branch + 0.6 \times Ext + 0.5 \times Data + 0.4 \times Time + 0.3 \times UI $$

Integration Scoring (API)¶

Score dimensions (Auth, Mapping, Transformation, Direction, Error handling).

Formula (range 8-28h): $$ Hours = 6 + 1.0 \times Auth + 1.5 \times Map + 1.0 \times Trans + 1.0 \times Dir + 0.8 \times Err $$

5. Quality Gates¶

Definition of Ready (DoR) - Before Start¶

[ ] Spec filled to ≥80%
[ ] Dependencies identified
[ ] Test data available
[ ] Approved by Product Owner

Definition of Done (DoD) - Upon Completion¶

ENT: Fields/layouts configured, permissions verified, 5 test records.
WF: All branches tested (incl. negative), notifications verified.
API: Connectivity OK, 5 success payloads, 3 error states handled.
MIG: Count reconciliation (±1%), spot check 20 records.

6. Agile Adaptation¶

Sprint: 2 weeks.
WP Size: 4-16h. Larger items must be split.
MVP Slicing: Identify "Steel Thread" (smallest viable process path) for rapid value delivery.