Layer Types Explained

Difficulty: Beginner to Intermediate

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

Related Articles

• 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.