Farline AI
Core Features

Understanding Project Definition Structure

Farline AI uses a YAML-based project definition to define projects. This article explains the structure and all available fields.

Basic Project Structure

project_name: My Project
unit: people weeks

scenarios:
  - scenario: Baseline
    start_date: 2025-04-01
    workstreams:
      - name: Team
        capacity: 3
    work_items:
      - id: TASK-1
        name: Design
        size: 5
        workstream: Team
        priority: 1
      - id: TASK-2
        name: Build
        size: 8
        workstream: Team
        priority: 2
        depends_on: [TASK-1]
      - id: TASK-3
        name: Test
        size: 4
        workstream: Team
        priority: 3
        depends_on: [TASK-2]
    milestones:
      - name: Project Complete
        target_date: 2025-05-01
        includes: [TASK-3]

Project-Level Fields

project_name (required)

The name of your project.

project_name: Website Redesign

unit (required)

The unit of measurement for capacity and work item sizes. Common values:

  • story points
  • engineer-days
  • hours
  • sprints
unit: story points

Scenarios

Each project can have multiple scenarios to model different planning options.

scenario (required)

The scenario name. Common scenarios:

  • Baseline - Your current plan
  • Optimistic - Best case scenario
  • Pessimistic - Worst case scenario
  • Fast Track - With additional resources

start_date (required)

The date work begins for this scenario (ISO format).

scenarios:
  - scenario: Baseline
    start_date: 2025-04-01
    workstreams: [...]
    work_items: [...]
  - scenario: Fast Track
    start_date: 2025-04-01
    workstreams: [...]
    work_items: [...]

Workstreams

Workstreams represent teams or tracks of work.

name (required)

The workstream name.

- name: Frontend Team

capacity (required)

How many units of work this workstream can complete per week.

capacity: 10  # 10 story points per week

start_delay (optional)

Delay the start of this workstream by a number of weeks.

start_delay: 2  # Start 2 weeks into the project

max_concurrent_items (optional)

Maximum number of work items that can be in progress simultaneously (WIP limit).

max_concurrent_items: 2  # Only work on 2 items at a time

Without this setting, the workstream can work on as many items as its capacity allows. Use WIP limits to:

  • Focus the team on fewer items for faster completion
  • Reduce context switching overhead
  • Create more realistic schedules

Work Items

Work items are the individual pieces of work to be completed. Work items are defined at the scenario level (not nested under workstreams) and reference their workstream by name.

id (required)

Unique identifier for the work item. Used in dependencies.

- id: backend-api

name (required)

Display name for the work item.

name: Build Backend API

size (required)

How many units of work this item requires (in your project's unit).

size: 25  # 25 story points

workstream (required)

The name of the workstream this item is assigned to.

workstream: Backend Team

depends_on (optional)

Array of work item IDs that must complete before this item can start.

depends_on: [ui-design, backend-api]

priority (optional)

Priority hint for slot allocation when WIP limits are in effect. Lower numbers = higher priority. Items with the same priority can run in parallel. This is a soft scheduling preference, not a strict ordering constraint.

priority: 1  # Higher priority - gets slots first when WIP limits apply

delay (optional)

Add a fixed delay (in weeks) before this work item starts.

delay: 2  # Wait 2 weeks before starting

Milestones

Milestones represent key dates that depend on work items.

name (required)

Display name for the milestone.

- name: Beta Release

target_date (required)

The desired completion date for this milestone (ISO format).

target_date: 2025-06-01

includes (required)

Array of work item IDs that must complete before this milestone is reached.

includes: [testing, documentation]

Complete Example

project_name: Mobile App Launch
unit: story points

scenarios:
  - scenario: Baseline
    start_date: 2025-04-01
    workstreams:
      - name: iOS Team
        capacity: 12
        max_concurrent_items: 2  # Focus on 2 items at a time

      - name: Backend Team
        capacity: 8

    work_items:
      - id: ios-auth
        name: Authentication
        size: 15
        workstream: iOS Team
        priority: 1

      - id: ios-core
        name: Core Features
        size: 40
        workstream: iOS Team
        priority: 2
        depends_on: [ios-auth]

      - id: ios-polish
        name: Polish & QA
        size: 20
        workstream: iOS Team
        priority: 3
        depends_on: [ios-core]

      - id: api-setup
        name: API Infrastructure
        size: 10
        workstream: Backend Team
        priority: 1

      - id: api-endpoints
        name: API Endpoints
        size: 25
        workstream: Backend Team
        priority: 2
        depends_on: [api-setup]

      - id: api-testing
        name: API Testing
        size: 15
        workstream: Backend Team
        priority: 3
        depends_on: [api-endpoints]

    milestones:
      - name: Alpha Release
        target_date: 2025-06-01
        includes: [ios-core, api-endpoints]

      - name: Public Launch
        target_date: 2025-07-01
        includes: [ios-polish, api-testing]

Tips for Writing Project Definitions

  1. Indentation matters - YAML uses 2 spaces per level (not tabs)
  2. Use quotes sparingly - Only needed for special characters or numbers as strings
  3. Test incrementally - Build your project definition step by step
  4. Use the AI - The AI chat can generate the project definition for you if you describe what you want
  5. Dependencies are powerful - Use them to model realistic project constraints

Common Patterns

Parallel Workstreams

Multiple teams working simultaneously:

workstreams:
  - name: Team A
    capacity: 10
  - name: Team B
    capacity: 10

work_items:
  - id: task-a
    name: Team A Work
    size: 20
    workstream: Team A
  - id: task-b
    name: Team B Work
    size: 20
    workstream: Team B

Sequential Phases

Work items that must happen in order:

work_items:
  - id: phase1
    name: Phase 1
    size: 20
    workstream: Team
    priority: 1

  - id: phase2
    name: Phase 2
    size: 30
    workstream: Team
    priority: 2
    depends_on: [phase1]

  - id: phase3
    name: Phase 3
    size: 25
    workstream: Team
    priority: 3
    depends_on: [phase2]

Cross-Team Dependencies

Frontend depending on backend:

workstreams:
  - name: Backend
    capacity: 5
  - name: Frontend
    capacity: 5

work_items:
  - id: api
    name: Build API
    size: 20
    workstream: Backend

  - id: ui
    name: Build UI
    size: 15
    workstream: Frontend
    depends_on: [api]  # Waits for backend

Last updated: 2025-12-19

Managing Workstreams and Dependencies

Previous Page

Project Templates

Next Page

On this page

Basic Project StructureProject-Level Fieldsproject_name (required)unit (required)Scenariosscenario (required)start_date (required)Workstreamsname (required)capacity (required)start_delay (optional)max_concurrent_items (optional)Work Itemsid (required)name (required)size (required)workstream (required)depends_on (optional)priority (optional)delay (optional)Milestonesname (required)target_date (required)includes (required)Complete ExampleTips for Writing Project DefinitionsCommon PatternsParallel WorkstreamsSequential PhasesCross-Team DependenciesRelated Articles