npx skills add https://github.com/aakash-dhar/claude-skills --skill estimate在进行工作量估算时,请遵循此结构化流程。良好的估算是一个范围,而非单一数字。它们应考虑到复杂性、风险、未知因素,以及事情总是比预期耗时更长的现实。
在估算之前,请明确范围:
# 查找需要更改的文件
grep -rn "[relevant-keyword]" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | head -20
# 检查受影响区域的复杂度
wc -l [target-files]
# 检查有多少文件导入/依赖于受影响的代码
grep -rn "import.*from.*[module]" --include="*.ts" --include="*.js" src/ 2>/dev/null | wc -l
# 检查受影响区域的测试覆盖率
find . -name "*[module]*test*" -o -name "*[module]*spec*" 2>/dev/null
# 检查最近的变更频率(热点区域 = 更高风险)
git log --oneline -20 -- [target-path]
# 检查有多少人曾在此区域工作过
git log --format='%aN' -- [target-path] | sort | uniq -c | sort -rn
# 检查该区域现有的 TODO/FIXME
grep -rn "TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.js" --include="*.py" [target-path] 2>/dev/null
将每个任务分解为具体的子任务:
When estimating work, follow this structured process. Good estimates are ranges, not single numbers. They account for complexity, risk, unknowns, and the reality that things always take longer than expected.
Before estimating, clarify the scope:
# Find the files that would need to change
grep -rn "[relevant-keyword]" --include="*.ts" --include="*.js" --include="*.py" src/ 2>/dev/null | head -20
# Check complexity of affected area
wc -l [target-files]
# Check how many files import/depend on the affected code
grep -rn "import.*from.*[module]" --include="*.ts" --include="*.js" src/ 2>/dev/null | wc -l
# Check test coverage of affected area
find . -name "*[module]*test*" -o -name "*[module]*spec*" 2>/dev/null
# Check recent change frequency (hot spots = more risk)
git log --oneline -20 -- [target-path]
# Check how many people have worked on this area
git log --format='%aN' -- [target-path] | sort | uniq -c | sort -rn
# Check for existing TODOs/FIXMEs in the area
grep -rn "TODO\|FIXME\|HACK\|XXX" --include="*.ts" --include="*.js" --include="*.py" [target-path] 2>/dev/null
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
示例:"添加 Google OAuth2 登录"
子任务:
1. 研究 Google OAuth2 API 并决定使用的库 [探索性研究]
2. 创建 OAuth 配置和环境变量 [小]
3. 实现 OAuth 回调路由和令牌交换 [中]
4. 根据 OAuth 配置文件创建/更新用户记录 [中]
5. 处理账户关联(OAuth + 现有邮箱账户) [大]
6. 在前端添加 OAuth 登录按钮 [小]
7. 处理 OAuth 错误状态和边界情况 [中]
8. 为 OAuth 服务编写单元测试 [中]
9. 为 OAuth 流程编写集成测试 [中]
10. 更新文档和环境设置指南 [小]
11. 使用真实的 Google 凭证在预发布环境测试 [小]
12. 令牌处理的安全性审查 [小]
按 1-5 分评估每个因素:
| 因素 | 1 (低) | 3 (中) | 5 (高) |
|---|---|---|---|
| 代码变更 | 单个文件,< 50 行 | 3-5 个文件,约 200 行 | 10+ 个文件,500+ 行 |
| 逻辑复杂度 | 简单的 CRUD,直接明了 | 条件逻辑,状态管理 | 复杂算法,并发 |
| 依赖关系 | 无外部依赖 | 使用现有库/API | 新集成,跨团队协调 |
| 数据变更 | 无模式变更 | 新列/索引 | 新表,数据迁移,回填 |
| 测试工作量 | 易于测试,用例少 | 多个场景,需要一些模拟 | 复杂设置,端到端测试,难以复现状态 |
| 风险 | 已充分理解的领域,安全变更 | 存在一些未知,影响中等 | 涉及关键路径、支付/认证/数据 |
| 前端工作 | 无 UI 变更 | 次要 UI 更新 | 新页面/流程,响应式,无障碍访问 |
| 领域知识 | 团队做过类似工作 | 需要一些研究 | 团队的新领域 |
| 审查/批准 | 标准 PR 审查 | 需要安全审查 | 架构审查,利益相关者签字 |
| 部署 | 正常部署,无需特殊步骤 | 功能开关,迁移 | 协调部署,停机窗口 |
复杂性得分 = 所有因素的平均值
快速、相对大小的估算 — 最适合待办事项梳理和冲刺计划:
| 尺码 | 描述 | 典型耗时 | 故事点 |
|---|---|---|---|
| XS | 配置变更,文案更新,单行修复 | < 2 小时 | 1 |
| S | 简单的 Bug 修复,小功能,范围明确 | 2-4 小时 | 2 |
| M | 包含几个组件的功能,存在一些未知 | 1-2 天 | 3-5 |
| L | 多组件功能,新集成,数据库变更 | 3-5 天 | 8 |
| XL | 跨多个系统的大型功能,存在显著未知 | 1-2 周 | 13 |
| XXL | 史诗级工作,在估算前需要分解 | 2+ 周 | 21+ |
规则 :如果达到 XL 或更大,请在估算前将其分解为更小的任务。
提供乐观、最可能和悲观的估算:
估算:添加 Google OAuth2 登录
最佳情况(一切顺利): 3 天
最可能情况(正常开发节奏): 5 天
最坏情况(意外并发症): 8 天
推荐估算: 5 天
未知因素缓冲(20%): +1 天
包含缓冲的总计: 6 天
公式 :期望值 = (最佳 + 4×最可能 + 最坏) / 6
这是 PERT 估算技术 — 它权衡了最可能的情况,同时考虑了极端情况。
使用斐波那契数列进行相对大小估算:1, 2, 3, 5, 8, 13, 21
参考故事(与团队校准):
1 点 → 修复 UI 中的拼写错误
2 点 → 向现有表单添加新字段
3 点 → 创建带有验证的新 API 端点
5 点 → 实现包含前端 + 后端 + 测试的新功能
8 点 → 与外部服务的新集成 + 错误处理
13 点 → 包含数据库模式变更 + 迁移 + 多个 API 的大型功能
21 点 → 史诗级,需要分解
规则 :如果无法确定是 5 还是 8,就选择 8。估算应偏向保守。
对于已知工作最准确 — 汇总各个任务的估算:
任务分解:添加 Google OAuth2 登录
| # | 任务 | 估算 | 置信度 |
|---|------|----------|-----------|
| 1 | 研究与库选择 | 2h | 高 |
| 2 | OAuth 配置与环境变量 | 1h | 高 |
| 3 | OAuth 回调路由 | 3h | 中 |
| 4 | 用户记录创建/关联 | 4h | 中 |
| 5 | 账户关联边界情况 | 4h | 低 |
| 6 | 前端登录按钮 | 2h | 高 |
| 7 | 错误处理 | 3h | 中 |
| 8 | 单元测试 | 3h | 高 |
| 9 | 集成测试 | 4h | 中 |
| 10 | 文档 | 1h | 高 |
| 11 | 预发布环境测试 | 2h | 中 |
| 12 | 安全审查 | 1h | 高 |
|---|------|----------|-----------|
| | **小计** | **30h** | |
| | **缓冲(针对中/低置信度任务,25%)** | **+8h** | |
| | **总计** | **38h (~5 天)** | |
| 风险 | 对估算的影响 | 缓解措施 |
|---|---|---|
| 首次执行此类任务 | +50-100% | 先进行有时间限制的探索性研究 |
| 需求不明确 | +30-50% | 在估算前澄清 |
| 外部 API 依赖 | +25-50% | 先用模拟构建,稍后集成 |
| 跨团队协调 | +25-50% | 尽早协调时间表,识别阻碍 |
| 对大表进行数据库迁移 | +25% | 在生产规模数据上测试迁移时间 |
| 涉及关键路径(认证、支付) | +25% | 额外测试,分阶段推出 |
| 无现有测试 | +30% | 先编写特征化测试 |
| 遗留代码 / 技术债务 | +25-50% | 预留理解 + 清理的时间 |
| 设计师不可用 | +25% | 使用现有模式,获取异步反馈 |
| 新技术/库 | +30-50% | 先制作原型,增加学习时间 |
| 法规/合规要求 | +25% | 尽早让合规团队参与 |
| 需要考虑多个环境 | +20% | 浏览器/设备的测试矩阵 |
基础估算: 5 天
风险:首次使用 OAuth2 +2 天 (40%)
风险:账户关联复杂性 +1 天 (20%)
风险:无现有认证测试 +1 天 (20%)
风险调整后的估算: 9 天
推荐缓冲: +1 天 (10%)
最终估算: 10 天 (2 周)
始终与估算一起传达置信度:
| 置信度 | 适用情况 | 准确度 |
|---|---|---|
| 高 (±10%) | 已充分理解的工作,团队做过类似工作,需求清晰 | 估算非常可靠 |
| 中 (±25%) | 存在一些未知,大部分已理解,需要少量研究 | 估算可能有变化 |
| 低 (±50%) | 存在显著未知,新技术,需求不明确 | 在准确估算前需要进行探索性研究 |
| 非常低 (±100%) | 全新领域,主要未知 | 不要估算 — 先进行探索性研究 |
示例输出:
估算:5 天
置信度:中 (±25%)
范围:4-7 天
建议:先进行 2 小时的 OAuth 库选择探索性研究,
在承诺进入冲刺前将置信度提高到高
使用过去的工作来校准估算:
# 类似的 PR 花了多长时间?(首次提交到合并之间的时间)
git log --merges --oneline --grep="auth\|login\|oauth" | head -10
# 类似功能的平均 PR 大小
gh pr list --state merged --search "auth OR login" --json additions,deletions,createdAt,mergedAt --limit 10 2>/dev/null
# 上一个类似功能花了多长时间?
git log --oneline --after="2025-01-01" --grep="feat" | head -20
# 最近 PR 的周期时间
gh pr list --state merged --limit 20 --json number,title,createdAt,mergedAt 2>/dev/null
类似已完成的工作:
| 功能 | 估算 | 实际 | 比率 |
|---------|-----------|--------|-------|
| 密码重置流程 | 3 天 | 4 天 | 1.33x |
| Stripe 集成 | 5 天 | 8 天 | 1.60x |
| 用户资料页 | 2 天 | 2 天 | 1.00x |
| 邮件通知 | 3 天 | 5 天 | 1.67x |
平均比率:1.40x (团队通常比估算多花 40% 的时间)
应用于当前估算:
原始估算:5 天
历史调整(×1.40):7 天
确定工作是否适合当前冲刺:
冲刺容量分析:
冲刺时长: 10 天
可用团队成员: 4 人
休假/会议/开销: -2 天/人 (20%)
每人有效容量: 8 天
团队总容量: 32 人天
已承诺工作量: 20 人天
剩余容量: 12 人天
此任务估算: 7 人天
缓冲: +2 天
结论: ✅ 适合当前冲刺 (占用 12 天剩余容量中的 9 天)
为其他工作/意外情况留有 3 天缓冲
✅ 适合 → 任务估算 ≤ 剩余容量的 60%
⚠️ 紧张 → 任务估算为剩余容量的 60-80%
❌ 不适合 → 任务估算 > 剩余容量的 80%
🔪 需要拆分 → 任务估算 > 冲刺容量 (需要分解)
当任务过大时,建议如何分解:
按层级拆分(垂直切片)
原始:"添加用户搜索功能"
拆分为:
冲刺 1:基础搜索 API + 简单 UI (MVP)
冲刺 2:高级过滤器 + 分页
冲刺 3:搜索建议 + 分析
按功能拆分(水平切片)
原始:"实现结账流程"
拆分为:
任务 1:购物车摘要页 (仅前端,模拟数据)
任务 2:支付 API 集成 (仅后端)
任务 3:连接前端与后端
任务 4:订单确认 + 邮件通知
任务 5:错误处理 + 重试逻辑
按风险拆分(先探索)
原始:"从 Mailgun 迁移到 SendGrid"
拆分为:
任务 1:[探索] 评估 SendGrid API,测试发送 (限时:4h)
任务 2:实现匹配当前接口的 SendGrid 包装器
任务 3:更新邮件模板以适配 SendGrid 格式
任务 4:在预发布环境进行迁移 + 测试
任务 5:生产环境切换 + 监控
按用户故事拆分
原始:"OAuth 登录"
拆分为:
故事 1:作为用户,我可以用 Google 登录
故事 2:作为用户,我可以用 GitHub 登录
故事 3:作为现有用户,我可以关联我的 OAuth 账户
故事 4:作为用户,我可以取消关联我的 OAuth 账户
📋 估算:[任务标题]
大小:M (中等)
点数:5
时间估算:3-5 天 (最可能 4 天)
置信度:中 (±25%)
分解:
- 后端 API 变更 — 1.5 天
- 前端更新 — 1 天
- 测试 — 1 天
- 审查 + 修复 — 0.5 天
风险:
- 依赖设计稿 (尚未定稿) — 可能增加 1-2 天
- 首次使用此 API — 可能需要额外研究时间
依赖关系:
- 前端工作需要设计批准后才能开始
- 集成测试需要预发布环境访问权限
冲刺适应性:✅ 适合,仍有 3 天缓冲
📊 工作量估算:[功能名称]
预计交付:2-3 周
置信度:中
包含内容:
- [能力 1]
- [能力 2]
- [能力 3]
不包含内容(未来工作):
- [范围外项目 1]
- [范围外项目 2]
关键风险:
- [风险 1] — 通过 [方法] 缓解
- [风险 2] — 在 [里程碑] 后会了解更多
假设:
- 设计在 [日期] 前定稿
- 在此期间没有其他优先级变更
- [团队成员] 在整个期间可用
[任务] 的快速估算:
- 大小:S/M/L
- 时间:X-Y 天
- 置信度:高/中/低
- 是否适合本冲刺:是/否/紧张
- 风险:[一句话描述]
按以下结构组织每个估算:
任务:[需要完成的工作的清晰描述]
范围:[包含和明确排除的内容]
| # | 子任务 | 估算 | 置信度 | 风险 |
|---|---------|----------|------------|------|
| 1 | [任务] | Xh | 高/中/低 | [如有风险] |
| ... | ... | ... | ... | ... |
方法:[T恤尺码法 / 时间范围法 / 故事点法 / 基于任务法]
大小:[XS/S/M/L/XL]
故事点:[1/2/3/5/8/13/21]
时间估算:
最佳情况: X 天
最可能情况: Y 天
最坏情况: Z 天
推荐: Y 天
包含缓冲: Y + 缓冲天数
置信度: [高/中/低] (±X%)
| 风险 | 影响 | 可能性 | 缓解措施 |
|------|--------|-----------|------------|
| [风险] | +X 天 | 高/中/低 | [方法] |
剩余冲刺容量:X 天
此任务(含缓冲):Y 天
结论:✅ 适合 / ⚠️ 紧张 / ❌ 不适合 / 🔪 需要拆分
- [建议 1 — 例如,先进行探索性研究]
- [建议 2 — 例如,拆分为 3 个任务]
- [建议 3 — 例如,在承诺前澄清需求]
每个估算的结尾应包含:
每周安装数
1
仓库
首次出现
1 天前
安全审计
安装于
zencoder1
amp1
cline1
openclaw1
opencode1
cursor1
Decompose every task into concrete subtasks:
Example: "Add OAuth2 login with Google"
Subtasks:
1. Research Google OAuth2 API and decide on library [spike]
2. Create OAuth config and environment variables [small]
3. Implement OAuth callback route and token exchange [medium]
4. Create/update user record from OAuth profile [medium]
5. Handle account linking (OAuth + existing email account) [large]
6. Add OAuth login button to frontend [small]
7. Handle OAuth error states and edge cases [medium]
8. Write unit tests for OAuth service [medium]
9. Write integration tests for OAuth flow [medium]
10. Update documentation and environment setup guide [small]
11. Test in staging with real Google credentials [small]
12. Security review of token handling [small]
Rate each factor on a scale of 1-5:
| Factor | 1 (Low) | 3 (Medium) | 5 (High) |
|---|---|---|---|
| Code changes | Single file, < 50 lines | 3-5 files, ~200 lines | 10+ files, 500+ lines |
| Logic complexity | Simple CRUD, straightforward | Conditional logic, state management | Complex algorithms, concurrency |
| Dependencies | No external dependencies | Uses existing libraries/APIs | New integrations, cross-team coordination |
| Data changes | No schema changes | New columns/indexes | New tables, data migration, backfill |
| Testing effort | Easy to test, few cases | Multiple scenarios, some mocking | Complex setup, E2E, hard to reproduce states |
| Risk | Well-understood area, safe change | Some unknowns, moderate impact | Touching critical path, payment/auth/data |
| Frontend work | No UI changes | Minor UI updates | New pages/flows, responsive, accessibility |
| Domain knowledge | Team has done similar work | Some research needed | New territory for the team |
| Review/approval | Standard PR review | Security review needed | Architecture review, stakeholder sign-off |
| Deployment | Normal deploy, no special steps | Feature flag, migration | Coordinated deploy, downtime window |
Complexity Score = Average of all factors
Quick, relative sizing — best for backlog grooming and sprint planning:
| Size | Description | Typical Duration | Story Points |
|---|---|---|---|
| XS | Config change, copy update, one-liner fix | < 2 hours | 1 |
| S | Simple bug fix, small feature, well-defined scope | 2-4 hours | 2 |
| M | Feature with a few moving parts, some unknowns | 1-2 days | 3-5 |
| L | Multi-component feature, new integration, DB changes | 3-5 days | 8 |
| XL | Large feature spanning multiple systems, significant unknowns | 1-2 weeks | 13 |
| XXL | Epic-level work, needs decomposition before estimating | 2+ weeks | 21+ |
Rule : If it's XL or larger, break it into smaller tickets before estimating.
Provide optimistic, likely, and pessimistic estimates:
Estimate: Add OAuth2 Login with Google
Best case (everything goes smoothly): 3 days
Most likely (normal development pace): 5 days
Worst case (unexpected complications): 8 days
Recommended estimate: 5 days
Buffer for unknowns (20%): +1 day
Total with buffer: 6 days
Formula : Expected = (Best + 4×Likely + Worst) / 6
This is the PERT estimation technique — it weights the most likely scenario while accounting for extremes.
Relative sizing using Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21
Reference stories (calibrate with team):
1 point → Fix a typo in the UI
2 points → Add a new field to an existing form
3 points → Create a new API endpoint with validation
5 points → Implement a new feature with frontend + backend + tests
8 points → New integration with external service + error handling
13 points → Large feature with DB schema changes + migration + multiple APIs
21 points → Epic-level, needs decomposition
Rule : If you can't agree on 5 vs 8, go with 8. Estimates should err on the side of caution.
Most accurate for known work — sum up individual task estimates:
Task Breakdown: Add OAuth2 Login with Google
| # | Task | Estimate | Confidence |
|---|------|----------|-----------|
| 1 | Research & library selection | 2h | High |
| 2 | OAuth config & env vars | 1h | High |
| 3 | OAuth callback route | 3h | Medium |
| 4 | User record creation/linking | 4h | Medium |
| 5 | Account linking edge cases | 4h | Low |
| 6 | Frontend login button | 2h | High |
| 7 | Error handling | 3h | Medium |
| 8 | Unit tests | 3h | High |
| 9 | Integration tests | 4h | Medium |
| 10 | Documentation | 1h | High |
| 11 | Staging testing | 2h | Medium |
| 12 | Security review | 1h | High |
|---|------|----------|-----------|
| | **Subtotal** | **30h** | |
| | **Buffer (25% for medium/low confidence)** | **+8h** | |
| | **Total** | **38h (~5 days)** | |
| Risk | Impact on Estimate | Mitigation |
|---|---|---|
| First time doing this | +50-100% | Do a time-boxed spike first |
| Unclear requirements | +30-50% | Clarify before estimating |
| External API dependency | +25-50% | Build with mock first, integrate later |
| Cross-team coordination | +25-50% | Align schedules early, identify blockers |
| Database migration on large table | +25% | Test migration time on production-size data |
| Touching critical path (auth, payments) | +25% | Extra testing, staged rollout |
| No existing tests | +30% | Write characterization tests first |
| Legacy code / tech debt | +25-50% | Budget time for understanding + cleanup |
| Designer not available | +25% | Use existing patterns, get async feedback |
| New technology/library | +30-50% | Prototype first, add learning time |
| Regulatory/compliance requirements | +25% | Involve compliance team early |
| Multiple environments to consider | +20% | Test matrix for browsers/devices |
Base estimate: 5 days
Risk: First time using OAuth2 +2 days (40%)
Risk: Account linking complexity +1 day (20%)
Risk: No existing auth tests +1 day (20%)
Risk-adjusted estimate: 9 days
Recommended buffer: +1 day (10%)
Final estimate: 10 days (2 weeks)
Always communicate confidence alongside the estimate:
| Confidence | When | Accuracy |
|---|---|---|
| High (±10%) | Well-understood work, team has done similar, clear requirements | Estimate is very reliable |
| Medium (±25%) | Some unknowns, mostly understood, minor research needed | Estimate could vary |
| Low (±50%) | Significant unknowns, new technology, unclear requirements | Needs a spike before accurate estimate |
| Very Low (±100%) | Completely new territory, major unknowns | Don't estimate — do a spike first |
Example output:
Estimate: 5 days
Confidence: Medium (±25%)
Range: 4-7 days
Recommendation: Start with a 2-hour spike on OAuth library selection
to increase confidence to High before committing to sprint
Use past work to calibrate estimates:
# How long did similar PRs take? (time between first commit and merge)
git log --merges --oneline --grep="auth\|login\|oauth" | head -10
# Average PR size for similar features
gh pr list --state merged --search "auth OR login" --json additions,deletions,createdAt,mergedAt --limit 10 2>/dev/null
# How long did the last similar feature take?
git log --oneline --after="2025-01-01" --grep="feat" | head -20
# Cycle time for recent PRs
gh pr list --state merged --limit 20 --json number,title,createdAt,mergedAt 2>/dev/null
Similar completed work:
| Feature | Estimated | Actual | Ratio |
|---------|-----------|--------|-------|
| Password reset flow | 3 days | 4 days | 1.33x |
| Stripe integration | 5 days | 8 days | 1.60x |
| User profile page | 2 days | 2 days | 1.00x |
| Email notifications | 3 days | 5 days | 1.67x |
Average ratio: 1.40x (team typically takes 40% longer than estimated)
Applying to current estimate:
Raw estimate: 5 days
Historical adjustment (×1.40): 7 days
Determine if the work fits in the current sprint:
Sprint capacity analysis:
Sprint duration: 10 days
Team members available: 4
Days off/meetings/overhead: -2 days per person (20%)
Effective capacity per person: 8 days
Total team capacity: 32 person-days
Already committed: 20 person-days
Remaining capacity: 12 person-days
This task estimate: 7 person-days
Buffer: +2 days
Verdict: ✅ Fits in current sprint (9 of 12 remaining days)
Leaves 3 days buffer for other work/surprises
✅ FITS → Task estimate ≤ 60% of remaining capacity
⚠️ TIGHT → Task estimate is 60-80% of remaining capacity
❌ DOESN'T FIT → Task estimate > 80% of remaining capacity
🔪 SPLIT IT → Task estimate > sprint capacity (needs decomposition)
When a task is too large, suggest how to break it down:
By Layer (Vertical Slice)
Original: "Add user search feature"
Split into:
Sprint 1: Basic search API + simple UI (MVP)
Sprint 2: Advanced filters + pagination
Sprint 3: Search suggestions + analytics
By Functionality (Horizontal Slice)
Original: "Implement checkout flow"
Split into:
Ticket 1: Cart summary page (frontend only, mock data)
Ticket 2: Payment API integration (backend only)
Ticket 3: Connect frontend to backend
Ticket 4: Order confirmation + email notification
Ticket 5: Error handling + retry logic
By Risk (Spike First)
Original: "Migrate from Mailgun to SendGrid"
Split into:
Ticket 1: [Spike] Evaluate SendGrid API, test sending (time-boxed: 4h)
Ticket 2: Implement SendGrid wrapper matching current interface
Ticket 3: Update email templates for SendGrid format
Ticket 4: Migration + testing in staging
Ticket 5: Production cutover + monitoring
By User Story
Original: "OAuth login"
Split into:
Story 1: As a user, I can sign in with Google
Story 2: As a user, I can sign in with GitHub
Story 3: As an existing user, I can link my OAuth account
Story 4: As a user, I can unlink my OAuth account
📋 Estimate: [Task Title]
Size: M (Medium)
Points: 5
Time estimate: 3-5 days (most likely 4)
Confidence: Medium (±25%)
Breakdown:
- Backend API changes — 1.5 days
- Frontend updates — 1 day
- Tests — 1 day
- Review + fixes — 0.5 days
Risks:
- Depends on design mock (not yet finalized) — could add 1-2 days
- First time using this API — may need extra research time
Dependencies:
- Needs design approval before frontend work starts
- Needs staging env access for integration testing
Sprint fit: ✅ Fits with 3 days buffer remaining
📊 Effort Estimate: [Feature Name]
Estimated delivery: 2-3 weeks
Confidence: Medium
What's included:
- [Capability 1]
- [Capability 2]
- [Capability 3]
What's NOT included (future work):
- [Out of scope item 1]
- [Out of scope item 2]
Key risks:
- [Risk 1] — mitigated by [approach]
- [Risk 2] — will know more after [milestone]
Assumptions:
- Design is finalized by [date]
- No other priority changes during this period
- [Team member] is available for the full duration
Quick estimate for [task]:
- Size: S/M/L
- Time: X-Y days
- Confidence: High/Medium/Low
- Fits this sprint: Yes/No/Tight
- Risks: [one-liner]
Structure every estimate as:
Task: [Clear description of what needs to be done]
Scope: [What's included and explicitly excluded]
| # | Subtask | Estimate | Confidence | Risk |
|---|---------|----------|------------|------|
| 1 | [task] | Xh | High/Med/Low | [risk if any] |
| ... | ... | ... | ... | ... |
Method: [T-shirt / Time Range / Story Points / Task-based]
Size: [XS/S/M/L/XL]
Story Points: [1/2/3/5/8/13/21]
Time Estimate:
Best case: X days
Most likely: Y days
Worst case: Z days
Recommended: Y days
With buffer: Y + buffer days
Confidence: [High/Medium/Low] (±X%)
| Risk | Impact | Likelihood | Mitigation |
|------|--------|-----------|------------|
| [risk] | +X days | High/Med/Low | [approach] |
Remaining sprint capacity: X days
This task (with buffer): Y days
Verdict: ✅ Fits / ⚠️ Tight / ❌ Doesn't fit / 🔪 Needs splitting
- [Recommendation 1 — e.g., do a spike first]
- [Recommendation 2 — e.g., split into 3 tickets]
- [Recommendation 3 — e.g., clarify requirements before committing]
End every estimate with:
Weekly Installs
1
Repository
First Seen
1 day ago
Security Audits
Installed on
zencoder1
amp1
cline1
openclaw1
opencode1
cursor1
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
109,600 周安装