Custom Workflow Sections

Waymaker taskboards allow you to create custom workflow sections that match your team's actual process. Move beyond generic "To Do, In Progress, Done" to design workflows that reflect how your team really works.

Understanding Workflow Sections

What Are Sections?

Sections (also called columns or statuses) represent stages in your workflow. Tasks move through sections from left to right as work progresses.

Default Workflow:

To Do → In Progress → Done

Custom Workflow Examples:

Software Development:

Backlog → To Do → In Progress → Code Review → Testing → Done

Design Process:

Ideas → Research → Wireframes → Mockups → Review → Approved → Implemented

Content Creation:

Brainstorm → Outline → Draft → Edit → Review → Published

Sales Pipeline:

Lead → Qualified → Proposal → Negotiation → Closed Won / Closed Lost

Section Properties

Each section has configurable properties:

1. Name (Required):

• Displayed at column top
• Should be action-oriented or state-based
• Examples: "In Review", "Ready for QA", "Deployed"

2. Description (Optional):

• Explains purpose and criteria
• Visible on hover
• Helpful for onboarding

3. Color (Optional):

• Visual differentiation
• Consistent meaning across boards
• Status at a glance

4. WIP Limit (Optional):

• Maximum tasks allowed in section
• Prevents bottlenecks
• Encourages finishing over starting

5. Auto-Assignment Rules (Optional):

• Automatically assign when moved to section
• Example: Assign to QA team when moved to "Testing"

6. Section Type:

• Open: Active work sections
• Closed: Completed work (Done, Cancelled)
• Archived: Hidden from default view

Creating Custom Sections

Adding a New Section

Method 1: Quick Add from Board:

1. Click "+ Add Section" at right of board
2. Enter section name
3. Press Enter
4. Section added to end of workflow

Method 2: Board Settings:

1. Click Board menu → Settings
2. Navigate to "Workflow" tab
3. Click "Add Section"
4. Configure all properties
5. Save changes

Section Configuration Form:

Section Name: Code Review
Description: Tasks awaiting code review approval
Color: Orange (#F59E0B)
WIP Limit: 5
Section Type: Open
Auto-Assignment: @reviewers-team
Position: Between "In Progress" and "Testing"

Editing Sections

Rename Section:

1. Click section header
2. Click edit icon (pencil)
3. Enter new name
4. Press Enter or click Save

Alternative: Board Settings → Workflow → Edit section

Configure Properties:

1. Board Settings → Workflow
2. Find section to edit
3. Click edit icon
4. Update properties
5. Save changes

Reorder Sections:

1. Board Settings → Workflow
2. Drag and drop sections to reorder
3. Save changes
4. Board updates immediately

Delete Section:

1. Board Settings → Workflow
2. Find section to delete
3. Click delete icon
4. Choose what to do with tasks:
   • Move to another section
   • Delete tasks (caution!)
5. Confirm deletion

Common Workflow Patterns

Agile/Scrum Workflow

┌──────────┐   ┌──────┐   ┌────────────┐   ┌──────────┐   ┌────────┐   ┌──────┐
│ Backlog  │ → │ To Do│ → │ In Progress│ → │ Review   │ → │ Testing│ → │ Done │
└──────────┘   └──────┘   └────────────┘   └──────────┘   └────────┘   └──────┘
   (Closed)                                    (WIP: 5)      (WIP: 3)    (Closed)

Section Details:

• Backlog: WIP limit: None, Section type: Closed
• To Do: Current sprint work, WIP limit: 20
• In Progress: Active development, WIP limit: Team size × 2
• Review: Code review stage, WIP limit: 5
• Testing: QA testing, WIP limit: 3
• Done: Completed work, Section type: Closed

When to Use:

• Software development teams
• Iterative product development
• Teams using Scrum methodology

Kanban Workflow

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│ To Do    │ → │ Doing    │ → │ Review   │ → │ Done     │
│ (No WIP) │   │ (WIP: 3) │   │ (WIP: 2) │   │ (No WIP) │
└──────────┘   └──────────┘   └──────────┘   └──────────┘

Principles:

• Visualize workflow
• Limit work-in-progress (WIP)
• Focus on flow, not iterations
• Continuous delivery

WIP Limits:

• To Do: No limit (buffer)
• Doing: Team size
• Review: Team size / 2
• Done: No limit (archive)

When to Use:

• Continuous flow work
• Support and maintenance
• Teams without sprints

Design Workflow

┌──────────┐   ┌──────────┐   ┌───────────┐   ┌──────────┐   ┌───────────┐   ┌──────────┐
│ Ideation │ → │ Research │ → │ Wireframe │ → │ Mockup   │ → │ Review    │ → │ Approved │
└──────────┘   └──────────┘   └───────────┘   └──────────┘   └───────────┘   └──────────┘
                                                                    ↓
                                                            ┌───────────────┐
                                                            │ Needs Revision│
                                                            └───────────────┘
                                                                    ↑
                                                                    └──(loop back to Mockup)

Section Details:

• Ideation: Color: Yellow, brainstorming phase
• Research: Color: Blue, user research and analysis
• Wireframe: Color: Gray, low-fidelity layouts
• Mockup: Color: Purple, high-fidelity designs
• Review: Color: Orange, stakeholder review
• Needs Revision: Color: Red, changes required (loops back)
• Approved: Color: Green, ready for development

When to Use:

• Design teams
• Creative workflows
• Iterative design processes

Content Creation Workflow

┌───────────┐   ┌─────────┐   ┌───────┐   ┌──────┐   ┌──────────┐   ┌───────────┐
│ Brainstorm│ → │ Outline │ → │ Draft │ → │ Edit │ → │ Review   │ → │ Published │
└───────────┘   └─────────┘   └───────┘   └──────┘   └──────────┘   └───────────┘
                                                            ↓
                                                       ┌─────────┐
                                                       │ Revision│
                                                       └─────────┘

Section Details:

• Brainstorm: Ideas and topics
• Outline: Structure and key points
• Draft: First version writing
• Edit: Self-editing and refinement
• Review: Peer or editor review
• Revision: Address feedback
• Published: Live content

When to Use:

• Content marketing teams
• Documentation teams
• Publishing workflows

Support Ticket Workflow

┌──────────┐   ┌─────────────┐   ┌─────────────┐   ┌────────────┐   ┌──────────┐
│ New      │ → │ Investigating│ → │ In Progress │ → │ Waiting   │ → │ Resolved │
└──────────┘   └─────────────┘   └─────────────┘   └────────────┘   └──────────┘
                                                         ↓
                                                 ┌──────────────┐
                                                 │ Customer Info│
                                                 └──────────────┘

Section Details:

• New: Unassigned tickets, Auto-assign to on-call
• Investigating: Diagnosing issue, WIP: 3 per person
• In Progress: Actively working on fix
• Waiting - Customer Info: Awaiting customer response
• Waiting - Internal: Awaiting internal input
• Resolved: Ticket closed, Section type: Closed

When to Use:

• Customer support teams
• IT helpdesk
• Issue tracking

Work-in-Progress (WIP) Limits

Why Use WIP Limits?

Benefits:

• Reduce context switching: Finish tasks before starting new ones
• Identify bottlenecks: When section fills up, investigate why
• Improve flow: Smooth, consistent work progression
• Increase quality: More focus on fewer tasks
• Team collaboration: Encourages helping blocked teammates

Without WIP Limits:

To Do (50 tasks) → In Progress (25 tasks) → Done (5 tasks)
Problem: Too much work started, little completed

With WIP Limits:

To Do (50 tasks) → In Progress (6 tasks, limit: 6) → Done (44 tasks)
Result: Focus on finishing, more completions

Setting WIP Limits

General Guidelines:

For Individual Contributors:

• 1-2 tasks per person maximum
• Example: Team of 4 → WIP limit of 6-8

For Review Stages:

• 50% of team size
• Example: Team of 6 → Review WIP limit of 3

For Testing/QA:

• 25-50% of development WIP
• Example: Dev WIP 8 → QA WIP 3-4

Starting Point:

Section WIP = (Team Size) × (Avg Tasks per Person)

Example:
Team: 5 developers
Avg: 1.5 tasks per person
WIP Limit: 5 × 1.5 = 7-8 tasks

Enforcing WIP Limits

Soft Limit (Warning):

• Visual indicator when limit reached
• Can still add tasks (not blocked)
• Team awareness and self-regulation
• Good for starting out

Hard Limit (Block):

• Cannot add tasks beyond limit
• Must complete or move tasks first
• Strict workflow enforcement
• For mature teams

WIP Limit Indicators:

Section: In Progress (5/8 tasks)
Status: ✅ Within limit

Section: Code Review (5/5 tasks)
Status: ⚠️ At limit (warning color)

Section: Testing (8/5 tasks)
Status: 🚫 Over limit (red, blocked if hard limit)

Responding to WIP Limit Issues

When Section Reaches WIP Limit:

1. Help Teammates: Can you help finish tasks?
2. Identify Blockers: What's preventing progress?
3. Review Priorities: Are we working on right things?
4. Adjust Process: Is limit too low? Process issue?

Common Bottlenecks:

Code Review Section Full:

• Add more reviewers
• Pair programming to reduce review needs
• Asynchronous review process
• Review earlier in process

Testing Section Full:

• Improve test automation
• Add QA capacity
• Shift testing left (earlier)
• Review test case complexity

Section Templates

Creating Reusable Workflow Templates

Save Workflow as Template:

1. Board Settings → Workflow
2. Click "Save as Template"
3. Name template (e.g., "Software Dev Workflow")
4. Choose what to include:
   • Section names
   • Section colors
   • WIP limits
   • Auto-assignment rules
5. Save template

Apply Template to New Board:

1. Create new board
2. Board Settings → Workflow
3. Click "Apply Template"
4. Select template
5. Customize if needed
6. Save

Organization Templates:

• Available across all boards in organization
• Ensures consistency
• Managed by organization admins
• Can be updated centrally

Pre-Built Templates

Basic Kanban:

To Do → In Progress → Done

Scrum Sprint:

Backlog → Sprint Backlog → In Progress → Review → Testing → Done

Bug Tracking:

Reported → Confirmed → In Progress → Fixed → Verification → Closed

Marketing Campaign:

Idea → Planning → Creating → Review → Scheduled → Published → Analyzing

Sales Pipeline:

Lead → Qualified → Meeting → Proposal → Negotiation → Closed Won

Advanced Section Features

Section Dependencies

Sequential Sections:

• Tasks must pass through sections in order
• Cannot skip sections
• Ensures quality gates

Example:

Dev → Code Review → Testing → Done
(Cannot move from Dev directly to Done)

Parallel Sections:

• Tasks can move to multiple sections
• Independent workflows
• Useful for specialization

Example:

             ┌→ Frontend Dev →┐
Design →     │                 ├→ Integration → Testing → Done
             └→ Backend Dev  →┘

Section Automation

Auto-Move Rules:

Rule: Move to Testing when PR merged
Trigger: GitHub PR merged
Action: Move task to "Testing" section

Rule: Move to Done when deployed
Trigger: Deployment completed (webhook)
Action: Move task to "Done" section

Auto-Notify Rules:

Rule: Notify assignee when moved to Review
Trigger: Task moved to "Review" section
Action: Send notification to assignee + @mention reviewer team

Auto-Tag Rules:

Rule: Add "needs-review" tag
Trigger: Task moved to "Code Review" section
Action: Add tag "needs-review"

Section Metrics

Track Section Performance:

Section: Code Review

Current Tasks: 4 tasks
WIP Limit: 5 tasks (80% utilized)

Metrics (Last 30 Days):
- Avg Time in Section: 1.2 days ✅
- Max Time in Section: 3.5 days
- Tasks Completed: 45 tasks
- Bottleneck Score: Low (✅)

Goal: Keep avg time under 1.5 days

Bottleneck Detection:

• Sections consistently at WIP limit
• High average time in section
• Growing queue of tasks entering section
• Low task completion rate

Best Practices

Do's

✅ Start simple - Begin with 3-5 sections, add more as needed ✅ Match your process - Workflow should reflect reality ✅ Use clear names - Section names should be unambiguous ✅ Set WIP limits - Prevent bottlenecks and improve flow ✅ Review regularly - Adjust workflow as team evolves ✅ Involve the team - Co-create workflow with those using it ✅ Monitor metrics - Track section performance ✅ Iterate - Workflow is never "done", continuously improve

Don'ts

❌ Don't over-complicate - More sections ≠ better ❌ Don't copy blindly - Another team's workflow may not fit yours ❌ Don't ignore bottlenecks - Full sections indicate issues ❌ Don't set arbitrary limits - Base WIP limits on data ❌ Don't make it rigid - Allow flexibility when needed ❌ Don't skip "Done" - Celebrate completed work ❌ Don't forget to archive - Completed sections should close

Optimal Section Count

By Team Size:

• Small team (1-3): 3-4 sections
• Medium team (4-8): 4-6 sections
• Large team (9+): 5-8 sections

By Complexity:

• Simple workflows: 3-4 sections
• Standard workflows: 5-6 sections
• Complex workflows: 7-8 sections maximum

Warning Signs of Too Many Sections:

• Team confused about where tasks go
• Tasks moving through 10+ sections
• Sections with 0-1 tasks consistently
• Difficult to see board at a glance

Migrating Existing Workflows

Adding Sections to Existing Board

Process:

1. Identify new section needed
2. Add section via Board Settings
3. Position in workflow
4. Set WIP limit
5. Move relevant tasks to new section
6. Notify team of change

Example: Adding "Code Review" Section:

Before:
To Do → In Progress → Done

After:
To Do → In Progress → Code Review → Done

Migration:
1. Add "Code Review" section between In Progress and Done
2. Move tasks currently in code review to new section
3. Update team workflow documentation
4. Announce in team meeting

Removing Sections

Process:

1. Identify section to remove
2. Check tasks in section
3. Decide destination for tasks:
   • Move to combined section
   • Distribute to other sections
   • Complete if appropriate
4. Delete section
5. Update documentation

Example: Merging "Review" and "Testing":

Before:
In Progress → Review → Testing → Done

After:
In Progress → QA (Review + Testing) → Done

Migration:
1. Create new "QA" section
2. Move all Review and Testing tasks to QA
3. Delete Review and Testing sections
4. Update team process

Conclusion

Custom workflow sections enable:

• Process alignment: Workflow matches how team actually works
• Bottleneck identification: Visual indicators of process issues
• Team clarity: Everyone understands work stages
• Continuous improvement: Evolve workflow as team matures
• Better flow: WIP limits improve task completion rates

Design your workflow collaboratively with your team, start simple, and iterate based on what works.

Related Resources

• Interface Overview - Understanding board layout
• Moving Tasks - Moving tasks between sections
• Board Configuration - Configure board settings
• Measuring Success - Track workflow metrics

---

Last updated: January 10, 2025