> ## Documentation Index
> Fetch the complete documentation index at: https://docs.charle.agency/llms.txt
> Use this file to discover all available pages before exploring further.

# Subtasks

> Working with subtasks and managing delivery work

Subtasks are the individual work items that make up a task. They're assigned to team members, scheduled with dates, and tracked through completion.

## What are subtasks?

Subtasks break down task requirements into actionable work:

* One subtask per work type per requirement
* Assigned to individual team members
* Scheduled with start and end dates
* Tracked through phases
* Linked to time entries

<Info>
  Subtasks are auto-generated when a task is created from a quote. The system creates initial subtasks; fix subtasks are created dynamically when QA fails.
</Info>

## Subtask types

Subtasks are organized by phase:

### Design Phase

* **Design** - Creating visual designs, mockups, prototypes
* **Client Design Feedback** - Incorporating client feedback (created dynamically)

### Development Phase

* **Development** - Writing code, building features
* **Internal QA Fixes** - Fixing issues from internal QA (created dynamically)
* **External QA Fixes** - Fixing issues from client QA (created dynamically)

### QA Phase

* **Internal QA Review** - Team testing the work
* **External QA Review** - Client reviewing the work

### Deployment Phase

* **Deployment** - Deploying to production

## Subtask statuses

Subtasks progress through statuses:

| Status              | Description                         | Available Actions    |
| ------------------- | ----------------------------------- | -------------------- |
| **Not Scheduled**   | Created but no dates assigned       | Schedule             |
| **Scheduled**       | Has assignee and dates, not started | Start                |
| **In Progress**     | Work actively happening             | Complete, Log Time   |
| **Awaiting Review** | Completed, waiting for review       | Review, Approve      |
| **Complete**        | Finished                            | Log Time (if needed) |

## Subtask estimation

### T-shirt sizing

Estimates are based on t-shirt sizes:

| Size | Time Range   | Average   | Use For                   |
| ---- | ------------ | --------- | ------------------------- |
| XS   | 0-30 min     | 15 min    | Tiny fixes, copy changes  |
| S    | 60-120 min   | 90 min    | Small features, bug fixes |
| M    | 3-6 hours    | 4.5 hours | Medium features           |
| L    | 8-16 hours   | 12 hours  | Large features            |
| XL   | 24-40 hours  | 32 hours  | Very large features       |
| XXL  | 40-120 hours | 80 hours  | Epics, complex projects   |

### 80/20 split

Estimates are split between core work and feedback/QA:

* **80%** goes to initial core subtask (e.g., "Development")
* **20%** is the feedback budget, split 50/50 between:
  * Initial QA review subtask (50% of feedback budget)
  * First QA fixes subtask if QA fails (50% of feedback budget)
* XS tasks (≤15 min) have no split - all time goes to core work
* Subsequent QA iterations get 0 min (PM sets manually)

**Example:**

* Requirement: M size Development (270 minutes average)
* Development subtask: 210 minutes (80% core work)
* Initial Internal QA Review: 30 minutes (50% of 60 min feedback budget)
* First Internal QA Fixes (if needed): 30 minutes (50% of 60 min feedback budget)

<Note>
  The feedback budget is split upfront—half for QA review time, half for potential fixes. If QA passes on the first round, the fixes budget isn't used (good for efficiency). If multiple fix rounds are needed, the PM allocates additional time manually.
</Note>

## Scheduling subtasks

### Opening the schedule dialog

Project Managers and CSMs schedule subtasks:

1. Open the task's **Subtasks** tab
2. Click **Schedule** on an unscheduled subtask
3. The scheduling dialog opens with two options:
   * **Block-based scheduling** (recommended)
   * **Direct scheduling**

### Block-based scheduling

When you open the schedule dialog, you'll see available blocks for this client:

<Steps>
  <Step title="Select a block">
    The dialog shows blocks matching the subtask's work type (Design, Development, QA). Each block card shows:

    * Month and year
    * Assigned developer (or "Unassigned")
    * Block type
  </Step>

  <Step title="Block with assignee">
    If the block already has an assigned developer, clicking it:

    * Auto-selects that developer as the assignee
    * Finds their first available date within the block's scheduled date range (e.g. 11th Feb – 2nd Mar)
    * If the developer is fully booked throughout the block period, the block's start date is selected and a capacity warning is shown
    * Shows the timeline panel with their calendar
  </Step>

  <Step title="Block without assignee">
    If the block is unassigned, clicking it:

    * Shows recommended developers for this work type
    * Developers are sorted by availability and current allocation
    * Clicking a developer auto-selects their next available date
  </Step>

  <Step title="Confirm and schedule">
    Review the selected date and timeline, then click **Schedule**
  </Step>
</Steps>

<Tip>
  Block-based scheduling ensures work is scheduled within the client's allocated capacity for that month.
</Tip>

### Direct scheduling

If no blocks exist or you need to schedule outside a block:

1. Click **Schedule directly instead** below the blocks list
2. Select an assignee from the recommendations
3. Choose a start date from the timeline
4. Click **Schedule**

### Phase developer continuity

When scheduling, the system suggests the "phase developer" - the person who completed other work on this task in the same phase. This ensures continuity and context.

<Tip>
  The phase developer recommendation appears at the top of the assignee list with an explanation of why they're recommended.
</Tip>

### End date calculation

End dates are calculated automatically:

* Takes estimated minutes
* Divides by assignee's daily capacity
* Excludes weekends and bank holidays
* Accounts for existing scheduled work
* Rounds up to nearest full day

**Example:**

* Subtask: 390 minutes (6.5 hours)
* Daily capacity: 390 minutes (6.5 hours)
* Start: Monday
* End: Monday (same day)

**Example 2:**

* Subtask: 780 minutes (13 hours)
* Daily capacity: 390 minutes (6.5 hours)
* Start: Monday
* End: Tuesday (2 days)

### Conflict detection and pushing tasks

When scheduling on a date where the developer is already at capacity:

1. **Capacity warning** - An amber warning shows the developer is fully booked
2. **Review Impact** - Click to see which tasks would be pushed to later dates
3. **Push and Schedule** - Confirm to push existing tasks and schedule the new one
4. **Use next available** - Or choose an alternative date with capacity

<Info>
  When you push tasks, their end dates are shifted forward while preserving the work duration. The system recalculates all affected timelines.
</Info>

### Editing scheduled subtasks

To modify an already-scheduled subtask:

1. Click on the scheduled subtask to open the edit dialog
2. The dialog shows:
   * Current assignee and timeline
   * Options to change the date
   * **Reassign to someone else** link
   * **Remove from Schedule** button
3. Make changes and click **Update**

**Reassigning:**

* Click "Reassign to someone else"
* Shows fresh developer recommendations
* Select new assignee and date
* Original developer's schedule updates automatically

**Removing from schedule:**

* Click "Remove from Schedule" in the footer
* Confirms which developer and date will be cleared
* Subtask returns to "Not Scheduled" status

## Working on subtasks

### Starting work

When you're ready to begin:

1. Navigate to your assigned subtask
2. Click **Start**
3. Subtask status changes to "In Progress"
4. Work begins counting against schedule

<Info>
  Use the **Active Tasks** button in the header to view all your in-progress work at a glance.
</Info>

### During work

While working on a subtask:

* **Log time incrementally** - Add time as you work
* **Update handoff info** - Add branch name, preview URL
* **Add notes** - Document progress or blockers

### Theme information (Development only)

For development subtasks, record:

* **Theme name** - Which theme you're working in
* **Theme URL** - Admin or preview URL
* **Theme notes** - Technical details

### Completing subtasks

When work is finished:

<Steps>
  <Step title="Click Complete">
    On the subtask row, click **Complete**
  </Step>

  <Step title="Fill details">
    * **Duration**: Time spent (if not already logged)
    * **Handoff URL**: Design file, staging URL, or preview link
    * **Branch name**: Git branch (for development)
    * **Late reason**: Required if past scheduled end date
  </Step>

  <Step title="Submit">
    Click **Complete Subtask**
  </Step>
</Steps>

**What happens:**

* Subtask marked complete (or awaiting review)
* Time entry created automatically
* Task phase updated if needed
* Notifications sent to reviewers

<Warning>
  If you complete a subtask late (past scheduled end date), you must provide a reason. This helps track scheduling accuracy.
</Warning>

## Logging time on subtasks

### During completion

The easiest way is to log time when completing:

* Enter duration in the completion dialog
* Time entry created automatically
* Always billable (linked to task)

### Separate time entry

You can also log time separately:

1. Click **Log Time** on subtask row
2. Pre-fills: client, task, subtask, activity type
3. Enter: date, duration, notes
4. Submit

<Tip>
  Log time incrementally as you work throughout the day rather than trying to remember at day-end.
</Tip>

### Time tracking

Time logged on subtasks:

* Counts toward task budget
* Used in billing formula
* Tracks actual vs estimated
* Links to specific work

## Handoff information

Different subtask types require different handoff info:

### Design subtasks

* **Handoff URL**: Figma/design file link
* **Notes**: Design decisions, component details

### Development subtasks

* **Branch name**: Git branch for code review
* **Handoff URL**: Preview/staging URL
* **Theme info**: Theme name and URL

### QA subtasks

* **BugHerd points**: Number of issues found (if using BugHerd)
* **Notes**: Testing notes, edge cases found

### Deployment subtasks

* **Handoff URL**: Production URL
* **Notes**: Deployment notes, any issues

## Reviewable subtasks

Some subtasks require review before completion:

* Design
* Client Design Feedback
* Internal QA Review
* External QA Review
* Deployment

**Review workflow:**

1. Assignee completes subtask
2. Status becomes "Awaiting Review"
3. Reviewer approves or requests changes
4. If approved: subtask marked complete
5. If changes: fix subtask created

## QA subtasks

### Internal QA Review

When QA testing internal work:

1. QA person clicks **Complete** on QA subtask
2. Marks as **Passed** or **Failed**
3. **If Passed:**
   * QA subtask marked complete
   * Task moves to External QA (or Deployment)
   * Notifications sent to CSM/PM
4. **If Failed:**
   * Creates "Internal QA Fixes" subtask
   * Auto-assigned to original developer
   * Task returns to Development phase
   * Iteration count increments

<Note>
  The first QA fixes subtask uses half the feedback budget (10% of total). If the task fails QA again, subsequent fix subtasks get 0 min allocation—the PM sets the estimate manually based on the scope of fixes needed.
</Note>

### External QA Review

When client tests work:

1. CSM/PM sends work to client via portal
2. Client reviews and provides feedback
3. **If Approved:**
   * External QA subtask marked complete
   * Task moves to Deployment phase
4. **If Changes Requested:**
   * Creates "External QA Fixes" subtask
   * Auto-assigned to original developer
   * Task returns to Development phase
   * Goes through Internal QA again

## Iterations

Subtasks track iterations for feedback loops:

* **Iteration 1**: Initial work
* **Iteration 2**: First round of fixes
* **Iteration 3+**: Additional fix rounds

**High iteration counts indicate:**

* Unclear requirements
* Communication issues
* Estimation problems
* Scope creep

<Warning>
  Monitor iterations closely. Multiple feedback loops significantly impact budget and timeline.
</Warning>

## Priority and ordering

### Display order

Subtasks can be reordered within each phase:

* PM and CSM can drag-and-drop to reorder
* Determines display sequence
* Helps organize work logically

### Scheduling priority

The scheduling system uses priority to determine order:

* Lower priority number = scheduled first
* Help desk tickets always highest priority
* Affects automated scheduling recommendations

## Subtask permissions

### Who can do what

| Action       | Delivery Team | PM         | CSM        | Manager |
| ------------ | ------------- | ---------- | ---------- | ------- |
| **View**     | Assigned only | All        | All        | All     |
| **Schedule** | ❌ No          | ✅ Yes      | ✅ Yes      | ✅ Yes   |
| **Start**    | ✅ Assignee    | ✅ Yes      | ✅ Yes      | ✅ Yes   |
| **Complete** | ✅ Assignee    | ✅ Override | ✅ Override | ✅ Yes   |
| **Review**   | ❌ No          | ✅ Yes      | ✅ Yes      | ✅ Yes   |
| **Log Time** | ✅ Assignee    | ✅ Override | ✅ Override | ✅ Yes   |

<Note>
  Assignees cannot review their own work. Reviews must be done by someone else (typically PM, CSM, or another team member).
</Note>

## Best practices

<CardGroup cols={2}>
  <Card title="Log time daily" icon="clock">
    Log time as you work or at end of day while it's fresh
  </Card>

  <Card title="Provide handoff info" icon="arrow-right">
    Always include URLs and notes for the next person
  </Card>

  <Card title="Start on time" icon="calendar-check">
    Begin work on scheduled start date to maintain schedule
  </Card>

  <Card title="Communicate delays" icon="message-circle">
    If running late, update PM/CSM immediately
  </Card>

  <Card title="Complete subtasks fully" icon="check-square">
    Don't mark complete if work isn't done - it blocks others
  </Card>

  <Card title="Test before handoff" icon="vial">
    Self-test your work before handing to QA
  </Card>
</CardGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Task Phases" icon="bars-progress" href="/user-guide/tasks/task-phases">
    Understand how subtasks fit into task phases
  </Card>

  <Card title="Reviews & Sign-offs" icon="circle-check" href="/user-guide/tasks/reviews-signoffs">
    Learn the review and approval process
  </Card>

  <Card title="Time Tracking" icon="clock" href="/user-guide/time-tracking">
    Detailed guide to logging time
  </Card>

  <Card title="Schedule" icon="calendar" href="/user-guide/schedule">
    View your scheduled subtasks
  </Card>
</CardGroup>