🎯 Estimation Scope
Select whether you're estimating the Epic as a whole or its child stories/tasks.
📋 Requirements
How well are the requirements understood? Ask: "Can we start coding today, or do we need more info?"
🔗 Dependencies
Consider both the number of external dependencies and their reliability. Ask: "Who/what are we waiting on?"
🎓 Learning Curve
How much effort will the team need to spend learning before they can deliver confidently? Ask: "Have we done this before, or do we need to learn?"
📦 Volume of Work
How much work is there, regardless of difficulty? Consider AI's ability to accelerate. Ask: "How many files/components/tests? Can AI generate much of this?"
🧩 Complexity
How intricate is the work? Consider AI's accuracy and reliability. Ask: "Can AI generate this accurately, or does it need heavy human oversight?"
⚠️ Risk
What is the potential for failure or unexpected issues? Consider AI-generated code risks. Ask: "What's the blast radius? Can we trust AI suggestions here?"
Story Point/s
Total Score:
📝 Estimation Summary
Copy this markdown-formatted summary to your Jira issue for documentation:
🤷♂️ How to Use This Calculator
For Individual Estimators
- Select Scope: Choose whether you're estimating an Epic or individual Stories/Tasks
- Evaluate Each Category: Work through Requirements, Dependencies, Familiarity, Volume, Complexity, and Risk
- Consider Interactions: Pay attention to the guidance box - some combinations amplify effort
- Add Notes: Document your reasoning in the text boxes for each category
- Calculate: Click "Calculate Story Points" to see your recommendation
- Update Jira:: Set the story points and paste the summary in the comments
For Team Estimation
- Share Context: One person presents the work item that needs estimation
- Discuss Each Category: Team discusses and agrees on ratings together
- Vote or Consensus: If ratings differ between roles (Dev vs QA), take the higher score
- Document Reasoning: Fill in the notes sections with key discussion points
- Calculate Together: Review the calculated story points as a team
- Sanity Check: Discuss whether the result feels reasonable based on team experience
- Update Jira: Set the story points and paste the summary in the comments
Best Practices
- Use this tool as a conversation starter, not a replacement for team judgment
- Re-estimate if requirements change significantly during the sprint
- Track actual vs estimated effort to calibrate your team's intuition over time
- Split stories that exceed 13 points for better predictability
- Consider breaking epics into smaller deliverables if they score too high
🧮 How It Works
Scoring Formula
The calculator uses a weighted sum across six categories. Each category has a multiplier based on its typical contribution to effort:
| Category | Weight (Children) | Weight (Epics) | Rationale |
|---|---|---|---|
| Requirements | 1.0x | 1.5x | Unclear requirements can be clarified or re-estimated |
| Dependencies | 1.2x | 2.0x | Can cause delays but can be re-planned |
| Learning Curve | 1.5x | 3.0x | Learning effort significantly impacts delivery time and quality |
| Volume | 1.5x | 2.5x | More work takes more time, regardless of difficulty |
| Complexity | 2.0x | 3.0x | Primary driver of effort - complex work is exponentially harder |
| Risk | 1.0x | 1.5x | Risks can be mitigated with proper planning |
Total Score Formula:
(Requirements × Weight) + (Dependencies × Weight) + (Learning Curve × Weight) + (Volume × Weight) + (Complexity × Weight) + (Risk × Weight)
Story Point Mapping
The calculator uses Fibonacci-based scaling to convert total scores into story points. This reflects the non-linear nature of effort estimation.
For Children (Stories/Tasks)
| Total Score | Story Points |
|---|---|
| ≤ 10 | 1 |
| ≤ 14 | 2 |
| ≤ 20 | 3 |
| ≤ 30 | 5 |
| ≤ 46 | 8 |
| ≤ 72 | 13 |
| > 72 | 21+ (Consider splitting) |
For Epics
| Total Score | Story Points |
|---|---|
| ≤ 72 | 13 |
| ≤ 114 | 21 |
| ≤ 164 | 34 |
| ≤ 233 | 55 |
| ≤ 329 | 89 |
| > 329 | 144+ (Split or convert to initiative) |
Previous Ceiling + (Effort Multiplier × Next Fibonacci Number). The effort multiplier is 2, and epic thresholds include a variance multiplier (1.0, 0.9, 0.85, 0.8...) to account for increasing uncertainty at larger scales.
❓ Frequently Asked Questions
Why isn't 0.5 story points an option?
Story points represent relative effort, not precise time estimates. Using 0.5 points introduces false precision that contradicts the abstract nature of story pointing. It can lead to over-refinement, noisy velocity tracking, and unnecessary complexity. Most agile teams use 1 as the smallest unit and batch smaller tasks together when needed. If a task is worth estimating, it's worth at least 1 point.
Why do different categories have different weights?
The weights reflect how much each category typically contributes to overall effort and uncertainty:
- Complexity (2-3x): Technical difficulty is a primary driver. Complex work requires more time, deeper thinking, and coordination.
- Learning Curve (1.5-3x): Time spent learning significantly slows teams down, even with AI assistance.
- Volume (1.5-2.5x): More work consumes more capacity, even when not technically complex.
- Dependencies (1.2-2x): Can cause delays but don't always increase actual work required.
- Requirements (1-1.5x): Gaps are often resolved early and don't always scale with effort.
- Risk (1-1.5x): Can be mitigated with planning and doesn't always translate to more work.
Why use non-linear scores (1, 5, 8, 13)?
These scores reflect the non-linear nature of effort. The jump from "Medium" to "High" effort is often more than just one unit of work. This scale helps avoid false precision and aligns with agile estimation practices where uncertainty grows exponentially.
How does this map to actual time or velocity?
It doesn't - and that's intentional! Story points measure relative size, complexity, and uncertainty, not duration. The mapping helps teams consistently size the work. Your team's velocity (points completed per sprint) will naturally calibrate over time based on your capacity and working style.
What if Dev and QA have different estimates?
Always take the higher score. This accounts for the full scope of work across all disciplines and provides a more realistic estimate. Use the difference as a discussion point to understand where complexity or risk varies by role.
Should I re-estimate if requirements change?
Yes! If significant changes occur during development, re-run the calculator and update your estimate. Document the change in Jira comments to maintain estimation history and improve future calibration.
What if my calculated points feel wrong?
Trust your team's intuition! This tool provides a data-driven starting point, not an absolute answer. If the result doesn't match your collective experience, discuss why and adjust. Over time, you'll develop better pattern recognition for your team's work.
Why are Epic weights higher than Children weights?
Epics involve additional overhead like cross-team coordination, architectural decisions, integration challenges, and longer feedback cycles. The higher weights reflect this amplified complexity and uncertainty at larger scales.