Assess Team Readiness for Scope

Business Context

At AsanaFlow, each product squad owns a workflow area and is periodically evaluated for whether it can take on additional roadmap scope. The Head of Product wants a metrics-based framework instead of relying on manager judgment alone.

Metric Scenario

One squad currently owns Task Templates and serves 1.8M monthly active users. Over the last 2 quarters, its core feature adoption rose from 41% to 49%, 90-day retention for exposed users improved from 58% to 63%, and weekly incidents declined from 7.2 to 3.1. However, backlog size increased from 120 to 185 tickets, median time-to-resolution for bugs worsened from 4.5 to 6.8 days, and on-time delivery fell from 87% to 76%. Leadership is asking whether the team is ready to absorb ownership of Automations, a neighboring feature expected to add 25% more engineering work and support volume.

Requirements

1. Define a primary metric or scorecard for "team readiness to take on more scope."
2. Identify which metrics should be treated as leading indicators vs lagging indicators.
3. Explain how you would balance delivery capacity, quality, user impact, and operational health.
4. Specify thresholds or decision rules for saying "ready," "not ready," or "ready with conditions."
5. Describe how you would diagnose conflicting signals, such as improving user outcomes but worsening execution metrics.

Data Available

• sprint_delivery: sprint_id, team_id, committed_points, completed_points, planned_launches, launches_on_time
• incident_log: incident_id, team_id, severity, created_at, resolved_at, root_cause
• jira_issues: issue_id, team_id, type, priority, created_at, resolved_at, status
• feature_usage_daily: user_id, feature_area, date, active_flag, key_action_count
• retention_cohorts: cohort_week, feature_area, day_30_retention, day_90_retention
• team_capacity: team_id, engineers, PMs, designers, open_roles, attrition_flag, oncall_hours