Best practices for story point estimation and velocity tracking

ALM PTC Codebeamer
, , , , , , , ,
1

Our team recently migrated to codebeamer ALM cb-23 and we’re leveraging the enhanced user-story management features for our agile workflow. However, we’re struggling with inconsistent estimation practices across our three development teams, which is causing planning inaccuracy and unreliable velocity metrics.

Team A uses modified Fibonacci (1,2,3,5,8,13), Team B uses t-shirt sizing that gets converted to points, and Team C uses hours-to-points conversion. When we try to do cross-team capacity planning or portfolio-level velocity tracking, the numbers are meaningless because everyone’s baseline is different.

We’ve configured Planning Poker in cb-23 for estimation sessions, but we haven’t standardized the field inheritance config for story points across projects. Also, our velocity baseline calculations seem off - some sprints show velocity of 45, others show 12, but the actual work completed feels similar.

What approaches have other teams used to standardize story point estimation in codebeamer while still allowing teams some autonomy? How do you handle velocity baseline calculations when teams have different estimation philosophies?

2

The key is to stop trying to compare velocity across teams. Velocity is a team-specific metric, not a portfolio metric. Instead, focus on throughput (items completed per sprint) for cross-team comparisons. In cb-23, you can set up custom reports that track story count completion rates rather than point-based velocity. This gives you meaningful portfolio visibility without forcing estimation standardization.

3

We created a dedicated “Estimation Reference” tracker in each project. It’s a read-only tracker (for most users) that contains 10-15 carefully selected stories representing different complexity levels. Each reference story has detailed acceptance criteria, technical notes, and the estimated points. During planning poker sessions, teams can quickly pull up these references in a second browser tab. The field inheritance is configured so the story point field definition and scale are identical between the reference tracker and the actual backlog tracker.

4

After reviewing all the approaches shared here, I want to synthesize what I believe are the most effective practices for story point estimation and velocity tracking in codebeamer ALM cb-23:

Field Inheritance Config: Standardize the story point field definition at the organizational level, but allow project-level customization of the scale if needed. In cb-23, create a custom field template for “Story Points” with these properties:

  • Field type: Integer with dropdown options
  • Required for sprint commitment: Yes
  • Allowed values: 1, 2, 3, 5, 8, 13, 21 (modified Fibonacci)
  • Default value: None (forces explicit estimation)

Inherit this field template across all agile projects, but document that the interpretation of each value is team-specific. This gives you data consistency without forcing semantic consistency.

Velocity Baseline Calculation: The key insight from Carlos is critical - you need temporal stability in your baseline. Configure your velocity reports in cb-23 to:

  1. Use a rolling 6-sprint average (not all-time average)
  2. Exclude sprints marked as “abnormal” (team changes, holidays, major incidents)
  3. Weight recent sprints slightly higher (multiply last 2 sprints by 1.2x)
  4. Show velocity trend line, not just current velocity

Create a calculated field formula: `(Sprint-1 * 1.2 + Sprint-2 * 1.2 + Sprint-3 + Sprint-4 + Sprint-5 + Sprint-6) / 6.4 This weighted approach gives you a responsive but stable baseline that adapts to team improvement without being overly volatile.

Planning Poker Setup: Lisa’s reference story catalog combined with Priya’s poker configuration creates a powerful estimation framework:

  1. Reference Catalog: Create an “Estimation Baseline” tracker in each project containing 12-15 completed stories that represent your point scale. Tag these with “estimation-reference” and link them to your planning poker configuration.

  2. Poker Rules: Configure Planning Poker in cb-23 with these settings:

    • Voting style: Modified Fibonacci only
    • Outlier threshold: 2 levels (triggers discussion)
    • Consensus rule: 75% within 1 level
    • Required participants: Minimum 3 developers
    • Reference stories: Auto-display stories at adjacent point levels during voting

  3. Estimation Workflow: Make story point estimation a required workflow state transition. Stories can’t move from “Backlog” to “Ready for Sprint” without a point value assigned through Planning Poker.

Cross-Team Metrics: For portfolio-level visibility, shift from velocity comparison to throughput and cycle time metrics:

  • Stories completed per sprint (count-based, not point-based)
  • Average cycle time from “In Progress” to “Done”
  • Predictability score (planned vs. actual completion rate)

These metrics are comparable across teams regardless of estimation philosophy, and cb-23’s reporting engine can easily aggregate them at the portfolio level.

Practical Implementation: Start with one pilot team, implement the full framework, run it for 3 sprints, then roll out to other teams with lessons learned. The field inheritance and planning poker setup are technical configurations, but the reference story catalog and baseline calculations require ongoing curation and team buy-in.

The goal isn’t perfect estimation - it’s consistent enough estimation to enable reliable planning, combined with metrics that actually help you improve delivery predictability over time.