Standard Fibonacci sequences (1, 2, 3, 5, 8, 13) work for 80% of agile teams, but what about the other 20%? Hardware teams estimating physical prototyping work, research teams dealing with uncertainty-heavy tasks, or organizations transitioning from hour-based estimation often need custom scales that better reflect their unique complexity patterns.
When off-the-shelf estimation scales don't fit your team's mental model of work, you're forcing square pegs into round holes. The result? Endless debates over whether something is "a 5 or an 8," inconsistent velocity tracking, and estimation sessions that feel disconnected from the actual work being delivered.
Why Teams Need Custom Estimation Scales
Standard estimation scales assume certain characteristics about your work. When those assumptions break down, custom scales become necessary.
Problem 1: Your Work Doesn't Follow Natural Fibonacci Growth
Fibonacci works because complexity growth isn't linear—a 13-point story isn't just "twice as hard" as a 5-point story. The gaps widen as uncertainty increases.
But some teams work differently:
- Hardware/manufacturing teams: Physical constraints create discrete complexity jumps (prototype vs small batch vs production tooling)
- Research & data science: Uncertainty dominates, making fine-grained Fibonacci distinctions meaningless
- Infrastructure work: Complexity often doubles (1 server vs 2 vs 4 vs 8)
- Design work: Iterations happen in predictable cycles that don't map to Fibonacci
When your actual work patterns don't match Fibonacci's growth curve, estimates become arbitrary numbers instead of meaningful complexity indicators.
Problem 2: Too Much Granularity (Or Not Enough)
Fibonacci forces specific precision levels. Between 5 and 8, there's no middle ground. For some teams, that's perfect—it prevents false precision. For others, it creates constant "split the difference" debates.
Teams needing more granularity:
- Large-scale enterprise projects where the difference between 8 and 13 represents weeks of effort
- Financial services with strict estimation audit requirements
- Client billing scenarios where estimates tie directly to contracts
Teams needing less granularity:
- Early-stage startups where everything is uncertain and T-shirt sizing (S/M/L) suffices
- Research teams where stories are either "feasible this sprint" or "needs spike"
- Maintenance work that's mostly uniform complexity
Problem 3: Team Mental Models Don't Match Numbers
Some teams naturally think in other patterns:
- Time-based thinkers: Prefer "days" even though story points aren't hours (Modified Fibonacci: 0.5, 1, 2, 3, 5, 8 approximates half-day increments)
- Percentage-based thinkers: Engineers estimating as "% of sprint capacity" (10%, 25%, 50%, 75%)
- Risk-focused teams: Uncertainty matters more than size (Low/Med/High risk + separate size estimate)
When your team constantly needs to "translate" between the scale and their internal mental model, you're adding cognitive overhead to every estimation.
Popular Custom Estimation Scales
Modified Fibonacci (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100)
The most common customization adds smaller values and larger endpoints.
Added 0: For trivial work (typo fixes, copy changes). Prevents "everything is at least a 1" inflation.
Added 0.5: For sub-1 tasks that still need tracking. Common in teams transitioning from hour-based estimation who aren't ready to batch tiny tasks.
Added 20, 40, 100: For epic-level estimation before decomposition. Signals "this is too big for sprint planning."
Best for: Teams with wide work variability who need to estimate everything from quick fixes to multi-sprint epics in the same backlog.
Pitfall: Adding too many options reintroduces false precision. Modified Fibonacci works because it keeps gaps wide while addressing edge cases.
Alignlee supports Modified Fibonacci as a preset scale option, no custom configuration needed.
Powers of 2 (1, 2, 4, 8, 16, 32)
Doubling scale where each increment represents roughly double the complexity.
Why teams use it:
- Mathematically clean—each story is 2x the previous
- Maps to computing concepts (memory allocation, binary trees, API calls)
- Easier mental math for velocity calculations
- Natural fit for infrastructure and DevOps work where capacity doubles
Example: Provisioning 1 server = 2 points. Provisioning 2 servers (with load balancing) = 4 points. Provisioning 4 servers (with orchestration) = 8 points.
Best for: Infrastructure teams, DevOps, platform engineering, backend-heavy work where parallelization and scaling are primary complexity drivers.
Pitfall: Doesn't account for the inherent uncertainty that Fibonacci captures. A 16-point story might not actually be 2x more complex than an 8—it might be 3x or 5x depending on unknowns.
T-Shirt Sizes (XS, S, M, L, XL, XXL)
Non-numeric scale that removes the "points = hours" temptation entirely.
Why teams use it:
- More intuitive for non-technical stakeholders (product, design, management)
- Removes false precision completely—no one argues "M vs M+"
- Faster initial adoption for teams new to story points
- Better for high-level roadmap estimation before detailed breakdown
Best for: Cross-functional teams with non-technical members, early-stage planning, portfolio-level estimation, teams transitioning away from hour-based estimation.
Pitfall: Harder to calculate velocity (you have to convert shirts to numbers eventually). Tools like Jira require numeric values, forcing arbitrary conversion (S=3, M=5, L=8).
Research from Mountain Goat Software shows teams using T-shirt sizes estimate 30% faster initially but often graduate to Fibonacci after 3-6 months for better velocity tracking.
Linear Scales (1, 2, 3, 4, 5)
Equal-interval scale where each increment is uniform.
Why teams use it:
- Simplest to understand for new teams
- Matches intuitive sense of "twice as big"
- Easy average calculations
- Familiar from school grading systems
Best for: Brand new agile teams still learning estimation concepts, teams with very uniform work (support tickets, minor bugs), small teams where complexity variance is low.
Pitfall: Encourages the false belief that complexity grows linearly. A 4-point story isn't "twice as hard" as a 2-point story when you account for integration complexity, edge cases, and unknowns. Linear scales work until you hit real uncertainty, then they break down.
Dog Breeds, Animals, or Objects
Non-standard playful scales (Chihuahua, Beagle, Labrador, Great Dane, St. Bernard).
Why teams use it:
- Fun and memorable
- Completely removes "points = hours" thinking
- Team bonding through shared inside jokes
- Works for teams allergic to process overhead
Best for: Startups, creative agencies, teams with strong culture of autonomy and experimentation.
Pitfall: Doesn't integrate with any standard tools. You'll manually map to numbers for Jira/velocity tracking. Also, the novelty wears off, and you're left explaining "why are we using dog breeds?" to every new hire.
When to Create a Truly Custom Scale
Most teams should start with standard Fibonacci or T-shirts and only customize when you have concrete evidence the defaults are causing problems.
Signs You Need a Custom Scale
Quantitative signals:
- Consistent clustering: 70%+ of stories estimated at the same 2 values
- Wide dispersion: Votes routinely span 5+ values (2, 3, 5, 8, 13 all common for same story)
- Re-estimation rate: More than 30% of stories re-pointed mid-sprint
- Debate time: 10+ minutes per story arguing over scale fit
Qualitative signals:
- "None of these numbers feel right" (said weekly)
- Team needs to "translate" scale to their mental model every story
- New members don't understand why you're using current scale
- Stakeholders can't interpret what estimates mean
How to Design a Custom Scale
Step 1: Analyze Your Actual Work Complexity
Pull 20-30 completed stories from last 3 sprints. On a whiteboard, group them by "felt similar in complexity." Ignore the estimates—fresh clustering.
You'll likely get 4-7 natural clusters. That's your real complexity spectrum.
Step 2: Define Boundaries Between Clusters
What makes something move from Cluster 2 to Cluster 3? Write down the differentiators:
- Number of files touched
- Number of teams involved
- New vs familiar technology
- Requirement clarity
- Testing complexity
These become your "reference definitions" for each scale point.
Step 3: Choose Numbers That Match Intuition
Do gaps feel like they double? Use powers of 2 (2, 4, 8, 16). Do gaps feel non-linear but not quite doubling? Fibonacci. Do gaps feel roughly equal? Linear (1, 2, 3, 4, 5).
Step 4: Test With Historical Stories
Re-estimate 10-15 old stories using new scale. Do estimates feel more "right"? Do debates resolve faster?
If the custom scale doesn't clearly improve over standard Fibonacci, don't switch. The benefit must outweigh the cost of training the team on a non-standard approach.
Common Custom Scale Mistakes
Mistake 1: Too Many Options
"Let's use 1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 15, 18, 20, 25..."
More precision = more debate time. Each additional option increases cognitive load. Optimal scale has 5-9 values max (per Miller's Law of cognitive capacity).
Mistake 2: Irregular Gaps
"Let's use 1, 3, 7, 12, 20..." (random gaps)
Without a pattern, team can't internalize the scale. Fibonacci works because it's memorable—each number is previous two added. Custom scales need equally clear logic.
Mistake 3: Decimal Points
"Let's use 1, 1.5, 2, 2.5, 3, 3.5..."
False precision disguised as custom scale. If you need that granularity, you're estimating in hours, not story points.
Mistake 4: Not Documenting Reference Stories
You create a custom scale but don't write down what a "4" means. Three months later, new team member asks "what's a 4?" and no one remembers.
Solution: Create a reference story library with 2-3 examples per scale value. Pin in team wiki or Confluence.
Custom Scales in Planning Poker Tools
Most planning poker tools lock you into Fibonacci or T-shirts. When evaluating tools for custom scale support, check:
Essential features:
- Ability to define arbitrary numeric sequences
- Ability to define arbitrary text labels (for non-numeric scales)
- Persistency: Custom scales saved per team, not re-entered each session
- Visibility: All participants see custom scale during voting (not just facilitator)
Nice-to-have features:
- Multiple saved custom scales (switch between projects)
- Scale templates (Modified Fibonacci, Powers of 2 as presets)
- Reference story library tied to each scale value
- Export/import scale definitions across teams
Alignlee supports fully custom estimation scales with both numeric and text-based values. Create once, reuse across sessions, share with your team.
Migrating to a New Scale
Don't just announce "we're using Powers of 2 now" on Monday and expect smooth transition.
Migration Process
Week 1: Introduce and Explain
- Show current scale problems with real examples
- Present new custom scale with rationale
- Define reference stories for each value
- Answer questions in retro
Week 2: Parallel Estimation
- Estimate new stories with new scale
- Also estimate with old scale (in parentheses)
- Compare: Does new scale reduce debate time?
Week 3-4: New Scale Only
- Commit fully to new scale
- Historical velocity becomes less relevant (expected)
- Track new baseline over 3-4 sprints
After 1 month: Retrospective Review
- Did estimation time improve?
- Did estimation accuracy improve?
- Does team prefer new scale?
If answers are "no" across the board, revert. Custom scales aren't inherently better—they're only better if they match your team's unique context.
Tools That Support Custom Estimation Scales
Not all planning poker tools offer custom scale flexibility. Here's where to find support:
Full Custom Support
- Alignlee: Define any numeric or text-based scale, save per team, switch between projects
- Jira built-in estimation: Custom field values, but no visual planning poker
- Miro/Mural: Template-based, fully customizable but manual (no automated voting)
Limited Custom Support
- Planning Poker (Spartez): Fibonacci, Modified Fibonacci, T-shirt—no arbitrary custom
- Scrum Poker Online: Fixed scales only
- PlanITpoker: Preset scales, limited customization
Workarounds for Tools Without Custom Scales
If your team uses a tool that doesn't support custom scales:
- Map to nearest Fibonacci: Use Fibonacci but document "5 = Small Batch" mapping
- Use comments: Vote with standard scale, comment your "real" scale in discussion
- Switch tools: If custom scales are critical, choose a tool that supports them
When to Stick With Standard Fibonacci
Most teams should NOT create custom scales. Fibonacci works because:
- Universal: New team members already know it from previous teams
- Well-documented: Thousands of blog posts, training materials explain Fibonacci estimation
- Tool support: Every planning poker tool supports it
- Proven: 20+ years of agile teams using it successfully
Only customize when:
- You have 6+ months of data showing Fibonacci doesn't fit your work
- The team consensus is "we need something different"
- You can clearly articulate what makes your work unique
- You're willing to train every new hire on your custom approach
Start Flexible Estimation Today
Whether you need standard Fibonacci, Modified Fibonacci, Powers of 2, T-shirt sizing, or a fully custom scale, Alignlee supports your team's unique estimation needs.
Create your first session with any scale—swap anytime as your team evolves.