Measuring Success with Taskboards

What gets measured gets improved. Effective taskboard metrics provide visibility into team performance, identify bottlenecks, and enable data-driven decisions that improve delivery velocity and quality.

Why Metrics Matter

Without measurement, teams operate blind:

No Visibility: Unable to see actual productivity vs. perceived productivity
Hidden Bottlenecks: Problems remain invisible until they become crises
Subjective Decisions: Choices based on opinions rather than data
Unpredictable Delivery: Unable to forecast completion dates reliably
Missed Improvements: No baseline to measure improvement against

With the right metrics, teams gain:

Objective Performance Data: Clear view of actual team capacity and output
Early Warning Signals: Identify problems before they impact delivery
Predictable Delivery: Accurate forecasting based on historical data
Continuous Improvement: Data-driven insights for process optimization
Team Health Visibility: Early detection of burnout, blockers, and dysfunction

The Metrics Framework

Waymaker's taskboard metrics framework covers four key dimensions:

Flow Metrics: How work moves through your system
Quality Metrics: How well work is done
Team Health Metrics: How your team is doing
Business Metrics: Impact on business outcomes

Choosing the Right Metrics

Principles for Metric Selection:

✅ Actionable: Can you take action based on the metric? ✅ Leading Indicators: Predict future outcomes, not just report history ✅ Team-Owned: Team can influence the metric through their actions ✅ Simple: Easy to measure and understand ✅ Balanced: Cover different aspects of performance

❌ Vanity Metrics: Look good but don't drive behavior ❌ Lagging Only: Report history without predictive value ❌ Externally Driven: Team cannot influence through their work ❌ Over-Complex: Difficult to measure or interpret ❌ Single-Dimensional: Only measure one aspect of performance

Flow Metrics

Flow metrics measure how efficiently work moves through your system.

1. Velocity

Definition: Amount of work completed in a time period

Measurement:

Count of tasks completed per sprint/week
Story points completed per sprint (if using estimation)
Task count by size (small, medium, large)

Waymaker Implementation:

Navigate to Board → Analytics → Flow Metrics
- View: Tasks completed by week/sprint
- Filter: By layer, assignee, or task type
- Export: Download CSV for analysis

Interpretation:

Good Velocity Indicators:

Consistent week-over-week (±15% variance)
Gradual increase over time as team improves
Predictable sprint-to-sprint

Concerning Patterns:

High variability (>30% variance week-to-week)
Declining trend over multiple sprints
Sudden spikes followed by crashes

Example Velocity Dashboard:

Sprint Velocity (Last 6 Sprints)
Sprint 1: 23 tasks
Sprint 2: 21 tasks
Sprint 3: 25 tasks
Sprint 4: 22 tasks
Sprint 5: 24 tasks
Sprint 6: 23 tasks

Average: 23 tasks/sprint
Variance: ±8.7%
Trend: Stable

Improving Velocity:

Break large tasks into smaller, consistent sizes
Reduce work-in-progress (WIP) limits
Eliminate blockers and dependencies
Improve task estimation accuracy
Reduce context switching

2. Cycle Time

Definition: Time from when work starts until it's completed

Measurement:

Task moved to "In Progress" → Task moved to "Done"
Exclude time in "To Do" (that's lead time)
Track median and 85th percentile

Waymaker Implementation:

Board → Analytics → Cycle Time
- View: Distribution chart and percentiles
- Filters: By task size, assignee, layer
- Breakdown: By workflow stage

Interpretation:

Healthy Cycle Time:

Median: 2-3 days for standard tasks
85th percentile: Under 5 days
Consistent across similar task types
Decreasing trend over time

Warning Signs:

Median > 5 days for standard tasks
85th percentile > 10 days
High variance (some tasks fast, others very slow)
Increasing trend over time

Example Cycle Time Report:

Cycle Time Analysis (Last 30 Days)

Small Tasks:
- Median: 1.2 days
- 85th %ile: 2.5 days
- Count: 45 tasks

Medium Tasks:
- Median: 3.1 days
- 85th %ile: 5.8 days
- Count: 32 tasks

Large Tasks:
- Median: 7.2 days
- 85th %ile: 11.3 days
- Count: 12 tasks

Recommendation: Large tasks exceed target, consider decomposition

Improving Cycle Time:

Reduce task size (aim for <3 day completion)
Minimize work-in-progress per person
Reduce handoffs and dependencies
Eliminate blockers quickly
Improve code review turnaround

3. Throughput

Definition: Number of tasks completed in a time period

Measurement:

Tasks completed per day/week/sprint
Stable rolling average (e.g., 7-day, 30-day)
Trend over time

Waymaker Implementation:

Board → Analytics → Throughput
- View: Tasks completed per day/week
- Rolling averages: 7-day, 30-day
- Comparison: Current vs. previous period

Interpretation:

Strong Throughput:

Consistent daily/weekly completion
Upward trend as team matures
Matches or exceeds planning assumptions

Concerning Patterns:

Highly variable day-to-day
Downward trend
Batch completion (nothing for days, then many at once)

Example Throughput Dashboard:

Throughput Metrics

Current Week: 28 tasks
Last Week: 26 tasks
4-Week Average: 25 tasks/week

Daily Throughput:
Mon: 4 tasks
Tue: 6 tasks
Wed: 5 tasks
Thu: 7 tasks
Fri: 6 tasks

Status: ✅ Above average, healthy daily distribution

Improving Throughput:

Reduce batch size (smaller tasks)
Limit work-in-progress
Remove bottlenecks in workflow
Parallelize independent work
Reduce rework through quality practices

4. Work-in-Progress (WIP)

Definition: Number of tasks actively being worked on

Measurement:

Count of tasks in "In Progress" status
WIP per team member
WIP by workflow stage

Waymaker Implementation:

Board → Analytics → Work in Progress
- View: Current WIP count
- Breakdown: By assignee, by stage
- Historical: WIP trends over time

Interpretation:

Healthy WIP:

1-2 tasks per person maximum
Consistent across team members
Low variance day-to-day

Warning Signs:

3 tasks per person
Uneven distribution (some with 5+, others with 0)
Increasing WIP trend without increasing throughput

Example WIP Report:

Current Work-in-Progress

Team Total: 12 tasks (6 people = 2.0 avg)

By Person:
- Alice: 2 tasks ✅
- Bob: 3 tasks ⚠️
- Carol: 2 tasks ✅
- David: 1 task ✅
- Emma: 2 tasks ✅
- Frank: 2 tasks ✅

Recommendation: Review Bob's workload, consider rebalancing

Improving WIP Management:

Set explicit WIP limits (e.g., max 2 per person)
Finish tasks before starting new ones
Make blockers highly visible
Encourage pair/mob programming on stuck tasks
Review WIP daily in standups

5. Lead Time

Definition: Time from task creation to completion

Measurement:

Task created → Task completed
Includes time waiting in backlog
Track median and percentiles

Waymaker Implementation:

Board → Analytics → Lead Time
- View: Full cycle from creation to done
- Breakdown: Time in each status
- Filter: By priority, layer, assignee

Interpretation:

Acceptable Lead Time:

Median: 5-7 days for medium priority
High priority: <3 days
Low priority: Can be longer (30+ days acceptable)

Issues:

Long time in "To Do" before starting
Work starting too early (pulled in prematurely)
Inconsistent lead time for similar tasks

Example Lead Time Analysis:

Lead Time Breakdown (Median)

High Priority Tasks:
- Time in To Do: 0.5 days
- Time in Progress: 2.1 days
- Time in Review: 0.4 days
- Total Lead Time: 3.0 days ✅

Medium Priority Tasks:
- Time in To Do: 2.3 days
- Time in Progress: 3.2 days
- Time in Review: 0.8 days
- Total Lead Time: 6.3 days ✅

Low Priority Tasks:
- Time in To Do: 12.5 days ⚠️
- Time in Progress: 2.8 days
- Time in Review: 0.5 days
- Total Lead Time: 15.8 days

Insight: Low priority tasks wait too long, consider backlog grooming

Quality Metrics

Quality metrics measure how well work is done.

1. Defect Rate

Definition: Percentage of completed tasks with defects

Measurement:

Bug tasks / Total completed tasks
Defects found in review vs. production
Defect density (bugs per feature area)

Waymaker Implementation:

Board → Analytics → Quality Metrics
- Tag bug tasks with "bug" label
- Track: Bugs created / Total tasks completed
- Trend: Week-over-week defect rate

Interpretation:

Healthy Defect Rate:

<10% of completed tasks result in bugs
80% of defects caught before production
Decreasing trend over time

Concerning Patterns:

20% defect rate
Increasing defects in production
Repeat defects in same areas

Example Defect Report:

Defect Rate Analysis (Last Sprint)

Tasks Completed: 45
Bugs Found: 4
Defect Rate: 8.9% ✅

Defect Discovery:
- In Review: 3 bugs (75%) ✅
- In QA: 1 bug (25%)
- In Production: 0 bugs (0%) ✅

Top Defect Areas:
1. User authentication (2 bugs)
2. Form validation (2 bugs)

Action: Add automated tests for auth and validation

Improving Quality:

Implement code review checklist
Increase automated test coverage
Conduct exploratory testing
Root cause analysis on defects
Pair programming on complex work

2. Rework Rate

Definition: Percentage of tasks requiring additional work after "completion"

Measurement:

Tasks reopened after being marked done
Tasks requiring significant changes in review
Time spent on rework vs. new work

Waymaker Implementation:

Track tasks that move from "Done" back to "In Progress"
- Board → Analytics → Rework
- Count: Tasks reopened
- Time: Hours spent on rework

Interpretation:

Acceptable Rework:

<5% of tasks require reopening
Rework caught in review, not production
Rework time <10% of total development time

Warning Signs:

10% of tasks reopened
Frequent rework in production
Rework time >20% of capacity

Example Rework Report:

Rework Analysis (Last Month)

Tasks Completed: 180
Tasks Reopened: 8
Rework Rate: 4.4% ✅

Reasons for Rework:
- Requirements changed: 3 tasks
- Missed edge case: 2 tasks
- Failed QA: 2 tasks
- Production issue: 1 task

Time Impact:
- Total dev time: 720 hours
- Rework time: 45 hours (6.3%) ✅

Action: Improve requirements review process

3. Review Cycle Time

Definition: Time from submitting work for review to approval

Measurement:

Task moved to "In Review" → Approved
Number of review rounds
Review turnaround time

Waymaker Implementation:

Board → Analytics → Review Metrics
- Time in "In Review" status
- Count: Number of times task bounced back
- Assignee: Review bottlenecks by reviewer

Interpretation:

Efficient Reviews:

Median review time: <4 hours
Single round approval: >70% of tasks
Even distribution across reviewers

Bottlenecks:

Review time >24 hours
Multiple review rounds (>2)
Reviews concentrated on one person

Example Review Report:

Code Review Metrics (Last 2 Weeks)

Total Reviews: 56
Median Review Time: 3.2 hours ✅

Review Rounds:
- 1 round: 42 tasks (75%) ✅
- 2 rounds: 12 tasks (21%)
- 3+ rounds: 2 tasks (4%)

Review Distribution:
- Alice: 18 reviews (avg 2.8 hrs) ✅
- Bob: 22 reviews (avg 5.1 hrs) ⚠️
- Carol: 16 reviews (avg 2.5 hrs) ✅

Action: Investigate Bob's longer review times

Team Health Metrics

Team health metrics measure how your team is doing.

1. Team Satisfaction

Definition: How team members feel about work and processes

Measurement:

Weekly team mood survey (1-5 scale)
Retrospective feedback themes
Voluntary turnover rate

Waymaker Implementation:

Create recurring task: Weekly Team Pulse
- Poll in comments: "How was your week? (1-5)"
- Track average score over time
- Note themes in comments

Interpretation:

Healthy Team:

Average satisfaction: >3.5/5
Stable or improving trend
Low variance (team aligned)

Warning Signs:

Average <3.0/5
Declining trend
High variance (team misaligned)

Example Team Health Report:

Team Satisfaction (Last 4 Weeks)

Week 1: 3.8/5 (6 responses)
Week 2: 4.1/5 (6 responses)
Week 3: 3.9/5 (5 responses)
Week 4: 4.2/5 (6 responses)

Average: 4.0/5 ✅
Trend: Improving ✅

Common Themes:
- ✅ Good collaboration and support
- ✅ Clear priorities and goals
- ⚠️ Some meetings could be async

Action: Evaluate meeting structure

2. Workload Balance

Definition: Distribution of work across team members

Measurement:

Tasks per person per sprint
Task completion rate by person
WIP distribution

Waymaker Implementation:

Board → Analytics → Team Workload
- View: Tasks assigned by person
- Completed: Completion rate by person
- Capacity: Utilization percentage

Interpretation:

Balanced Team:

Even distribution (±20% variance)
Similar completion rates
No persistent over/under-utilization

Imbalance Signals:

50% variance in workload
Consistently overloaded individuals
Consistently idle individuals

Example Workload Report:

Workload Distribution (Current Sprint)

Team Average: 8 tasks per person

Individual Allocation:
- Alice: 8 tasks (100%) ✅
- Bob: 12 tasks (150%) ⚠️
- Carol: 7 tasks (88%) ✅
- David: 9 tasks (113%) ✅
- Emma: 6 tasks (75%) ⚠️
- Frank: 8 tasks (100%) ✅

Completion Rate:
- Alice: 87% (7/8 completed) ✅
- Bob: 58% (7/12 completed) ⚠️
- Carol: 100% (7/7 completed) ✅

Action: Rebalance Bob's workload, investigate Emma's capacity

3. Blocker Frequency

Definition: How often team members are blocked

Measurement:

Number of tasks marked "Blocked"
Time in blocked state
Blocker categories and causes

Waymaker Implementation:

Use "Blocked" tag on tasks
- Board → Analytics → Blockers
- Count: Active blockers
- Time: Average time blocked
- Categories: Group by blocker type

Interpretation:

Healthy State:

<10% of active tasks blocked
Average blocked time <1 day
Blockers resolved within sprint

Warning Signs:

20% of tasks blocked
Blockers lasting >3 days
Recurring blocker types

Example Blocker Report:

Blocker Analysis (Last Month)

Total Tasks: 180
Blocked Tasks: 12 (6.7%) ✅

Blocker Duration:
- <1 day: 8 blockers (67%)
- 1-3 days: 3 blockers (25%)
- >3 days: 1 blocker (8%)

Blocker Types:
1. Waiting on external team: 5 blockers
2. Technical dependency: 4 blockers
3. Missing requirements: 2 blockers
4. Infrastructure issue: 1 blocker

Action: Create SLA with external team

4. Meeting Load

Definition: Time spent in meetings vs. focus work

Measurement:

Meeting hours per person per week
Percentage of work week in meetings
Deep work blocks available

Waymaker Implementation:

Create task type: "Meeting"
- Track meeting tasks with time estimates
- Board → Analytics → Time Allocation
- Compare: Meeting time vs. delivery time

Interpretation:

Healthy Balance:

<30% of work week in meetings
Multiple 2+ hour focus blocks daily
Meeting time stable or decreasing

Warning Signs:

40% of time in meetings
No focus blocks >1 hour
Increasing meeting time trend

Example Meeting Load Report:

Meeting Analysis (Per Person Per Week)

Team Average: 12 hours (30% of 40-hour week) ✅

Individual Breakdown:
- Alice (IC): 8 hours (20%) ✅
- Bob (Lead): 18 hours (45%) ⚠️
- Carol (IC): 10 hours (25%) ✅
- David (IC): 9 hours (23%) ✅
- Emma (IC): 11 hours (28%) ✅
- Frank (IC): 16 hours (40%) ⚠️

Focus Time Available:
- Average: 4.2 hrs/day ✅
- Longest block: 2.8 hrs ⚠️

Action: Consolidate meetings, protect focus time

Business Metrics

Business metrics connect team performance to business outcomes.

1. Delivery Predictability

Definition: Ability to deliver on commitments

Measurement:

Sprint commitments met (%)
Forecast accuracy for release dates
Variance in delivery estimates

Waymaker Implementation:

Track sprint goals and actuals
- Board → Analytics → Predictability
- Committed: Planned tasks
- Delivered: Completed tasks
- Variance: Difference analysis

Interpretation:

Predictable Delivery:

80% of sprint commitments met
Release date variance <1 week
Improving forecast accuracy

Unpredictable Patterns:

<60% of commitments met
Frequent deadline misses
Large variance in estimates

Example Predictability Report:

Delivery Predictability (Last 6 Sprints)

Sprint 1: 23 planned / 21 delivered (91%) ✅
Sprint 2: 25 planned / 20 delivered (80%) ✅
Sprint 3: 22 planned / 22 delivered (100%) ✅
Sprint 4: 24 planned / 18 delivered (75%) ⚠️
Sprint 5: 23 planned / 23 delivered (100%) ✅
Sprint 6: 25 planned / 24 delivered (96%) ✅

Average: 90% commitment success ✅
Trend: Improving after Sprint 4 dip

Root Cause (Sprint 4): Underestimated technical complexity
Action: Improved estimation calibration

2. Value Delivered

Definition: Business value of completed work

Measurement:

User-facing features shipped
Customer impact metrics
Revenue or cost impact

Waymaker Implementation:

Tag tasks with value labels
- Board → Analytics → Value Metrics
- High Value / Medium Value / Low Value
- Business outcome tracking

Interpretation:

High-Value Focus:

60% of effort on high-value work
Regular high-value feature releases
Clear business outcome connection

Warning Signs:

<40% of effort on high-value work
Mostly low-value or tech debt
No clear business outcome tracking

Example Value Report:

Value Distribution (Last Quarter)

Total Tasks: 540
High Value: 180 tasks (33%)
Medium Value: 270 tasks (50%)
Low Value: 90 tasks (17%)

Effort Allocation (estimated hours):
High Value: 1,080 hrs (60%) ✅
Medium Value: 540 hrs (30%)
Low Value: 180 hrs (10%)

Business Outcomes:
- User activation: +23%
- Conversion rate: +8%
- Support tickets: -15%

Status: ✅ Balanced focus, strong business impact

3. Time-to-Market

Definition: Time from idea to production

Measurement:

Feature inception to launch
Time in each development phase
Iteration speed

Waymaker Implementation:

Track layers as feature lifecycles
- Board → Analytics → Time to Market
- Layer created → Layer completed
- Phases: Discovery, Design, Dev, QA, Launch

Interpretation:

Fast Time-to-Market:

Small features: <2 weeks
Medium features: 4-6 weeks
Large features: 8-12 weeks

Slow Delivery:

Small features: >4 weeks
Excessive time in single phase
Long gaps between phases

Example Time-to-Market Report:

Feature: User Dashboard Redesign

Timeline:
- Discovery: 1 week
- Design: 2 weeks
- Development: 4 weeks
- QA: 1 week
- Launch: 0.5 weeks
Total: 8.5 weeks ✅

Phase Breakdown:
- Planning: 12% of time
- Design: 24% of time
- Development: 47% of time
- QA: 12% of time
- Launch: 6% of time

Comparison: 15% faster than previous similar feature

Success Factors:
- Clear requirements upfront
- Iterative design reviews
- Parallel dev and design for later phases

Setting Up Your Metrics Dashboard

1. Choose Your Metrics

Start Small (3-5 metrics):

1-2 Flow Metrics (e.g., Velocity, Cycle Time)
1 Quality Metric (e.g., Defect Rate)
1 Team Health Metric (e.g., Team Satisfaction)
1 Business Metric (e.g., Delivery Predictability)

Expand Gradually:

Add metrics as team matures
Replace metrics that don't drive action
Keep total metrics <10 for focus

2. Establish Baselines

First Month:

Measure without targets
Establish baseline performance
Understand variance and patterns

Second Month:

Set initial targets (realistic)
Begin tracking trends
Identify quick wins

Third Month+:

Refine targets based on data
Focus on improvement initiatives
Celebrate progress

3. Create Rituals

Daily:

Quick scan of WIP and blockers
Review new high-priority tasks
5-minute metric check

Weekly:

Review velocity and throughput
Team health pulse check
Blocker resolution review

Monthly:

Comprehensive metric review
Trend analysis and forecasting
Process improvement discussions

Quarterly:

Deep dive on all metrics
Benchmark against goals
Strategic adjustments

Taking Action on Metrics

When Metrics Show Problems

Don't Panic: One bad week doesn't indicate systemic issues Look for Patterns: Multiple data points confirm trends Investigate Root Causes: Metrics show symptoms, not causes Involve the Team: Collaborative problem-solving Experiment: Try improvements, measure impact

Improvement Framework

1. Identify the Problem

Which metric is concerning?
How significant is the deviation?
Is this a trend or anomaly?

2. Analyze Root Causes

Why is this happening?
When did it start?
What changed recently?

3. Generate Solutions

What could we try?
What has worked in the past?
What do other teams do?

4. Experiment

Pick one improvement
Set success criteria
Define measurement period (2-4 weeks)

5. Measure Impact

Did the metric improve?
Any unintended consequences?
Should we continue, adjust, or stop?

Example Improvement Cycle

Problem Identified:

Metric: Cycle time increased from 3 days to 7 days
Duration: Last 3 weeks
Impact: Delivery commitments at risk

Root Cause Analysis:

Investigation findings:
- Code review turnaround increased from 4 hours to 24+ hours
- Two senior reviewers on vacation
- Remaining reviewers overloaded
- No backup review process

Solutions Generated:

Options:
1. Add junior developers to review rotation (with senior oversight)
2. Set review response time SLA (4 hours)
3. Implement pair programming to reduce review bottleneck
4. Create review buddy system for coverage

Experiment:

Trying: Combination of options 1, 2, and 4
Duration: 2 sprints
Success Criteria: Cycle time returns to <4 days median
Measurement: Track review turnaround and overall cycle time

Results:

After 2 sprints:
- Review turnaround: Down to 6 hours median ✅
- Cycle time: Down to 4.2 days median ✅
- Side benefits: Junior developers improving faster

Decision: Continue all three improvements, they work together

Common Metric Pitfalls

1. Vanity Metrics

Problem: Metrics that look good but don't drive improvement

Examples:

Total lines of code written
Number of commits
Hours logged
Tasks created (not completed)

Fix: Focus on outcome metrics (shipped features, user impact, quality)

2. Gaming the Metrics

Problem: Optimizing for the metric instead of actual improvement

Examples:

Breaking tasks artificially small to inflate velocity
Marking tasks done prematurely to hit targets
Cherry-picking easy tasks to boost completion rates

Fix:

Measure balanced scorecard (multiple metrics)
Focus on trends, not absolute numbers
Emphasize team ownership over individual metrics
Regular metric review and adjustment

3. Analysis Paralysis

Problem: Measuring everything, acting on nothing

Examples:

Tracking 20+ metrics
Spending more time analyzing than improving
Waiting for perfect data before taking action

Fix:

Limit to 5-7 core metrics
Bias toward action over analysis
Use metrics to guide, not dictate, decisions

4. Ignoring Context

Problem: Comparing metrics without accounting for differences

Examples:

Comparing velocity across different teams
Comparing cycle time on different task types
Benchmarking against different industries

Fix:

Compare against your own baselines
Segment metrics by task type/size
Focus on your trend, not others' numbers

Best Practices Summary

Do's

✅ Start with a few metrics - Quality over quantity ✅ Establish baselines - Understand normal before targeting improvement ✅ Focus on trends - One data point isn't a pattern ✅ Involve the team - Shared ownership of metrics ✅ Act on insights - Metrics without action are pointless ✅ Measure balance - Flow, quality, team health, and business ✅ Iterate on metrics - Adjust as team and work evolves ✅ Celebrate progress - Recognize improvements

Don'ts

❌ Don't track vanity metrics - Measure meaningful outcomes ❌ Don't game the system - Optimize for real improvement ❌ Don't compare teams - Focus on your own growth ❌ Don't over-measure - Analysis paralysis prevents action ❌ Don't ignore context - Account for differences in work ❌ Don't blame individuals - Metrics are team outcomes ❌ Don't chase perfection - Good enough beats perfect ❌ Don't forget the why - Connect metrics to goals

Conclusion

Effective metrics enable:

Data-driven decisions instead of gut feelings
Continuous improvement through measurement and experimentation
Predictable delivery based on historical performance
Team health visibility and early problem detection
Business alignment connecting work to outcomes

Start small, measure consistently, act on insights, and continuously improve. Your metrics should serve your team, not the other way around.

Related Resources

Collaboration Best Practices - Team collaboration strategies
Layer Progress Tracking - Track progress by layer
Board Configuration - Set up your board for success
Writing Effective Tasks - Create measurable tasks

Last updated: January 10, 2025