Layer Progress Tracking

Difficulty: Beginner

Overview

Understanding progress is fundamental to successful project management. Waymaker's layer progress tracking provides real-time visibility into how your epics, sprints, and project phases are advancing toward completion. Whether you're tracking story points in an agile sprint, monitoring tasks in a waterfall phase, or measuring hours logged against estimates, layer progress metrics give you the insights you need to keep projects on track.

This comprehensive guide covers all aspects of layer progress tracking in Waymaker. You'll learn how progress is calculated, what the different progress indicators mean, how to interpret layer health status, and how to use progress metrics to make informed decisions about your projects.

What You'll Learn

• How progress percentage is calculated for layers
• Understanding visual progress indicators and displays
• Interpreting layer status indicators (on track, at risk, delayed)
• Tracking story points vs task count progress
• Monitoring time-based progress (estimated vs actual hours)
• Defining layer completion criteria
• Understanding progress rollup from sub-layers to parent layers
• Using progress metrics for project planning and reporting

Prerequisites

• Understanding of Waymaker layers (see Introduction to Layers)
• Knowledge of creating layers (see Creating and Managing Layers)
• Basic understanding of task management (see Basic Task Management)
• A taskboard with layers and tasks created

Progress Percentage Calculation

The most fundamental progress metric is the completion percentage, which tells you what portion of a layer's work is complete.

Basic Calculation Method: Task Count

Formula: Progress % = (Completed Tasks / Total Tasks) × 100

Example:

Layer: Sprint 10: Oct 1-14
Total Tasks: 18
Completed Tasks: 15
Progress: (15 / 18) × 100 = 83.3% ≈ 83%

What Counts as Completed:

• Tasks in sections marked as "completion status" (typically "Done" or "Complete")
• Tasks with completion flag checked
• Tasks at 100% progress (if using task-level progress)

What Counts as Total:

• All tasks assigned to the layer
• Includes completed, in-progress, and not-started tasks
• Does NOT include archived tasks (unless specifically included)

Alternative Calculation: Story Points

For agile teams using story points:

Formula: Progress % = (Completed Story Points / Total Story Points) × 100

Example:

Layer: Sprint 10: Oct 1-14
Total Story Points: 40
Completed Story Points: 38
Progress: (38 / 40) × 100 = 95%

Difference from Task Count:

Same Layer:
- Task Count Progress: 15 of 18 tasks = 83%
- Story Points Progress: 38 of 40 points = 95%

Why Different?:

• The 3 incomplete tasks might be small (1-2 points each)
• Most of the effort (story points) is complete
• Story points may be a better indicator of actual progress

Which to Use:

• Task count: Simple, easy to understand, no estimation needed
• Story points: More accurate reflection of effort completed, requires estimation discipline

Time-Based Calculation (Hours)

For teams tracking time:

Formula: Progress % = (Actual Hours Logged / Estimated Hours) × 100

Example:

Layer: Phase 2: Design
Total Estimated Hours: 200 hours
Actual Hours Logged: 150 hours
Progress: (150 / 200) × 100 = 75%

Warning: Time logged can exceed estimate:

Estimated: 200 hours
Logged: 220 hours
Progress: (220 / 200) × 100 = 110%

Interpretation: Phase is taking longer than estimated (potential overrun)

Weighted Calculation (Advanced)

Future Feature: Combine multiple progress factors

Formula: Progress = (Task% × 40%) + (Points% × 40%) + (Time% × 20%)

Example:

Task Progress: 83% × 40% = 33.2%
Story Point Progress: 95% × 40% = 38%
Time Progress: 75% × 20% = 15%
Weighted Progress: 33.2 + 38 + 15 = 86.2%

Benefit: Balanced view incorporating multiple progress dimensions

Sub-Layer Progress Rollup

For layers with sub-layers:

Rollup Method: Average of child layer progress

Example:

Epic: User Authentication (Parent)
├── Sprint 10: Oct 1-14 (95% complete)
├── Sprint 11: Oct 15-28 (40% complete)
└── Sprint 12: Oct 29-Nov 11 (0% complete)

Epic Progress: (95 + 40 + 0) / 3 = 45% complete

Alternative Rollup: Weighted by task count or story points

Epic: User Authentication
├── Sprint 10: 18 tasks, 95% complete → 17.1 tasks done
├── Sprint 11: 16 tasks, 40% complete → 6.4 tasks done
└── Sprint 12: 20 tasks, 0% complete → 0 tasks done
Total: 54 tasks, 23.5 done → 43.5% complete

Which Method: Check your Waymaker settings or documentation for current rollup logic

Visual Progress Indicators

Waymaker uses multiple visual indicators to communicate layer progress at a glance.

Progress Bars

Location: Visible in Layer Manager, layer cards, and filtered board views

Display:

Sprint 10: Oct 1-14
[████████████████████░░░] 83%

Color Coding (Common Pattern):

• Green (0-100%): Healthy progress, on track
• Yellow/Amber (warning): At risk, attention needed
• Red (delayed): Behind schedule, intervention required

Width: Progress bar fills proportionally to percentage

• 0% = Empty bar
• 50% = Half-filled bar
• 100% = Fully filled bar

Percentage Display

Format: Shown alongside progress bar

Examples:

• 83% - Simple percentage
• 15 of 18 tasks (83%) - Detailed count + percentage
• 38/40 pts (95%) - Story points + percentage

Location:

• Layer Manager (next to layer name)
• Taskboard header (when filtered to layer)
• Layer detail panel
• Reports and dashboards

Progress Rings/Circles

Alternative Visualization: Circular progress indicator

Display:

     ╱─────╲
   ╱         ╲
  │   83%     │
   ╲         ╱
     ╲─────╱
  (Green arc showing 83% fill)

Benefits:

• Compact display
• Easy to scan multiple layers
• Works well in layer cards/tiles

Task Count Indicators

Simple Count:

15 / 18 tasks

Detailed Breakdown:

Sprint 10: Oct 1-14
✅ Complete: 15 tasks
🔄 In Progress: 2 tasks
⏸️ Not Started: 1 task
Total: 18 tasks

Visual Checkmark Progress:

✅✅✅✅✅✅✅✅✅✅✅✅✅✅✅ (15 done)
⬜⬜⬜ (3 remaining)

Layer Health Icons

Status Icons (may vary by implementation):

• ✅ On Track: Progress aligns with timeline
• ⚠️ At Risk: Progress lagging, intervention may be needed
• ❌ Delayed: Progress significantly behind, action required
• 🔒 Blocked: Dependencies not met, cannot proceed
• ✔️ Complete: 100% progress achieved

Icon Placement: Next to layer name in Layer Manager and board headers

Layer Status Indicators (On Track, At Risk, Delayed)

Beyond simple percentage, Waymaker can indicate layer health status based on progress vs. time elapsed.

How Status Is Determined

On Track (Green):

• Progress >= Expected progress based on time elapsed
• Example: 50% through sprint timeline, 55% of work complete
• Status: Ahead of schedule ✅

At Risk (Yellow/Amber):

• Progress < Expected progress, but within tolerance (e.g., 10-20% behind)
• Example: 75% through sprint timeline, 60% of work complete
• Status: Behind schedule but recoverable ⚠️

Delayed (Red):

• Progress significantly < Expected progress (e.g., >20% behind)
• Example: 90% through sprint timeline, 50% of work complete
• Status: Unlikely to complete on time ❌

Blocked:

• Progress stalled due to dependencies or external factors
• Example: 3 days with 0% progress increase
• Status: Cannot proceed without resolution 🔒

Expected Progress Formula

Formula: Expected Progress = (Days Elapsed / Total Days) × 100

Example:

Sprint: Oct 1-14 (14 days total)
Today: Oct 8 (7 days elapsed)
Expected Progress: (7 / 14) × 100 = 50%

Actual Progress: 55%
Status: ✅ On Track (5% ahead)

Another Example:

Phase: Design (35 days total)
Elapsed: 28 days (80% of timeline)
Expected Progress: 80%

Actual Progress: 60%
Status: ❌ Delayed (20% behind)

Tolerance Thresholds

Common Thresholds (may vary):

• On Track: Within ±10% of expected
• At Risk: 10-20% behind expected
• Delayed: >20% behind expected

Example Scenarios:

Scenario 1:

• Expected: 50%, Actual: 48% → On Track (within 10%)

Scenario 2:

• Expected: 75%, Actual: 60% → At Risk (15% behind)

Scenario 3:

• Expected: 90%, Actual: 60% → Delayed (30% behind)

Manual Status Override

Use Case: Progress metrics don't tell full story

Example:

Sprint shows 60% complete (on track numerically)
BUT: All remaining tasks are complex and high-risk
Manual Override: Set status to "At Risk"
Reason: Complexity not reflected in simple task count

How to Override (if supported):

1. Open layer settings
2. Find "Status" field
3. Select manual status
4. Add reason/note
5. Save

Best Practice: Document reason for override in layer description

Story Points vs Task Count Progress

Understanding the difference between these two progress metrics helps you choose the right one for your team.

Task Count Progress

What It Measures: Number of tasks completed

Calculation: (Completed Tasks / Total Tasks) × 100

Pros:

• Simple to understand
• No estimation required
• Easy to track (task is done or not done)
• Works for any project type

Cons:

• Treats all tasks as equal (but they're not)
• 10 small tasks ≠ 1 large task
• Can be misleading if tasks vary widely in size
• Doesn't reflect actual effort

Best For:

• Simple projects with similarly-sized tasks
• Teams new to agile
• Non-software projects
• Quick assessments

Example:

Sprint 10:
- 10 small tasks (1 hour each) = 10 tasks
- 2 large tasks (10 hours each) = 2 tasks

If 10 small tasks done, 2 large tasks remain:
Task Count Progress: 10 / 12 = 83%
Actual Work Progress: 10 hours / 30 hours = 33%

Problem: Looks great (83%) but most work remains!

Story Points Progress

What It Measures: Amount of effort/complexity completed

Calculation: (Completed Story Points / Total Story Points) × 100

Pros:

• Reflects actual work completed
• Accounts for task complexity
• Better predictor of sprint completion
• Standard in agile methodologies

Cons:

• Requires estimation (upfront work)
• Team must understand story points
• Estimation accuracy varies
• Requires consistent estimation practice

Best For:

• Agile/Scrum teams
• Software development projects
• Teams with estimation discipline
• Velocity-based planning

Example (Same Scenario):

Sprint 10:
- 10 small tasks (1 point each) = 10 points
- 2 large tasks (10 points each) = 20 points
Total: 30 points

If 10 small tasks done (10 points), 2 large tasks remain (20 points):
Story Point Progress: 10 / 30 = 33%

Accurate: Reflects that 67% of work remains

Combining Both Metrics

Display Both:

Sprint 10: Oct 1-14
Tasks: 10 of 12 complete (83%)
Story Points: 10 of 30 complete (33%)
Status: ⚠️ At Risk (task count misleading)

Interpretation:

• High task completion suggests good progress
• Low story point completion reveals most effort remains
• Status correctly identifies risk

Best Practice: Use story points for planning and reporting, task count for quick team updates

When Metrics Diverge

Large Divergence Indicates:

• Task sizing inconsistency (some very large, some very small)
• Estimation inaccuracy (underestimated or overestimated)
• Team completing easy tasks first (cherry-picking)

Action:

• Review task breakdown (split large tasks)
• Improve estimation practice
• Encourage tackling high-point tasks earlier

Time-Based Progress (Estimated vs Actual Hours)

Time tracking adds another dimension to progress monitoring, showing efficiency and helping predict completion.

Time Progress Calculation

Formula: Time Progress % = (Actual Hours / Estimated Hours) × 100

Example:

Layer: Phase 2: Design
Estimated Hours: 200 hours
Actual Hours Logged: 150 hours
Time Progress: 75%

Time Progress vs Task Progress

Comparison:

Phase 2: Design
Task Progress: 60% (12 of 20 tasks complete)
Time Progress: 75% (150 of 200 hours logged)

Interpretation:

• 60% of tasks complete
• BUT 75% of budgeted time used
• Warning: Trending toward time overrun

Possible Reasons:

• Tasks taking longer than estimated
• Team working inefficiently
• Estimates were too optimistic
• Scope creep (tasks growing in size)

Efficiency Metrics

Efficiency Ratio: Task Progress / Time Progress

Example:

Task Progress: 60%
Time Progress: 75%
Efficiency: 60% / 75% = 0.80 (80%)

Interpretation:

• Efficiency < 1.0: Taking longer than expected (inefficient)
• Efficiency = 1.0: On track (perfect estimate)
• Efficiency > 1.0: Faster than expected (efficient or underestimated)

Healthy Range: 0.90 - 1.10 (within 10% of estimates)

Time Remaining Calculation

Estimate to Complete (ETC):

Estimated Hours: 200
Actual Hours Logged: 150
Hours Remaining: 200 - 150 = 50 hours

But if trending over:

Task Progress: 60%
Time Used: 75%
Projected Total: 200 / 0.60 × 0.75 = 250 hours
Projected Overrun: 250 - 200 = 50 hours over budget

Action: Alert stakeholders, request additional time/budget, or reduce scope

Time Tracking Display

Layer Detail Panel:

Phase 2: Design

Time Tracking:
Estimated: 200 hours
Logged: 150 hours (75%)
Remaining: 50 hours (est.)
Status: ⚠️ At Risk (task progress behind time)

Breakdown:
- Sarah: 60 hours
- Michael: 55 hours
- Emily: 35 hours

Benefits:

• See who's logging time
• Identify if team is tracking time consistently
• Spot individuals over/under logging

Layer Completion Criteria

Not all layers are complete just because progress reaches 100%. Completion criteria define what "done" means.

Defining Completion Criteria

Basic Criterion: All tasks in "Done" section

Enhanced Criteria:

Layer: Sprint 10: Oct 1-14

Completion Criteria:
✅ All committed tasks in "Done" section
✅ All acceptance criteria met for each task
✅ Code reviewed and merged
✅ Tests passing (unit, integration, E2E)
✅ Documentation updated
✅ Sprint demo completed
✅ Sprint retrospective held
✅ Velocity recorded

Where to Define: Layer description field

Definition of Done (DoD)

Concept: Shared understanding of what "complete" means

Sprint DoD Example:

A user story is "Done" when:
- [ ] Code written and reviewed
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] Deployed to staging environment
- [ ] Acceptance criteria validated
- [ ] Documentation updated
- [ ] Product Owner approved

Phase DoD Example:

Design phase is "Done" when:
- [ ] All wireframes approved
- [ ] Visual designs approved
- [ ] Style guide created
- [ ] Design files handed off to development
- [ ] Stakeholder sign-off obtained
- [ ] Design milestone marked complete

Completion Beyond 100%

100% Progress ≠ Automatically Complete

Additional Requirements:

1. Approval: Stakeholder sign-off
2. Quality: All acceptance criteria met
3. Documentation: Artifacts created and stored
4. Handoff: Next phase/team briefed
5. Retrospective: Lessons learned documented

Marking Layer Complete:

1. Verify 100% task/point progress
2. Confirm all completion criteria met
3. Obtain approvals
4. Mark layer as "Complete" (status or flag)
5. Archive layer (future feature)

Incomplete Criteria Warning

Scenario: Sprint shows 100% but criteria not met

Example:

Sprint 10: Oct 1-14
Progress: 100% (18 of 18 tasks complete)
Status: ⚠️ Not Complete

Outstanding:
- Sprint demo not conducted
- 3 tasks missing documentation
- Retrospective not held

Action: Keep sprint status "In Progress" until criteria met, even if tasks are done

Progress Rollup from Sub-layers to Parent Layers

For hierarchical layer structures, understanding how progress rolls up is essential.

Simple Average Rollup

Method: Average child layer progress

Example:

Epic: User Authentication
├── Sprint 10: 95% complete
├── Sprint 11: 40% complete
└── Sprint 12: 0% complete

Epic Progress: (95 + 40 + 0) / 3 = 45%

Pros: Simple, easy to understand Cons: Treats all sprints equally (but they may have different sizes)

Weighted Rollup (Task Count)

Method: Weight by task count

Example:

Epic: User Authentication
├── Sprint 10: 20 tasks, 95% complete → 19 tasks done
├── Sprint 11: 15 tasks, 40% complete → 6 tasks done
└── Sprint 12: 25 tasks, 0% complete → 0 tasks done

Total: 60 tasks, 25 done
Epic Progress: 25 / 60 = 42%

Pros: Accounts for different sprint sizes Cons: Still assumes all tasks equal in effort

Weighted Rollup (Story Points)

Method: Weight by story points

Example:

Epic: User Authentication
├── Sprint 10: 40 points, 95% complete → 38 points done
├── Sprint 11: 40 points, 40% complete → 16 points done
└── Sprint 12: 40 points, 0% complete → 0 points done

Total: 120 points, 54 done
Epic Progress: 54 / 120 = 45%

Pros: Most accurate effort-based progress Cons: Requires consistent story point estimation

Partial Rollup (Completed Children Only)

Alternative Approach: Only completed child layers count

Example:

Epic: User Authentication
├── Sprint 10: 100% complete ✅
├── Sprint 11: 40% complete (in progress)
└── Sprint 12: 0% complete (not started)

Completed Sprints: 1 of 3
Epic Progress: 33% (based on complete sprints only)

Use Case: Conservative estimate (only count done work)

Multi-Level Rollup

Complex Hierarchy:

Epic: User Authentication
├── Feature 1: Login System
│   ├── Sprint 10 (100% complete)
│   └── Sprint 11 (50% complete)
│   Feature 1 Progress: 75%
├── Feature 2: Password Management
│   ├── Sprint 11 (20% complete)
│   └── Sprint 12 (0% complete)
│   Feature 2 Progress: 10%

Epic Progress: (75% × Feature1_weight) + (10% × Feature2_weight)

Complexity: Requires clear rollup rules across multiple levels

Rollup Display

Layer Manager View:

▼ Epic: User Authentication (45%)
  ├─ Sprint 10: Oct 1-14 (95%) ✅
  ├─ Sprint 11: Oct 15-28 (40%) 🔄
  └─ Sprint 12: Oct 29-Nov 11 (0%) ⏸️

Benefit: See epic and sprint progress at a glance

Using Progress Metrics for Planning

Progress metrics aren't just for reporting—they're powerful planning tools.

Velocity-Based Forecasting

Using Story Point Progress:

Epic Remaining: 66 story points
Average Sprint Velocity: 38 points per sprint
Sprints Needed: 66 / 38 = 1.74 ≈ 2 sprints

Estimated Completion: 2 sprints from now

Refining with Actual Progress:

Sprint 11 Actual Progress (Day 7 of 14):
- Expected: 50%
- Actual: 40%
- Adjusted Velocity: 38 × 0.80 = 30 points per sprint
- Sprints Needed: 66 / 30 = 2.2 ≈ 3 sprints

Risk Identification

Progress Pattern Analysis:

Sprint Progress (Daily):
Day 1-3: 0% (normal, planning)
Day 4-7: 10% (slow start)
Day 8-10: 25% (still slow)
Day 11: 35% (accelerating)

Projection: Likely to reach 50-60% by end of sprint (not 100%)
Action: Reduce scope or extend sprint

Resource Allocation

Time Progress vs Task Progress:

Phase 3: Development
Task Progress: 40% (8 of 20 tasks)
Time Progress: 60% (120 of 200 hours)

Analysis: Burning through hours faster than completing tasks
Action: Add developers or reduce scope

Milestone Prediction

Progress Trend:

Phase 2: Design (5 weeks)
Week 1: 15% complete
Week 2: 35% complete (20% gain)
Week 3: 50% complete (15% gain)

Trend: Slowing progress (20% → 15%)
Projected Week 4: 62% (12% gain)
Projected Week 5: 72% (10% gain)

Conclusion: Will not reach 100% by Week 5
Action: Request 1-week extension

Tips & Best Practices

• Choose Right Metric: Use story points for effort-based progress, task count for simple projects
• Set Completion Criteria Early: Define "done" before layer starts, not when it ends
• Monitor Daily: Check progress daily for active layers, weekly for upcoming layers
• Understand Rollup Logic: Know how your tool calculates parent layer progress
• Use Status Indicators: Don't just look at percentage—check health status (on track/at risk/delayed)
• Track Time Optionally: Add time tracking for critical phases or external client projects
• Set Realistic Expectations: Progress is rarely linear; expect variations
• Compare Metrics: When task%, points%, and time% diverge, investigate why
• Document Criteria: Write completion criteria in layer description for shared understanding
• Review Trends: Look at progress over time, not just current snapshot
• Act on At-Risk Status: Don't wait until "Delayed"—intervene when "At Risk"

Common Mistakes to Avoid

• Ignoring Status Indicators: Focusing only on percentage, missing at-risk warnings
• Confusing Progress Types: Mixing up task count vs story points progress
• Cherry-Picking Easy Tasks: Completing many small tasks first, leaving large tasks for end
• Not Tracking Regularly: Only checking progress at end of sprint/phase (too late to adjust)
• Treating 100% as Done: Marking layer complete without verifying completion criteria
• Inconsistent Estimation: Poor story point estimation makes point-based progress unreliable
• Ignoring Time Variance: Not noticing when time used exceeds task progress
• No Baseline: Not recording expected progress to compare against actual
• Overlooking Rollup: Not understanding how child layer progress affects parent
• False Precision: Obsessing over 83% vs 85% when margin of error is ±10%

Related Articles

• Introduction to Layers - Layer fundamentals
• Creating and Managing Layers - Layer setup
• Filtering and Viewing by Layer - Layer filtering for progress views
• Using Layers for Agile Projects - Sprint velocity and burndown
• Using Layers for Waterfall Projects - Phase completion tracking
• Time Tracking and Estimation - Detailed time tracking guide
• Dashboard and Analytics - Progress reporting and charts

Need More Help?

If you have questions about layer progress tracking, interpreting metrics, or setting up completion criteria, please contact support or visit our community forums. Our team can help you implement effective progress tracking for your projects.