Board Organization Strategies

Difficulty: Intermediate

Overview

As your team and projects grow, a critical question emerges: should you create many specialized boards or consolidate work into fewer comprehensive boards? Should you organize by project, by team, by client, or by time period? Poor board organization leads to fragmented workflows, lost tasks, and team confusion.

This guide teaches you strategic approaches to board organization, helps you decide when to create new boards versus using layers within existing boards, establish effective naming conventions, structure workspaces at scale, manage board lifecycles from creation to archival, and implement cross-board navigation patterns that keep your team productive.

What You'll Learn

• One board per project vs one board per team decision framework
• Workspace and folder organization patterns
• Board naming conventions that scale
• When to split boards vs use layers/sections
• Board lifecycle stages (active, maintenance, archive)
• Scaling from 1 to 100+ boards
• Cross-board workflow strategies
• Team-specific organization patterns

Prerequisites

• A Waymaker account with multiple taskboards or planning to scale
• Understanding of board creation (see Creating Your First Taskboard)
• Understanding of layers (see Introduction to Layers)
• Admin or Owner permissions (to create organizational structure)

The Core Question: One Board or Many?

Decision Framework

Before creating a new board, ask these five questions:

1. Do these tasks share the same workflow?

• ✅ Same workflow → Same board (use layers to organize)
• ❌ Different workflows → Separate boards

Example: Marketing tasks (blog, social, ads) share workflow: Draft → Review → Publish. One "Marketing" board with layers.

2. Does the same team own all tasks?

• ✅ Same team → Same board
• ❌ Different teams with different priorities → Separate boards

Example: Engineering and Design have different priorities and meetings. Separate boards even if working on same project.

3. Is this work time-bound (starts and ends)?

• ✅ Time-bound (project, sprint, event) → Separate board or layer
• ❌ Ongoing work → Part of standing board

Example: "Q4 Product Launch" is time-bound → Could be separate board or layer in "Product" board.

4. Will this accumulate >100 tasks?

• ✅ Yes, likely 100+ tasks → Consider separate board
• ❌ No, <50 tasks → Probably a layer in existing board

Example: Large client engagement (200+ tasks) → Separate board. Small client project (30 tasks) → Layer in "Client Work" board.

5. Do stakeholders need isolated access?

• ✅ Yes, guest access for specific project → Separate board (easier permissions)
• ❌ No, same team members → Same board

Example: External client needs to see only their project → Separate board for that client.

Common Organization Patterns

Pattern 1: One Board Per Team (Recommended for Most Teams)

Structure:

• Engineering Board
• Design Board
• Marketing Board
• Sales Board
• Operations Board

Each board contains:

• All that team's work (current and future)
• Layers to organize by project, sprint, or priority
• Sections for team's specific workflow

Pros:

• Clear ownership (one team = one board)
• Team-specific workflows
• Easy standup meetings (one board to review)
• Scales well as team grows

Cons:

• Cross-team projects require coordination across boards
• Hard to see full project view across teams

Best for:

• Teams with distinct workflows
• 5-20 person teams
• Long-term, ongoing work

Example: Engineering Board

Sections: Backlog | Sprint | In Progress | Review | Done
Layers:
├── Mobile App (Epic)
│   ├── Sprint 12
│   └── Sprint 13
├── API Platform (Epic)
│   ├── Sprint 12
│   └── Sprint 13
└── Infrastructure (Epic)
    └── Q4 Improvements

Pattern 2: One Board Per Project

Structure:

• Project A Board
• Project B Board
• Project C Board

Each board contains:

• All work for that project across all teams
• Sections for workflow stages
• Layers by team or feature
• Clear start and end dates

Pros:

• Complete project view in one place
• Cross-functional collaboration
• Easier for project managers
• Clear project boundaries

Cons:

• Team's work fragmented across many project boards
• Hard for team members to see all their tasks
• Duplicated workflows across boards
• Lots of boards if you have many small projects

Best for:

• Project-based work (agencies, consulting)
• Clear project start/end dates
• Cross-functional projects
• External stakeholders (one board per client)

Example: Website Redesign Project Board

Sections: Planning | Design | Development | Testing | Launch
Layers:
├── Design Team Work
├── Frontend Development
├── Backend Development
└── QA Testing

Pattern 3: Hybrid (Team Boards + Project Boards)

Structure:

• Standing team boards for ongoing work
• Temporary project boards for major initiatives
• Clear handoff between them

How it works:

• Daily work happens in team boards
• Major cross-functional projects get dedicated project boards
• When project completes, archive project board and tasks return to team boards

Pros:

• Best of both worlds
• Flexibility for special projects
• Team continuity maintained

Cons:

• More complex
• Needs clear rules about when to create project board
• Can lead to duplicate tasks

Best for:

• Larger organizations (50+ people)
• Mix of ongoing and project-based work
• Mature teams comfortable with complexity

When to create project board:

• Project duration >2 months

• 3 teams involved

• Executive visibility required
• External stakeholder involvement

Pattern 4: One Board Per Time Period (Sprints/Quarters)

Structure:

• Q1 2025 Board
• Q2 2025 Board
• Q3 2025 Board

Each board contains:

• All work planned for that time period
• Archived when period ends
• Historical reference

Pros:

• Clean slate each period
• Historical snapshots
• Easy reporting per period

Cons:

• Ongoing tasks don't fit well
• Frequent board creation
• Hard to track multi-quarter initiatives

Best for:

• Highly seasonal businesses
• Academic/fiscal year cycles
• Teams that prefer clean slates

NOT recommended for:

• Software development (use standing boards with sprint layers instead)
• Ongoing operations

Pattern 5: One Mega Board

Structure:

• Single "Company Work" board
• Hundreds/thousands of tasks
• Layers for everything

Pros:

• Everything in one place
• No decision fatigue about which board

Cons:

• Becomes unwieldy at scale (>200 tasks)
• Slow performance
• Hard to navigate
• Different teams forced into same workflow

Best for:

• Very small teams (2-5 people)
• Simple workflows
• Temporary setups

NOT recommended for:

• Teams >10 people
• Multiple distinct workflows

Board Naming Conventions

Why Naming Conventions Matter

Good naming conventions enable:

• Quick board identification
• Searchability
• Sorting and filtering
• Professional appearance
• Team alignment

Naming Convention Patterns

Pattern 1: Team-Based

[Team Name] - [Sub-category if needed]

Examples:
- Engineering - Backend
- Engineering - Frontend
- Engineering - Infrastructure
- Design - Product
- Design - Marketing
- Marketing - Content
- Marketing - Campaigns

Pattern 2: Project-Based

[Client/Project Name] - [Phase/Type]

Examples:
- Acme Corp - Website Redesign
- Beta Product - Q4 Launch
- Internal Tools - 2025 Upgrade

Pattern 3: Time-Based

[Year] [Quarter/Period] - [Focus Area]

Examples:
- 2025 Q4 - Product Development
- 2025 Q4 - Marketing Initiatives
- October 2025 - Sprint Planning

Pattern 4: Type-Based

[Work Type] - [Team/Subcategory]

Examples:
- Sprints - Engineering
- Client Work - Consulting Team
- Goals - Company-wide
- Meetings - Weekly Team Sync

Naming Best Practices

✅ DO:

• Use consistent format across all boards
• Include team/department name if multi-team organization
• Use date format: YYYY-MM-DD or YYYY-QX
• Keep names under 50 characters
• Use Title Case or sentence case consistently
• Avoid special characters that break search

❌ DON'T:

• Use vague names: "Board 1", "New Board", "Test"
• Mix naming styles: Some with dates, some without
• Use abbreviations teammates won't understand
• Include "(copy)" or "(2)" in name (cleanup duplicates)

Prefixes and Tags

Prefix Strategy:

[STATUS] [TEAM] - [NAME]

Examples:
🔴 ACTIVE Engineering - Current Sprint
🟢 ARCHIVE Marketing - Q3 Campaign
🔵 TEMPLATE Project Kickoff Checklist

Prefix Legend:

• 🔴 ACTIVE: Currently in use
• 🟡 PAUSED: Temporarily on hold
• 🟢 ARCHIVE: Completed, historical reference
• 🔵 TEMPLATE: Reusable template

Workspace and Folder Organization

Workspace Hierarchy

Waymaker Workspaces organize boards into folders:

Organization: Waymaker Inc
├── Workspace: Product Development
│   ├── Engineering Boards
│   ├── Design Boards
│   └── Product Management Boards
├── Workspace: Marketing
│   ├── Content Boards
│   ├── Campaigns Boards
│   └── Social Media Boards
├── Workspace: Client Projects
│   ├── Active Clients
│   ├── Onboarding
│   └── Archived Clients
└── Workspace: Operations
    ├── HR & Recruiting
    ├── Finance
    └── IT & Security

Workspace Strategies

Strategy 1: By Department

• One workspace per major department
• Clear organizational alignment
• Easy permissions (department = workspace access)

Strategy 2: By Function

• Product, Marketing, Sales, Operations
• Cross-departmental work in shared workspace
• Functional clarity

Strategy 3: By Client/Project

• One workspace per major client or program
• Isolated access for external stakeholders
• Easy to archive entire client workspace

Strategy 4: By Work Type

• Active Projects workspace
• Templates workspace
• Archive workspace
• Clear lifecycle organization

Folder Best Practices

Within Each Workspace:

• Active folder: Currently worked boards
• Archive folder: Completed boards (reference only)
• Templates folder: Reusable board templates

Limit Depth:

• Maximum 2-3 levels of folders
• Deeper = harder to navigate

Consistent Structure:

• Apply same folder structure to all workspaces
• Team members know where to look

When to Split Boards vs Use Layers

Use Layers When:

1. Same Workflow, Different Organization

• Engineering team with multiple epics
• Marketing with multiple campaigns
• All follow same process (Backlog → In Progress → Done)

2. Hierarchical Relationship

• Epic → Sprint → Story
• Program → Project → Task
• Clear parent-child relationship

3. Progress Rollup Needed

• Need to see % complete across sub-categories
• Layer progress automatically rolls up

4. Same Team, Different Priorities

• Team has multiple concurrent initiatives
• Use layers to organize, not separate boards

Example: Engineering team with 5 epics

• Don't: Create 5 separate boards
• Do: One Engineering board with 5 Epic layers

Use Separate Boards When:

1. Different Workflows

• Engineering (Backlog → Sprint → Done)
• Marketing (Draft → Review → Publish → Analytics)
• Can't share same sections

2. Different Teams with Different Cadences

• Engineering (2-week sprints)
• Marketing (monthly campaigns)
• Operations (ongoing tasks)
• Each needs their own rhythm

3. Permissions Differ

• External client access to their project only
• Easier with separate board than complex layer permissions

4. >100 Tasks Expected

• Large initiatives become unwieldy in single board
• Better performance with separate boards

5. Clear Start/End

• Event planning (start 3 months before, end 1 week after)
• Temporary projects
• Easier to archive entire board when done

Scaling from 1 to 100+ Boards

Phase 1: Getting Started (1-5 Boards)

Typical Setup:

• Personal "My Tasks" board
• Team board
• Maybe one project board

Organization:

• No formal structure needed
• Flat list of boards works fine

Focus:

• Learning taskboard features
• Establishing team workflows

Phase 2: Growing Team (6-20 Boards)

Typical Setup:

• Multiple team boards
• A few project boards
• Templates emerging

Organization:

• Start using workspaces
• Create "Active" vs "Archive" folders
• Establish naming conventions

Focus:

• Standardizing workflows
• Creating first templates
• Basic archival process

Phase 3: Multi-Team Organization (21-50 Boards)

Typical Setup:

• Board per team
• Boards per major project
• Template library
• Cross-team collaboration boards

Organization:

• Workspace per department
• Clear folder structure
• Naming convention enforced
• Archive old boards quarterly

Focus:

• Cross-board workflows
• Reporting across boards
• Template governance

Phase 4: Enterprise (50+ Boards)

Typical Setup:

• 50-200+ boards
• Multiple workspaces
• Dedicated board admins
• Automated archival

Organization:

• Formal workspace strategy
• Board lifecycle management
• Template standards
• Board approval process

Focus:

• Governance and compliance
• Performance optimization
• Board discovery and search
• Automated cleanup

Board Lifecycle Management

Lifecycle Stages

1. Creation

• New board created from scratch or template
• Initial setup and configuration
• Team members added

2. Active Use

• Daily work happening
• Tasks being created and completed
• Primary focus

3. Maintenance

• Project wrapping up or on hold
• Occasional updates
• Monitoring only

4. Archive

• Work completed
• Historical reference only
• Read-only

5. Deletion

• No longer needed
• Truly obsolete
• Permanent removal

Active Board Management

Keep boards active by:

• Regular cleanup (weekly)
• Archiving completed tasks
• Pruning outdated tasks
• Updating board description

Red flags (board needs attention):

• No activity in 30 days

• 500 tasks

• 100 unassigned tasks

• Board name still "New Board" or "Test"

Archiving Boards

When to Archive:

• Project completed
• Quarter/sprint ended (if using time-based boards)
• Team disbanded
• Client engagement ended

How to Archive:

1. Mark all tasks complete or move to "Done"
2. Export board as backup (CSV)
3. Update board name: Add "[ARCHIVE]" prefix
4. Move to "Archive" workspace or folder
5. Remove active members (leave as reference only)

See: Archiving and Cleanup for detailed process.

Cross-Board Workflows

Linking Related Boards

Board Relationships:

• Parent-child (Program board → Project boards)
• Sequential (Design board → Development board)
• Parallel (Multiple team boards for same initiative)

How to Link:

• Add board links in board description
• Create "Related Boards" custom field
• Use task descriptions to reference other boards
• Maintain master list in wiki/docs

Managing Work Across Multiple Boards

Challenge: Task needs input from multiple teams on different boards.

Solutions:

Option 1: Duplicate Task (Not Recommended)

• Create task on each team's board
• Keep in sync manually
• Prone to errors

Option 2: Primary Board + References

• Task lives on one "owner" board
• Other boards have task with link to primary
• Example: "See Engineering Board task #123"

Option 3: Cross-Board Dependencies (Future Feature)

• Task on Board A depends on task on Board B
• Dependency tracking across boards
• Check if Waymaker supports this

Option 4: Integration Hub Board

• Create special "Cross-Team" board
• Tasks requiring multiple teams go here
• Teams pull work from hub as needed

Troubleshooting

"We have too many boards and can't find anything"

Solution:

1. Audit all boards: List every board, last activity date
2. Archive inactive boards (no activity >90 days)
3. Consolidate similar boards (combine if possible)
4. Establish naming convention
5. Organize into workspaces/folders
6. Create board directory document

"Team members don't know which board to use"

Solution:

1. Create clear decision tree: "Use Board X for Y work type"
2. Document in wiki or team handbook
3. Add board descriptions explaining purpose
4. Limit board creation permissions (only admins)
5. Regular onboarding for new team members

"Our board structure keeps changing"

Solution:

1. Normal in first 3-6 months (experimentation phase)
2. Stabilize on one pattern after trial period
3. Document chosen pattern
4. Resist frequent reorganizations (disruptive)
5. Make changes quarterly, not weekly

Common Mistakes to Avoid

❌ Mistake 1: Creating a new board for every small project

Problem: 50 boards for tiny 5-task projects. Board sprawl.

Solution: Use layers in a standing board for small projects. Only create separate board if >50 tasks expected or external access needed.

❌ Mistake 2: Never archiving old boards

Problem: Active workspace cluttered with 100 boards, most inactive

Solution: Quarterly cleanup. Archive boards with no activity in 90 days. Move to "Archive" workspace.

❌ Mistake 3: No naming convention

Problem: Boards named "Board 1", "New Board (copy)", "Test", "asdf"

Solution: Establish and enforce naming convention. Rename all existing boards. Document pattern for new boards.

❌ Mistake 4: Creating duplicate boards instead of using templates

Problem: Manually recreating same structure 10 times

Solution: Create template after second time you need same structure. Use template for all future instances.

Quick Reference

Decision Framework:

• Same workflow + team → Same board, use layers
• Different workflows or teams → Separate boards
• Time-bound work → Separate board or layer

• 100 tasks expected → Consider separate board

• Guest access needed → Separate board (easier permissions)

Common Patterns:

• One board per team (most common)
• One board per project (consulting/agency)
• Hybrid (team + project boards)

Naming Convention:

[Team/Project Name] - [Sub-category]
Example: Engineering - Backend

Lifecycle: Creation → Active → Maintenance → Archive → Delete

When to Split vs Layer:

• Same process = Layer
• Different process = Separate board

---

Related Articles

• Creating Your First Taskboard - Board creation basics
• Board Templates and Reusability - Template strategy
• Archiving and Cleanup - Board lifecycle management
• Introduction to Layers - Using layers for organization
• Layer Best Practices - Advanced layer strategies

Next Steps

You now understand strategic board organization! Ready to continue?

1. Archiving and Cleanup - Manage completed boards
2. Using Layers for Agile Projects - Organize work within boards
3. Team Collaboration - Multi-board team workflows

---

Ready for next topic? → Archiving and Cleanup