Claude Code से वास्तविक प्रोजेक्ट की development estimation workflow

Development estimation का मतलब exact दिन guess करना नहीं है। असली project में अच्छी estimate वह होती है जो scope, assumptions, unknowns, risks, review time और verification work को साफ लिखती है, ताकि product, engineering और client एक ही evidence पर फैसला लें।

Beginners की सबसे बड़ी गलती है सिर्फ coding time estimate करना। “Profile में phone field जोड़ना है” छोटा लगता है, लेकिन इसमें database migration, API types, form validation, CSV export, audit logs, tests, release notes और reviewer availability शामिल हो सकते हैं। Migration का मतलब database schema या data बदलना है। Code rollback आसान हो सकता है, लेकिन data rollback हमेशा आसान नहीं होता, इसलिए इसे अलग से estimate करें।

Claude Code estimate को जादुई तरीके से accurate नहीं बनाता। इसकी ताकत repo पढ़ने, blast radius निकालने, assumptions और unknowns को table में रखने, और risks को visible बनाने में है। इसे confident date बनाने के लिए नहीं, missed work कम करने के लिए इस्तेमाल करें।

यह workflow official Scrum Guide के empiricism से मेल खाता है: transparency, inspection और adaptation। कई issues और PRs को track करने के लिए GitHub की milestones docs उपयोगी हैं। Relative estimation के लिए Atlassian की estimation guide देखें। Claude Code के लिए official overview और CLI reference को source मानें।

ClaudeCodeLab में आगे पढ़ने के लिए codebase navigation, bug report template और code review checklist साथ में रखें।

Estimate Inputs को अलग करें

Date बोलने से पहले पांच inputs अलग करें।

Input	सरल अर्थ	Claude Code कैसे मदद करता है
scope	क्या शामिल है और क्या नहीं	files, related features, tests
assumptions	estimate सही होने की शर्तें	product rules, permissions, release path
unknowns	अभी क्या पता नहीं	files, questions, owners
risk buffer	failure और waiting के लिए जगह	migration, auth, billing, review queue
evidence	number क्यों defendable है	past PRs, git history, test count

सिर्फ “2 दिन” मत बोलिए। बेहतर है: “low 1.5 days, likely 3 days, high 5 days अगर CRM integration scope में आया।” Range कमजोरी नहीं है। यह बताती है कि क्या पता है और क्या अभी बदल सकता है।

flowchart LR
  A["Request"] --> B["repo scan"]
  B --> C["task decomposition"]
  C --> D["assumptions table"]
  D --> E["risk register"]
  E --> F["estimate range"]
  F --> G["review prompt"]
  G --> H["client summary"]

चार realistic use cases

पहला case SaaS profile field change है। phone_number जोड़ने से DB schema, API validation, UI, search, CSV export, audit logs, privacy behavior और tests प्रभावित हो सकते हैं। अगर यह personal data है, तो log masking और delete/export rules भी estimate में आएंगे।

दूसरा case legacy screen bug fix है। “Filter काम नहीं कर रहा” पुराने query helpers, cache, URL parameters, fixtures और E2E checks से जुड़ा हो सकता है। Claude Code से direct fix मांगने से पहले impact और verification route बनवाएं।

तीसरा case consulting proposal या internal DX request है। Client कहता है “admin screen चाहिए”, लेकिन real scope में login, roles, audit trail, CSV, notifications, permission handover और operations manual आ सकते हैं। Claude Code existing issues और code पढ़कर request में छूटी work items दिखा सकता है।

चौथा case monetized content site है। एक छोटा MDX change भी page speed, internal links, OGP, structured data, localization, screenshots और AdSense-friendly layout review शामिल कर सकता है। Publishing quality सिर्फ text edit नहीं है।

Common failure cases

पहला failure है first guess को commitment बना देना। Repo scan से पहले “शायद एक दिन” सिर्फ hope है। जब यह stakeholder तक पहुंच जाता है, तो बाद की realistic estimate delay जैसी दिखती है।

दूसरा failure है review और verification को zero मानना। छह घंटे की implementation के बाद भी tests, review fixes, staging check, release notes और deploy coordination लग सकते हैं।

तीसरा failure है unknowns को vague buffer में छिपाना। “30% जोड़ दो” तब तक उपयोगी नहीं है जब तक reason साफ न हो: external API unclear, rollback plan missing, reviewer queue, fixtures missing, या product rule ambiguous।

चौथा failure है AI number को बिना evidence मान लेना। अगर Claude Code “3 days” कहता है लेकिन files, past PRs, tests और risks नहीं देता, तो वह सिर्फ polished prose है।

Step 1: Read-only repo scan

पहले repository की shape देखें। अभी edit न करें।

git status --short
git branch --show-current
git rev-parse --show-toplevel

rg --files \
  -g '!*node_modules*' \
  -g '!dist' \
  -g '!build' \
  -g '!coverage' \
  -g '!*.lock' \
  | sort \
  | head -200

find . -maxdepth 3 \( \
  -name package.json -o \
  -name pyproject.toml -o \
  -name go.mod -o \
  -name Cargo.toml -o \
  -name AGENTS.md -o \
  -name CLAUDE.md -o \
  -name README.md \
\) -print

अब Claude Code से read-only map मांगें।

claude -p "
Run a read-only repo scan.
Do not edit, create files, or add dependencies.

Return:
1. apps, packages, and services
2. runtime, test, and build entrypoints
3. generated folders to ignore
4. 10 files that must be read for this estimate
5. reasons this task cannot yet be estimated
"

Step 2: Task decomposition

Work को ऐसे units में बांटें जिन्हें review और verify किया जा सके।

claude -p "
Task: Let users add, view, and edit a phone number on their profile.

Break this into reviewable work items.
For each item include:
- name
- likely files
- implementation work
- test work
- definition of done
- size: small, medium, or large

Also list out-of-scope items.
Separate guessed product rules as assumptions.
"

आमतौर पर DB, API, UI, tests और release work बनते हैं। अगर कोई item एक PR में review नहीं हो सकता, तो estimate से पहले उसे split करें।

Step 3: Assumptions table

Assumptions बाद में plan तोड़ते हैं, इसलिए उन्हें लिखें।

| ID | Assumption | Why it matters | Owner | Confirm by |
| --- | --- | --- | --- | --- |
| A1 | Phone number is optional | Required fields change validation and migration | PM | 2026-06-05 |
| A2 | Web only, no mobile app change | Mobile release adds review and store delay | PM | 2026-06-05 |
| A3 | Existing user rows stay null | Backfill work is not included | Tech lead | 2026-06-06 |

claude -p "
Review this assumptions table.
Find assumptions that could break the estimate.
Add missing owners, deadlines, and questions.
Move anything risky into a risk register.
"

Step 4: Risk register

Risk register वह table है जिसमें लिखा जाता है कि plan किस वजह से बिगड़ सकता है।

| Risk | Trigger | Impact | Mitigation | Buffer |
| --- | --- | --- | --- | --- |
| DB rollback is unclear | migration changes existing rows | High | dry-run and rollback plan | 0.5-1 day |
| External CRM stores phone | CRM field mapping appears | Medium | check integration owner | 0.5 day |
| Review queue is full | no reviewer within 24h | Medium | book review slot early | 1 day |
| Test data is missing | no edge-case users | Medium | create fixtures first | 0.5 day |

Buffer laziness के लिए नहीं है। यह unknowns, failures और waiting time को plan में जगह देता है। Auth, billing, private data, delete flows और migrations को pure UI work से ज्यादा explicit risk चाहिए।

Step 5: Estimate range calculate करें

यह script copy-paste करके चल सकती है।

// estimate-range.mjs
const tasks = [
  { name: "Repo scan and design check", hours: 2, risk: 1.1 },
  { name: "DB migration and schema", hours: 4, risk: 1.4 },
  { name: "API contract and validation", hours: 5, risk: 1.2 },
  { name: "Profile UI update", hours: 6, risk: 1.2 },
  { name: "Tests and fixtures", hours: 5, risk: 1.3 },
  { name: "Review fixes and release note", hours: 3, risk: 1.2 },
];

const base = tasks.reduce((sum, task) => sum + task.hours, 0);
const likely = tasks.reduce((sum, task) => sum + task.hours * task.risk, 0);
const low = Math.max(base * 0.8, base - 4);
const high = likely * 1.35;

const day = 6;
const format = (hours) => `${hours.toFixed(1)}h / ${(hours / day).toFixed(1)}d`;

console.log(`Low:    ${format(low)}`);
console.log(`Likely: ${format(likely)}`);
console.log(`High:   ${format(high)}`);

node estimate-range.mjs

Multiplier को truth न मानें। risk: 1.4 का मतलब है “यह area uncertain है।” अगर बदलें, तो Issue या PR में reason लिखें।

Step 6: Critical review prompt

Client को भेजने से पहले Claude Code से estimate पर attack करवाएं।

You are a critical project estimation reviewer.

Review this estimate before I share it with a client.
Find:
1. hidden scope
2. weak assumptions
3. missing tests
4. missing rollout or rollback work
5. fake precision
6. tasks that should be split

Return findings first.
Then provide a revised low / likely / high range.
Do not make the estimate look more certain than the evidence supports.

Prompt की wording मायने रखती है। “इसे सुंदर बना दो” से सुंदर text मिलेगा। “Critical review” से useful friction मिलेगा।

Step 7: Client-facing summary

Internal notes को छोटी decision document में बदलें।

# Development Estimate Summary

## Scope
- Add optional phone number to user profile.
- Update DB schema, API validation, profile UI, and tests.
- Include release note and manual verification.

## Not included
- SMS notification.
- Mobile app release.
- Historical data backfill.
- CRM integration changes unless confirmed.

## Estimate
- Low: 3 business days
- Likely: 4-5 business days
- High: 7 business days if CRM or migration rollback work expands

## Assumptions
- Phone number is optional.
- Web only.
- Existing users can keep the value empty.

## Risks
- DB rollback plan must be reviewed before implementation.
- Reviewer availability may add one calendar day.

## Next decision
- Confirm whether CRM and mobile app are in scope by 2026-06-05.

Estimate को GitHub Issues या milestone में रखें ताकि actual result से compare हो सके।

## Estimate
- Low:
- Likely:
- High:
- Confidence: Low / Medium / High

## Scope
- [ ]

## Out of scope
- [ ]

## Assumptions
- [ ]

## Risks
- [ ]

## Verification
- [ ] Unit tests:
- [ ] Integration tests:
- [ ] Manual check:

## Actual result
- Started:
- Merged:
- Extra work found:
- What to adjust next time:

Actual result section team learning का हिस्सा है। अगली estimate opinion नहीं, evidence से शुरू होती है।

Consulting CTA

Estimation consulting के लिए strong topic है, क्योंकि हर team को इसे अपने repo, client language और rules के हिसाब से adapt करना पड़ता है। ClaudeCodeLab estimation templates, Claude Code review prompts, PR checklists और rollout rules design करने में मदद कर सकता है। अगर आप इसे अपने issues या proposal process से जोड़ना चाहते हैं, तो Claude Code training और consultation पर context भेजें।

Hands-on result

Masa ने यह workflow एक छोटे profile-field change पर test किया। शुरुआती gut estimate “आधा दिन UI” था। Repo scan के बाद DB schema, API validation, CSV export, audit logs, tests और review queue सामने आए। Client-ready range likely 4-5 business days बनी, और CRM शामिल होने पर high case 7 days था। Claude Code की value date predict करने में नहीं थी; value hidden files और unknowns जल्दी दिखाने में थी।