Total Story Points Completed Report

Last updated: February 3, 2026

Overview

The Total Story Points Completed report measures the volume of work your team delivers, weighted by complexity and effort. Unlike simple issue counts, this metric accounts for the estimated size of each completed item, giving you a more nuanced view of team capacity and delivery throughput.

What This Metric Measures

Story Points Completed tracks the total estimation value of work delivered by measuring:

  • Weighted delivery volume: Sum of all story point estimates from completed issues

  • Team velocity: How much estimated work your team can complete per time period

  • Capacity baseline: Historical throughput for forecasting future sprint commitments

  • Delivery trends: Whether your team's output is increasing, decreasing, or stable

This metric provides a more accurate picture of productivity than raw issue counts, especially when your backlog contains issues of varying complexity.

Metric Variants

Span provides several story points metrics to support different analysis needs:

1. Total Story Points Completed (Base Metric)

The aggregate sum of all story point estimates from issues marked as completed in the selected time period.

2. Story Points Completed Per Week (Rate-Normalized)

Normalizes the total by active working days, allowing fair comparison across different time periods and accounting for time off.

FormulaTotal Story Points Completed ÷ Active Days × 7

3. Sprint-Specific Metrics

Track story points within sprint contexts:

  • Planned Story Points Completed: Points from issues planned at sprint start

  • Unplanned Story Points Completed: Points from issues added during the sprint

  • Story Points In Progress: Currently active work

  • Story Points In Review: Work pending final approval

  • Rolled Over Story Points: Work carried to the next sprint

How It's Calculated

Basic Calculation:

Total Story Points Completed = SUM(story_points) WHERE status = 'completed'

For Rate-Normalized Version:

Story Points Per Week = (Total Story Points ÷ Active Days) × 7

Active Days Definition:

  • Days when team members were NOT marked as out of office

  • Calculated across all contributing team members

  • Automatically excludes vacation, sick leave, and scheduled time off

Example: If your team completed 120 story points over a 2-week period with 60 active employee days:

(120 ÷ 60) × 7 = 14 story points per week per active contributor

Where to Find This Report

Access the Total Story Points Completed report from:

  • Team dashboards → Velocity metrics

  • Individual contributor views → Personal metrics

  • Search for "Story Points Completed" in the metrics navigation

The metric page route is: issue-estimate-completed

Available Breakdowns & Filters

Analyze Story Points Completed across multiple dimensions:

Team & People Dimensions

  • Individual contributors

  • Teams and organizational groups

  • Team hierarchy paths

  • Department or job family

Issue Dimensions

  • Issue status (Completed, In Progress, In Review)

  • Issue type (Story, Task, Bug, etc.)

  • Custom lifecycle stages

  • Planned vs. unplanned work

Sprint Context

  • Sprint cycles

  • Sprint start/end dates

  • Work added during sprint vs. planned at start

  • Rolled over work from previous sprints

Time Periods

  • Custom date ranges: Any start and end date

  • Weekly aggregation: 7-day rollups for normalized metrics

  • Monthly/Quarterly: Longer period aggregations

  • Sprint cycles: Point completion per sprint

  • Historical comparisons: Side-by-side period analysis

  • Trending views: Time series showing changes over time

Key Use Cases

1. Establish Team Velocity

Calculate your team's average story points completed per sprint to set realistic commitments for future sprints.

2. Capacity Planning & Forecasting

Use historical story point completion to estimate delivery timelines for roadmap features and projects.

3. Sprint Planning Quality

Compare planned vs. actual story points completed to improve estimation accuracy and reduce scope creep.

4. Team Performance Benchmarking

Use the per-week normalized metric to compare throughput across teams while accounting for time off and calendar differences.

5. Identify Productivity Trends

Track whether story point completion is improving, declining, or remaining stable to spot process improvements or bottlenecks.

6. Workload Distribution Analysis

Understand how story points are distributed across team members to balance workload and identify capacity constraints.

7. Measure Unplanned Work Impact

Analyze how much unplanned work affects sprint completion to better manage interruptions and ad-hoc requests.

How It Relates to Other Metrics

Story Points Completed works best when analyzed alongside complementary metrics:

Metric

Relationship

Issues Completed

Count-based alternative; useful when story points aren't available or reliable

Issue Cycle Time

Measures speed of completion; combine to understand efficiency vs. volume

Sprint Planning Accuracy

Shows % of planned story points actually completed

Planned vs. Unplanned Work

Breaks down story point completion by work origin

Story Points In Progress

Shows current active work to prevent overcommitment

Completion Rate

Shows percentage of total backlog completed

Pro Tip: Use Story Points Completed (volume) with Issue Cycle Time (speed) to get a complete picture of both throughput and efficiency. High story points with low cycle time indicates strong productivity.

Insights You Can Gain

Velocity Patterns

  • Is team velocity stable or fluctuating significantly?

  • What's the typical range of story points completed per sprint?

  • Are there seasonal patterns or predictable variations?

Planning Accuracy

  • How often does the team complete what they planned?

  • Is scope creep (unplanned work) impacting sprint goals?

  • Are estimates consistently accurate or systematically off?

Capacity Analysis

  • What's the team's realistic throughput capacity?

  • How do absences or team changes affect delivery volume?

  • Are certain team members carrying disproportionate load?

Efficiency Trends

  • Is the team getting faster at completing work?

  • Did process changes improve or hurt throughput?

  • What periods show exceptional or poor performance?

Workload Balance

  • Are story points evenly distributed across the team?

  • Do certain issue types consistently consume more capacity?

  • Is technical debt work affecting feature delivery?

Important Considerations

Story Point Scale Differences

Important: Span does not automatically normalize different story point scales across teams. If Team A uses a 1-13 Fibonacci scale and Team B uses a 1-8 linear scale, both are summed directly.

Implications for Cross-Team Comparison:

  • Teams with larger point scales will numerically appear more productive

  • Raw totals are not directly comparable across teams using different scales

  • Recommendation: Use the Story Points Per Week normalized metric for fairer comparison, and analyze teams separately when scales differ significantly

Best Practices for Accurate Analysis

  1. Ensure Consistent Estimation: Train teams on consistent story point estimation practices

  2. Use Rate-Normalized Metrics: Prefer "per week" variants for time-period comparisons

  3. Account for Context: Major refactors, tech debt, or team changes affect velocity

  4. Look at Trends, Not Snapshots: Single sprint variations are normal; focus on patterns

  5. Combine with Quality Metrics: High velocity doesn't guarantee high-quality delivery

  6. Review Sprint Retrospectives: Quantitative data should inform, not replace, qualitative discussion

Getting Started

Requirements

To use this metric, ensure you have:

  • ✓ Connected project management tool (Jira, Linear, etc.)

  • ✓ Story point estimation enabled in your PM tool

  • ✓ Issues properly tagged with story point values

  • ✓ Calendar integration enabled (for accurate OOO tracking in normalized metrics)

  • ✓ Team and contributor data configured in Span

Setting Baseline Velocity

  1. Select a Time Period: Choose 3-6 sprints of historical data

  2. Review Story Points Completed: Calculate average and range

  3. Account for Outliers: Remove sprints with major disruptions (holidays, incidents, team changes)

  4. Establish Your Baseline: Use the average as your capacity baseline

  5. Monitor and Adjust: Refine baseline as team composition or processes change

Frequently Asked Questions

Q: How do story points differ from issue counts?
A: Story points weight work by complexity. Completing 5 small bugs (1 point each) equals 5 points, while completing 1 large feature (20 points) shows significantly more throughput. Story points give a more accurate capacity picture.

Q: What if our team doesn't use story points consistently?
A: Consider using the Issues Completed metric instead. Story point metrics are most valuable when estimation practices are consistent and mature.

Q: Should I compare story points across different teams?
A: Only if teams use the same estimation scale. Otherwise, use the normalized "per week" metric and still interpret comparisons cautiously. Focus on each team's trends rather than absolute comparisons.

Q: How do I improve story point completion?
A: Focus on: (1) Removing blockers, (2) Improving estimation accuracy, (3) Reducing unplanned work, (4) Breaking down large stories, (5) Addressing technical debt that slows velocity.

Q: What's a "good" story point completion rate?
A: This varies by team size, estimation scale, and context. Focus on your team's historical baseline and consistency rather than arbitrary targets.

Q: How does Span handle partial sprint periods?
A: The rate-normalized metrics adjust for active days, providing accurate comparisons even for partial periods or when team members have time off.


Need Help?

For additional support with the Total Story Points Completed report:

  • Visit the Span Help Center

  • Contact your Customer Success Manager

  • Email support@span.app


This documentation reflects Span's platform capabilities as of the current version. Features and calculations are subject to updates.