Layer Types Explained

Last Updated: October 10, 2025 Difficulty: Beginner to Intermediate Estimated Reading Time: 11 minutes

Overview

Waymaker provides five distinct layer types—Epic, Sprint, Stage, Milestone, and Custom—each designed to serve specific organizational purposes and align with different project methodologies. Understanding the characteristics, use cases, and best practices for each layer type helps you structure your taskboard to match how your team actually works.

This article provides a comprehensive guide to each layer type, explaining when to use each one, how they map to agile and waterfall methodologies, and how to leverage color coding for visual organization.

What You'll Learn

Detailed explanation of each layer type (Epic, Sprint, Stage, Milestone, Custom)
When to use each layer type for maximum effectiveness
How layer types map to agile and waterfall methodologies
Color coding strategies for visual organization
Typical duration and scope for each layer type
Real-world examples of each layer type in action
How to choose the right layer type for your needs

Prerequisites

Understanding of what layers are (see Introduction to Layers)
Familiarity with creating layers (see Creating and Managing Layers)
Basic knowledge of project management methodologies (agile vs. waterfall)

Epic Layer Type

What Is an Epic?

An Epic is a large body of work that represents a significant feature, initiative, or theme that typically spans multiple iterations or time periods. Epics are too large to complete in a single sprint and must be broken down into smaller, manageable pieces of work.

Characteristics

Size: Large scope requiring weeks to months to complete
Breakdown: Contains multiple sprints, user stories, or tasks
Flexibility: Scope can evolve as understanding improves
Hierarchy: Typically a parent layer with sprint or stage sub-layers
Focus: Business value or user-facing capability

When to Use Epic Layers

Use Epic layers when:

You're managing large features that span multiple sprints
You need to group related user stories or tasks by theme
You're tracking progress toward a major capability or release
You're organizing work by product area or functional domain
You're following agile/scrum methodology

Example Scenarios:

"User Authentication System" (contains login, password reset, OAuth, 2FA)
"Payment Processing" (contains checkout, invoicing, refunds, subscriptions)
"Mobile App Launch" (contains iOS development, Android development, app store submission)
"Dashboard Redesign" (contains analytics, charting, filters, exports)

Typical Duration

Range: 4-12 weeks (one quarter is common)
Flexibility: Duration is estimated, not fixed
Breakdown: Usually contains 2-6 sprints

Epic Best Practices

Naming Conventions:

Use clear, outcome-focused names
✅ "User Authentication System"
✅ "Advanced Reporting Dashboard"
✅ "Multi-language Support"
❌ "Feature A" (not descriptive)
❌ "Big Project" (too vague)

Color Coding:

Suggested Color: Purple (#8B5CF6) or Deep Blue (#1E40AF)
Consistency: Use the same color for all epics
Priority Variation: Consider darker shades for high-priority epics

Organization:

Create sprint sub-layers under each epic
Group related epics under a theme or product area (if using 3-level hierarchy)
Maintain a "Backlog" epic for unassigned user stories

Success Metrics:

Track story points completed vs. estimated
Monitor epic progress (percentage of sub-layers/tasks complete)
Review epic completion rate (how many epics finish on time?)

Epic Example: E-commerce Platform

Epic: Checkout Experience Enhancement
├── Sprint 15: Oct 1-14
│   ├── User Story: Guest checkout flow
│   ├── User Story: Saved payment methods
│   └── User Story: Address autocomplete
├── Sprint 16: Oct 15-28
│   ├── User Story: Order summary redesign
│   ├── User Story: Promotional code application
│   └── User Story: Express checkout (1-click)
└── Sprint 17: Oct 29-Nov 11
    ├── User Story: Checkout analytics
    ├── User Story: A/B testing framework
    └── User Story: Mobile checkout optimization

Epic Goal: Increase checkout conversion rate by 15%

Duration: 6 weeks (3 sprints)

Success Criteria:

Guest checkout available
1-click checkout for returning customers
Mobile conversion improved by 20%
A/B testing operational

Sprint Layer Type

What Is a Sprint?

A Sprint is a time-boxed iteration of work, typically lasting 1-4 weeks (most commonly 2 weeks). Sprints are the heartbeat of agile development, providing regular delivery cycles and predictable planning cadence.

Characteristics

Time-boxed: Fixed start and end dates (non-negotiable)
Goal-oriented: Each sprint has a specific goal or objective
Commitment: Team commits to completing planned work
Review: Ends with demo/review and retrospective
Velocity: Tracked via story points or task completion

When to Use Sprint Layers

Use Sprint layers when:

You're following agile/scrum methodology
You want regular, predictable delivery cycles
You need to track team velocity and capacity
You're planning work in 1-4 week iterations
You want to create focus and limit work-in-progress

Example Scenarios:

"Sprint 10: Oct 1-14" (2-week iteration)
"MVP Sprint 3" (build-to-launch sprint)
"Q4 Sprint 5: Nov 12-25" (quarterly sprint numbering)
"Hardening Sprint" (quality/bug-fix focused sprint)

Typical Duration

Most Common: 2 weeks (10 working days)
Range: 1-4 weeks
Fixed: Duration doesn't change mid-sprint
Consistency: Same duration for all sprints (typically)

Sprint Best Practices

Naming Conventions:

Include sprint number and date range
✅ "Sprint 10: Oct 1-14"
✅ "Sprint 2025-10 (Oct 1-14)"
✅ "Q4 Sprint 3: Oct 1-14"
❌ "Current Sprint" (not specific)
❌ "October Sprint" (too vague if multiple sprints per month)

Color Coding:

Suggested Color: Blue (#3B82F6) or Cyan (#06B6D4)
Consistency: All sprints same color
Active Highlight: Consider brighter shade for current sprint

Organization:

Create sprints as sub-layers under epics (recommended)
OR create sprints as root layers if not using epics
Number sprints sequentially across the project/product
Set exact start and end dates (critical for timeline views)

Sprint Planning:

Pull user stories from epic backlog
Size stories with story points
Don't overcommit—plan for 70-80% of capacity
Set a clear sprint goal

Success Metrics:

Velocity (story points completed per sprint)
Sprint commitment reliability (% of committed work completed)
Burndown/burnup charts
Team satisfaction and predictability

Sprint Example: Product Development

Authentication Epic
├── Sprint 10: Oct 1-14
│   Goal: Core authentication infrastructure
│   Capacity: 40 story points
│   ├── User Story (8 pts): Login UI design and implementation
│   ├── User Story (13 pts): OAuth integration (Google, GitHub)
│   ├── User Story (5 pts): Password validation logic
│   ├── User Story (8 pts): Session management
│   └── User Story (5 pts): Auth unit tests
│   Total Committed: 39 points
│
└── Sprint 11: Oct 15-28
    Goal: Password reset and 2FA
    Capacity: 40 story points
    ├── User Story (8 pts): Password reset flow
    ├── User Story (13 pts): Two-factor authentication
    ├── User Story (5 pts): Email notification templates
    ├── User Story (8 pts): Security audit
    └── User Story (5 pts): Integration tests
    Total Committed: 39 points

Review at Sprint End: Demo completed features, calculate actual velocity, hold retrospective.

Stage Layer Type

What Is a Stage?

A Stage represents a distinct phase of work in a sequential project plan. Stages are typically used in waterfall or phase-gate methodologies where work flows linearly from one stage to the next.

Characteristics

Sequential: Stages typically complete before the next begins
Phase-based: Represents a logical phase of the project
Dependency: Often has dependencies on previous stages
Milestone-gated: May end with approval or gate review
Deliverable-focused: Produces specific outputs

When to Use Stage Layers

Use Stage layers when:

You're following waterfall or traditional project management
Work flows sequentially through defined phases
Each phase has clear deliverables and criteria
You need to track phase completion and gates
Different teams own different stages

Example Scenarios:

"Requirements Gathering" (first stage of discovery)
"Design & Wireframing" (design phase)
"Development & Implementation" (build phase)
"Quality Assurance & Testing" (testing phase)
"Deployment & Launch" (release phase)

Typical Duration

Range: Days to weeks (highly variable)
Fixed Scope: Deliverables defined upfront
Sequential: Starts after previous stage completes
Gate-reviewed: May require approval before next stage

Stage Best Practices

Naming Conventions:

Use clear, descriptive phase names
✅ "Requirements Gathering"
✅ "Visual Design & Mockups"
✅ "User Acceptance Testing"
✅ "Production Deployment"
❌ "Phase 1" (not descriptive)
❌ "Doing Stuff" (too vague)

Color Coding:

Suggested Color: Teal (#14B8A6) or Green (#10B981)
Consistency: Same color for all stages
Status Variation: Consider different shades for completed vs. active vs. upcoming

Organization:

Create stages as sub-layers under phase parent layers
OR create stages as root layers if single-phase project
Order stages chronologically
Include estimated start/end dates

Stage Definition:

Define clear entry criteria (what must be done before stage starts)
Define clear exit criteria (what must be done before stage ends)
Identify deliverables for each stage
Assign stage owner/responsible party

Success Metrics:

Stage completion on time (% on schedule)
Quality of deliverables (defects, rework)
Dependency management (blockers resolved)
Stakeholder approval at stage gates

Stage Example: Website Redesign

Website Redesign Project
├── Phase 1: Discovery (Weeks 1-2)
│   ├── Stage: Stakeholder Interviews
│   │   ├── Task: Schedule interviews
│   │   ├── Task: Conduct CEO interview
│   │   ├── Task: Conduct department head interviews
│   │   └── Task: Compile insights document
│   │   Exit Criteria: All stakeholders interviewed, insights documented
│   │
│   ├── Stage: Competitive Analysis
│   │   ├── Task: Identify top 5 competitors
│   │   ├── Task: Analyze competitor features
│   │   ├── Task: Create comparison matrix
│   │   └── Task: Document opportunities
│   │   Exit Criteria: Analysis complete, recommendations documented
│   │
│   └── Milestone: Requirements Sign-off
│
├── Phase 2: Design (Weeks 3-6)
│   ├── Stage: Information Architecture
│   │   Exit Criteria: Sitemap approved, IA documented
│   ├── Stage: Wireframes
│   │   Exit Criteria: All key pages wireframed, stakeholder approval
│   ├── Stage: Visual Design
│   │   Exit Criteria: Design system created, mockups approved
│   └── Milestone: Design Approval
│
└── Phase 3: Development (Weeks 7-14)
    ├── Stage: Frontend Development
    ├── Stage: Backend Development
    ├── Stage: Integration & Testing
    └── Milestone: Launch Ready

Gate Reviews: Each milestone triggers a go/no-go decision before proceeding to the next phase.

Milestone Layer Type

What Is a Milestone?

A Milestone marks a significant checkpoint, deliverable, decision point, or achievement in your project. Unlike other layer types that contain work, milestones represent a point in time—a finish line to cross.

Characteristics

Point in Time: Represents a specific date, not a duration
Deliverable: Often associated with a key output or approval
Gate: May be a decision point (go/no-go)
Celebration: Marks achievement or completion
External: Often visible to stakeholders or clients

When to Use Milestone Layers

Use Milestone layers when:

You need to mark key deliverables or checkpoints
You have approval gates or phase transitions
You're tracking client deliverables or contract milestones
You need to celebrate team achievements
You're coordinating with external dependencies (launches, events)

Example Scenarios:

"Requirements Sign-off" (approval gate)
"Beta Launch" (product release)
"Design Approval" (stakeholder review)
"Contract Deliverable #3" (client commitment)
"MVP Launch" (significant achievement)

Typical Duration

Point in Time: Single day (or even specific time)
No Duration: Start date = End date
Fixed: Milestone date is a commitment
Deadline: Often a hard deadline

Milestone Best Practices

Naming Conventions:

Use outcome-focused names
✅ "MVP Launch"
✅ "Design Approval"
✅ "Requirements Sign-off"
✅ "Contract Deliverable: Final Report"
❌ "Milestone 1" (not descriptive)
❌ "End of Phase" (vague)

Color Coding:

Suggested Color: Gold (#F59E0B) or Orange (#F97316)
Visibility: Bright, attention-grabbing colors
Importance: Consider red for critical milestones

Organization:

Place milestones at phase boundaries
Associate milestones with the deliverable or gate
Set exact milestone date
Create tasks under milestone for preparation work

Milestone Definition:

Define what must be delivered or decided
Identify who needs to approve or review
Set clear success criteria
Assign milestone owner

Success Metrics:

Milestone hit rate (% achieved on time)
Lead time (how far in advance of deadline completed)
Quality (rework or issues after milestone)

Milestone Example: Product Launch

Product Launch Timeline

Phase 1: Development
├── Sprint 1-3 work
└── Milestone: Feature Complete (Oct 15)
    ├── Task: All features implemented
    ├── Task: Code review complete
    ├── Task: Feature demo to stakeholders
    └── Task: Feature freeze decision

Phase 2: Testing
├── QA and UAT work
└── Milestone: Release Candidate (Oct 29)
    ├── Task: All critical bugs fixed
    ├── Task: Performance benchmarks met
    ├── Task: Security audit complete
    └── Task: Go/No-Go decision

Phase 3: Launch
├── Deployment preparation
├── Milestone: Beta Launch (Nov 8)
│   ├── Task: Deploy to beta environment
│   ├── Task: Notify beta users
│   └── Task: Monitor for issues
└── Milestone: Public Launch (Nov 15)
    ├── Task: Deploy to production
    ├── Task: Press release published
    ├── Task: Marketing campaign activated
    └── Task: Launch party! 🎉

Milestone Tracking: Use Gantt chart view to visualize milestone timeline and dependencies.

Custom Layer Type

What Is a Custom Layer?

A Custom layer is a flexible, general-purpose layer type that doesn't fit the predefined categories. Use custom layers to organize work in ways that make sense for your unique context.

Characteristics

Flexible: No predefined meaning or constraints
Adaptable: Can represent anything you need
Unique: Fits your specific organizational needs
Unrestricted: No assumptions about duration, scope, or methodology

When to Use Custom Layers

Use Custom layers when:

Your organizational need doesn't fit Epic/Sprint/Stage/Milestone
You're using a non-standard methodology
You need to group by dimension other than time or feature
You're experimenting with new organizational structures
Predefined types feel constraining

Example Scenarios:

"Q4 2025 Initiatives" (time-based grouping)
"Backend Team Tasks" (team-based grouping)
"Bug Fixes & Technical Debt" (type-based grouping)
"Client A Projects" (client-based grouping)
"Platform: iOS" (platform-based grouping)

Typical Duration

No Constraints: Whatever makes sense for your use case
Flexibility: Can be ongoing, time-boxed, or event-driven

Custom Layer Best Practices

Naming Conventions:

Be explicit about what the layer represents
✅ "Backend Team: October Work"
✅ "Technical Debt Backlog"
✅ "Client Requests: Acme Corp"
✅ "Platform: Mobile Apps"
❌ "Other" (not helpful)
❌ "Miscellaneous" (too vague)

Color Coding:

Suggested Color: Gray (#6B7280) or custom brand colors
Meaningful: Choose colors that reinforce the category
Consistent: If grouping by team, use team colors

Organization:

Use custom layers for cross-cutting concerns
Can be root layers or sub-layers
May exist alongside methodology-specific layers (epics, sprints)

Documentation:

Add descriptions explaining what the custom layer represents
Document why you're using a custom layer instead of predefined types

Custom Layer Examples

By Team:

Product Development Q4
├── Engineering Team (Custom)
│   ├── Backend development tasks
│   ├── Frontend development tasks
│   └── DevOps tasks
├── Design Team (Custom)
│   ├── UX research
│   ├── Visual design
│   └── Design system updates
└── Marketing Team (Custom)
    ├── Content creation
    ├── Campaign management
    └── Analytics

By Client:

Consulting Projects
├── Client A: Website Redesign (Custom)
│   ├── Discovery tasks
│   ├── Design tasks
│   └── Development tasks
├── Client B: SEO Optimization (Custom)
│   └── SEO tasks
└── Client C: Strategy Engagement (Custom)
    └── Strategy tasks

By Platform:

Mobile App Development
├── iOS Platform (Custom)
│   ├── Sprint 10
│   └── Sprint 11
├── Android Platform (Custom)
│   ├── Sprint 10
│   └── Sprint 11
└── Shared Backend (Custom)
    └── API development tasks

By Type of Work:

Product Backlog
├── Feature Development (Custom - Epic-like)
├── Bug Fixes (Custom)
├── Technical Debt (Custom)
├── Research & Spikes (Custom)
└── Documentation (Custom)

Layer Type and Color Coding

Visual organization through consistent color coding enhances taskboard usability and quick pattern recognition.

Recommended Color Scheme by Type

Layer Type	Suggested Color	Hex Code	Purpose
Epic	Purple	#8B5CF6	Major features stand out
Sprint	Blue	#3B82F6	Time-based iterations clear
Stage	Teal	#14B8A6	Sequential phases visible
Milestone	Gold	#F59E0B	Key checkpoints highlighted
Custom	Gray	#6B7280	Neutral, flexible

Alternative Color Strategies

By Priority:

High Priority: Red (#EF4444)
Medium Priority: Orange (#F97316)
Low Priority: Green (#10B981)

By Status:

Not Started: Gray (#9CA3AF)
In Progress: Blue (#3B82F6)
At Risk: Orange (#F97316)
Complete: Green (#10B981)

By Team/Department:

Engineering: Blue (#3B82F6)
Design: Pink (#EC4899)
Marketing: Orange (#F97316)
Sales: Green (#10B981)
Operations: Teal (#14B8A6)

Brand-Aligned:

Use your organization's brand colors consistently
Map colors to meaningful categories in your context

Color Best Practices

Limit Palette: Use 4-6 colors maximum
Consistency: Same color always means the same thing
Contrast: Ensure colors are distinguishable
Accessibility: Consider colorblind-friendly palettes
Documentation: Document what each color means in your board description

Methodology Mapping: Agile vs. Waterfall Layer Strategies

Different methodologies benefit from different layer type combinations.

Agile/Scrum Mapping

Recommended Structure:

Epic (root) → Sprint (child) → User Story (task)

Layer Types Used:

Epic: Large features or themes
Sprint: Time-boxed iterations (1-4 weeks)
Milestone: Major releases or product launches
Custom: Backlog, technical debt, bug tracking

Example:

Product Development
├── Epic: User Management (Purple)
│   ├── Sprint 10: Oct 1-14 (Blue)
│   └── Sprint 11: Oct 15-28 (Blue)
├── Epic: Reporting Dashboard (Purple)
│   └── Sprint 11: Oct 15-28 (Blue)
├── Custom: Technical Debt Backlog (Gray)
└── Milestone: MVP Launch (Gold)

Waterfall/Traditional PM Mapping

Recommended Structure:

Phase (root) → Stage (child) → Milestone → Task

Layer Types Used:

Stage: Sequential project phases
Milestone: Phase gates and deliverables
Custom: Phase-level groupings
Epic: (Sometimes) Major deliverables

Example:

Website Redesign Project
├── Phase 1: Discovery (Teal - Stage)
│   ├── Stage: Stakeholder Interviews (Teal)
│   ├── Stage: Competitive Analysis (Teal)
│   └── Milestone: Requirements Sign-off (Gold)
├── Phase 2: Design (Teal - Stage)
│   ├── Stage: Information Architecture (Teal)
│   ├── Stage: Wireframes (Teal)
│   ├── Stage: Visual Design (Teal)
│   └── Milestone: Design Approval (Gold)
└── Phase 3: Development (Teal - Stage)
    ├── Stage: Frontend Development (Teal)
    ├── Stage: Backend Development (Teal)
    └── Milestone: Launch Ready (Gold)

Hybrid Methodology Mapping

Scrumban (Scrum + Kanban):

Custom: Continuous Flow (root) → Sprint (optional time-box) → Task

SAFe (Scaled Agile):

Custom: Program Increment → Epic → Sprint → User Story

Wagile (Waterfall + Agile):

Stage: Planning Phase → Epic/Sprint: Development → Stage: Launch

Choosing the Right Layer Type

Use this decision framework to select the appropriate layer type:

Decision Questions

1. Is this a time-boxed iteration?

Yes → Sprint
No → Continue

2. Is this a large feature spanning multiple iterations?

Yes → Epic
No → Continue

3. Is this a sequential phase in a linear plan?

Yes → Stage
No → Continue

4. Is this a specific checkpoint or deliverable date?

Yes → Milestone
No → Continue

5. Does this fit a unique organizational need?

Yes → Custom

Quick Reference Table

Your Need	Best Layer Type	Alternative
2-week agile iteration	Sprint	None
Large feature (multi-sprint)	Epic	Custom
Discovery phase	Stage	Custom
Product launch date	Milestone	None
Team-based grouping	Custom	Epic
Sequential workflow	Stage	Custom
Client deliverable	Milestone	Epic
Technical debt grouping	Custom	Epic
Phase gate review	Milestone	Stage
Platform segmentation (iOS/Android)	Custom	Epic

Tips & Best Practices

Match Methodology: Use Sprint/Epic for agile, Stage/Milestone for waterfall
Consistent Colors: Stick to one color per layer type across all boards
Clear Names: Layer names should be self-explanatory without context
Set Dates: Always include dates for Sprint, Stage, and Milestone types
Limit Types: Don't use all five types in one board unless complexity warrants it
Document Choices: Add descriptions explaining why you chose each layer type
Review Regularly: Ensure layer types still make sense as project evolves
Team Alignment: Make sure everyone understands what each layer type means in your context

Common Mistakes to Avoid

Mixing Methodologies: Using "Sprint" for waterfall phases or "Stage" for agile iterations
Type Confusion: Calling everything "Custom" when Epic or Sprint would be clearer
Color Chaos: Using different colors for the same layer type across boards
Ignoring Type: Choosing types randomly without considering methodology fit
Too Many Types: Using all five types when 2-3 would suffice
Vague Custom: Creating "Custom" layers without clear definition of what they represent
No Dates on Sprints: Sprint layers should always have specific start/end dates
Milestone Spans: Milestones should be a point in time, not a duration

Introduction to Layers - Understand layer concepts and hierarchy
Creating and Managing Layers - Step-by-step layer creation
Using Layers for Agile Projects - Complete agile workflow
Using Layers for Waterfall Projects - Waterfall methodology setup
Layer Best Practices - Advanced organization strategies
Agile/Scrum with Taskboards - Full agile implementation guide
Waterfall with Taskboards - Full waterfall implementation guide

Need More Help?

If you have questions about choosing the right layer types for your project, or need assistance mapping layers to your methodology, please contact support or visit our community forums. Our team can help you design the perfect layer structure for your workflow.

Layer Types Explained

Overview

What You'll Learn

Prerequisites

Epic Layer Type

What Is an Epic?

Characteristics

When to Use Epic Layers

Typical Duration

Epic Best Practices

Epic Example: E-commerce Platform

Sprint Layer Type

What Is a Sprint?

Characteristics

When to Use Sprint Layers

Typical Duration

Sprint Best Practices

Sprint Example: Product Development

Stage Layer Type

What Is a Stage?

Characteristics

When to Use Stage Layers

Typical Duration

Stage Best Practices

Stage Example: Website Redesign

Milestone Layer Type

What Is a Milestone?

Characteristics

When to Use Milestone Layers

Typical Duration

Milestone Best Practices

Milestone Example: Product Launch

Custom Layer Type

What Is a Custom Layer?

Characteristics

When to Use Custom Layers

Typical Duration

Custom Layer Best Practices

Custom Layer Examples

Layer Type and Color Coding

Recommended Color Scheme by Type

Alternative Color Strategies

Color Best Practices

Methodology Mapping: Agile vs. Waterfall Layer Strategies

Agile/Scrum Mapping

Waterfall/Traditional PM Mapping

Hybrid Methodology Mapping

Choosing the Right Layer Type

Decision Questions

Quick Reference Table

Tips & Best Practices

Common Mistakes to Avoid

Related Articles

Need More Help?