Skip to Content
Core FeaturesWorking with Work Items

Working with Work Items

Work items are the building blocks of your project plan in Farline. Learn how to create, size, and manage them effectively.

What is a Work Item?

A work item represents a chunk of work that needs to be done in your project. Think of work items as:

  • Features or epics in agile projects
  • Deliverables or milestones in waterfall projects
  • Tasks or activities in general project management

Examples of work items:

  • “User Authentication”
  • “Build Product Catalog”
  • “Deploy to Production”
  • “Design Homepage Mockups”

Work Item Anatomy

Every work item in Farline has these properties:

ID (required)

A unique identifier for the work item within its workstream.

id: user-auth

Tips:

  • Use lowercase with hyphens (kebab-case)
  • Keep it short but descriptive
  • Must be unique within the workstream

Name (required)

The display name shown in charts and reports.

name: User Authentication

Tips:

  • Use title case
  • Be descriptive and specific
  • Keep under 50 characters for chart readability

Size (required)

How much work this item represents, measured in your project’s units (story points, days, hours, etc.).

size: 20

Tips:

  • Use consistent units across your project
  • Larger sizes = takes longer to complete
  • Consider team capacity when sizing

Dependencies (optional)

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

dependencies: - design-mockups - api-setup

Tips:

  • Use the ID, not the name
  • Multiple dependencies are supported
  • Creates sequential ordering in timeline

Group (optional)

Organize related work items into groups for better visualization.

group: Phase 1

Tips:

  • Groups show as visual sections in charts
  • Useful for releases, sprints, or phases
  • Optional but recommended for large projects

Creating Work Items

Via AI Chat

The easiest way to create work items is through conversation:

You: “Add a work item for database migration to the Backend workstream”

AI: “I’ll add that work item. How big should it be?”

You: “Make it 15 story points”

The AI will add the work item to your project YAML automatically.

Via YAML Editing

For advanced users, edit the YAML directly:

workstreams: - name: Backend Team capacity: 10 work_items: - id: db-migration name: Database Migration size: 15 - id: api-endpoints name: Build API Endpoints size: 25 dependencies: [db-migration]

Changes to the YAML update the charts in real-time.

Sizing Work Items

Choosing the right size is crucial for accurate forecasts.

Sizing Strategies

Story Points (Recommended)

  • Relative sizing based on complexity and effort
  • Example: 1, 2, 3, 5, 8, 13, 21 (Fibonacci sequence)
  • Small = 1-5, Medium = 8-13, Large = 21+

Days or Hours

  • Absolute time estimates
  • Example: “This will take 3 days”
  • Use if your team tracks time directly

T-shirt Sizes

  • Simplified relative sizing
  • Example: Small = 5, Medium = 10, Large = 20
  • Convert to numbers in Farline

Sizing Tips

Be consistent: Use the same scale across all work items in a project

Include everything: Factor in coding, testing, review, deployment

Account for unknowns: Add buffer for complexity and risk

Split large items: Break items >40 points into smaller pieces

Calibrate with history: Use past completed work as reference

Dependencies Between Work Items

Dependencies control the order work happens.

Why Use Dependencies

  • Technical requirements: API must exist before frontend can call it
  • Sequential work: Design before implementation
  • Resource constraints: Same person can’t do two things at once
  • Risk management: Validate approach before building on it

How Dependencies Work

When you add a dependency:

- id: frontend-ui name: Build Frontend UI size: 30 dependencies: [api-endpoints]

Farline schedules frontend-ui to start only after api-endpoints completes.

Multiple Dependencies

A work item can depend on multiple others:

- id: integration-testing name: Integration Testing size: 15 dependencies: - frontend-ui - api-endpoints - auth-system

integration-testing starts only after ALL three dependencies finish.

Dependency Chains

Dependencies can chain together:

design-mockups component-library page-implementation integration-testing

Farline calculates the full dependency tree and schedules appropriately.

Cross-Workstream Dependencies

Work items can depend on items in other workstreams:

workstreams: - name: Design Team work_items: - id: mockups name: Design Mockups size: 10 - name: Frontend Team work_items: - id: components name: Build Components size: 25 dependencies: [mockups] # References Design Team's work

This creates handoffs between teams.

Organizing Work Items

Use Groups

Groups help organize work items visually:

work_items: - id: user-login name: User Login size: 10 group: MVP Features - id: user-profile name: User Profile size: 15 group: MVP Features - id: admin-dashboard name: Admin Dashboard size: 20 group: Phase 2

Groups appear as visual sections in Gantt charts.

Sequence Numbers

Work items without dependencies execute in the order they appear:

work_items: - id: setup name: Project Setup size: 5 - id: core name: Core Features size: 30 - id: polish name: Polish and QA size: 10

These will run sequentially: setup → core → polish.

Parallel Work

Items with no dependencies and different IDs can run in parallel:

work_items: - id: feature-a name: Feature A size: 20 - id: feature-b name: Feature B size: 20

If the workstream has enough capacity, both run simultaneously.

Common Patterns

Sequential Phases

work_items: - id: discovery name: Discovery & Planning size: 10 - id: design name: Design Phase size: 20 dependencies: [discovery] - id: build name: Build Phase size: 50 dependencies: [design] - id: test name: Testing Phase size: 15 dependencies: [build]

Parallel Tracks

work_items: - id: frontend name: Frontend Development size: 40 - id: backend name: Backend Development size: 40 - id: integration name: Integration size: 20 dependencies: [frontend, backend]

Shared Foundation

work_items: - id: infrastructure name: Setup Infrastructure size: 15 - id: feature-1 name: Feature 1 size: 25 dependencies: [infrastructure] - id: feature-2 name: Feature 2 size: 25 dependencies: [infrastructure] - id: feature-3 name: Feature 3 size: 25 dependencies: [infrastructure]

Editing Work Items

Via Chat

Make changes through natural language:

Examples:

  • “Change the size of user-auth to 30”
  • “Add a dependency from frontend to backend”
  • “Remove the api-endpoints work item”
  • “Rename ‘Build UI’ to ‘Build User Interface‘“

Via YAML

Edit directly in the YAML editor:

  1. Find the work item in the YAML
  2. Make your changes
  3. Charts update automatically

Tip: Use Ctrl+F (Cmd+F on Mac) to find work items quickly.

Best Practices

Start with 5-10 work items per workstream: Don’t over-plan initially

Use meaningful IDs: user-auth is better than item-1

Be specific in names: “Build Authentication System” is better than “Auth”

Size consistently: Don’t mix days and story points in one project

Review dependencies: Too many dependencies create bottlenecks

Group related work: Use groups for releases, sprints, or phases

Validate with the team: Work item sizes should reflect team consensus

Iterate and refine: Adjust sizes as you learn more about the work

Troubleshooting

Work item not showing in chart?

  • Check that size > 0
  • Verify it’s under a valid workstream
  • Look for YAML syntax errors

Timeline looks wrong?

  • Review dependencies - are they correct?
  • Check work item sizes - are they realistic?
  • Verify workstream capacity matches team size

Too many parallel items?

  • Add dependencies to create sequence
  • Increase work item sizes to slow down work
  • Reduce workstream capacity

Last updated: 2025-12-19