Subtasks

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

​

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:

​

Subtask estimation

​

T-shirt sizing

Estimates are based on t-shirt sizes:

​

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)

​

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:

​

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.

​

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

​

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

​

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: What happens:

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

​

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

​

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

​

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

​

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

​

Best practices

​

Next steps