Problems with Traditional Estimation

• Estimations extremely difficult - never worked on team good at them
• Most teams terrible/okay at estimations at best
• Traditional point systems often frustrate when tasks don't complete on time
• Ping doesn't currently use points due to difficulty making valuable system

Goals of Estimation Systems

• Identify who should do task
• Identify when task should be done
• Identify how long task will take
• Prioritize based on above factors
• Identify low performers/underutilized team members

Key Insight: Time Estimation Failure

• "How long it will take" fundamentally unreliable
• Could be accurate sometimes but not consistently
• Common trap: assuming point value = guaranteed completion time
• This assumption is fundamentally wrong

Proposed New Estimation Framework

Three-Dimensional Scoring (1-10 scale each):

Complexity (or Specialization)

• How hard/specialized is the task
• How skilled should person doing it be
• Example: WebRTC task at Ping = 10/10 complexity (specialized knowledge required)

Effort (formerly Time)

• How long should task be worked on
• Not mapped to specific time units
• 1/10 = quick one-line fix, 10/10 = extended work period
• Will almost always be wrong but provides relative indication

Risk (Confidence)

• Chances that complexity/effort estimates are wrong
• Missing component in most estimation systems
• Critical for indicating estimate reliability

Real Example: Voice Levels in Pre-call View

Initial Estimates:

• Complexity: 3-4/10 (seemed simple, reuse existing code)
• Effort: 2/10 (quick implementation)
• Risk: 6/10 (third-party dependencies, device interaction)

Actual Results:

• Agora SDK doesn't provide reliable voice indication outside calls
• Risk estimate proved accurate
• Complexity became 6-7/10, Effort became 4-5/10
• High risk score correctly predicted estimate inaccuracy

Value of Multi-Dimensional Approach

Task Assignment Benefits:

• Easier identification of right person for task
• Clear reasoning for assignment decisions
• Better employee development planning

Junior Developer Growth Strategy:

• Start with: low complexity, high effort tasks
• Progress to: medium effort, high complexity tasks
• Consistently impressive results when shifting focus from effort to complexity
• Reveals unexpected developer capabilities

Key Problem with Traditional Systems

• Conflate complexity and effort into single metric
• Ignore risk entirely
• Pretend complexity = effort (fundamentally different concepts)

Handling Unknowns and Research

Separate Research Tasks:

• When complexity/risk unclear, create research task first
• Example: "Identify how to get voice levels from third-party SDK"
  • Complexity: 2/10 (read docs)
  • Effort: 2/10 (research task)
  • Risk: 4/10 (moderate uncertainty)
• Research tasks mitigate risk for subsequent implementation
• If struggling to categorize complexity vs risk = need research task

Current Implementation Status

Ping's Current Approach:

• Team of 5 developers + 1 non-developer
• Using gut feel due to small team size
• All tracking in Linear
• Good intuitive sense of task assignment and timing
• Thinks in proposed framework but doesn't formally measure yet

Future Plans:

• Will implement formal system when team scales
• Proposal for future estimation methodology
• Moving away from T-shirt sizes and Fibonacci sequences
• Focus on: what's hard + who has skills, what's long + who has time, what's risky + how wrong are estimates

Implementation Philosophy

• Estimation system should expect to be wrong
• Less guarantee, more indicator for task assignment
• Separate unknowns identification as distinct task type
• Build system that adds value rather than frustration