Software Estimation Charter

Software Estimation Charter¶

1. Purpose¶

This charter defines a unified, scalable, and role-based software estimation framework. It enables early-stage scoping, funding alignment, CapEx/OpEx forecasting, and delivery team planning using T-shirt sizing, FTE-based cost models, and Agile-compatible estimation levels.

Engineering teams (Product Owners, BAs, Architects, Devs): Use Sections 1–5 for relative complexity-based estimation. Finance/PMO: Use Sections 6–Appendices for effort-to-cost modeling and forecasting.

Sections 6 onward are not applicable for engineering estimation activities and must be treated as optional cost modeling tools by PMO.

Who Should Use This Document¶

This estimation charter is intended for use by Product Owners, Business Analysts, Architects, Project Managers, and PMO Leads during the intake, roadmap planning, PI Planning, and sprint-level estimation phases. It enables consistent and defensible effort and cost forecasting, aligned with Agile delivery models.

This charter serves to bridge the gap between early-stage idea evaluation and formal delivery planning. Unlike sprint-level estimations or detailed budgeting documents, this framework supports scalable pre-commitment forecasting.

2. Core Estimation Principles¶

During early planning, defaulting to the next higher size category mitigates risk from:

• Cross-team dependencies
• Technical ambiguity
• Undefined or shifting scope

Do not interpret T-shirt sizes as a linear time progression. Estimation is comparative, not deterministic.

Risk Buffer Guidance:¶

• Low Risk (self-contained, clear scope): add 0–5% buffer
• Medium Risk (internal dependencies, minor unknowns): add 5–10% buffer
• High Risk (cross-team, vendor involvement, or unclear scope): add 10–20% buffer

For larger sizes (L, XL, XXL), or when risk level is uncertain, use the higher end of the buffer range.

3. Estimation Levels¶

Important: Story points ≠ hours.
Story points represent relative effort or complexity, not time. T-shirt sizing reflects what kind of problem is being solved, not how long it will take. Never back-convert complexity to hours directly.

Each estimation layer corresponds to a specific planning stage and should not be used interchangeably:

• T-shirt sizing → used at intake and funding stages
• Story points → used during PI Planning
• Task-level hours → used during Sprint Planning

4. T-Shirt Size Definitions¶

T-shirt sizing represents the scope and effort required for a given feature using standardized categories ranging from XS to XXL.

To ensure consistency and defensibility in effort forecasting:

• T-shirt sizing should be applied at the individual feature level, not to a group of features by default.
• Avoid aggregating multiple features into a single size unless:
• All features have similar complexity and risk profiles, and
• Dependencies and implementation paths have been jointly evaluated.
• When in doubt, size each feature independently and consolidate effort using the Role-Based Effort Matrix (Section 5).

Note: Aggregating features can obscure variations in effort and risk. Sizing at the feature level improves accuracy and allows better buffer calibration.

Do not size based on requirement counts or superficial UI/BE scope. Focus on unknowns, tech sprawl, and delivery risk.

M: “Typically 3–5 moderate requirements. May require basic integration but minimal architectural oversight.”

L: “6–8 requirements across systems. Requires design alignment, cross-team collaboration, and architectural review.”

5. Role-Based Effort Matrix (Hours)¶

The following matrix provides role-specific planning estimates (in hours) based on T-shirt sizing.
These values are intended only for early-stage scoping, funding forecasts, and team capacity planning.

Important Notes:¶

• This matrix does not track sprint-level delivery or hold teams accountable for estimated hours.
• Risk buffers should be applied at the planning stage (see Section 10) to account for early ambiguity, especially when estimating based on MVP scope.
• If the scope evolves beyond MVP assumptions or new risks emerge, estimates must be re-evaluated and funding plans adjusted.
• Final delivery effort will be refined through PI Planning (story points) and Sprint Planning (task-level hours).

Updated Table -

Note: Effort increases from L to XL reflect non-linear complexity, elevated coordination overhead, and increased regression risk typical of multi-sprint delivery scenarios.

6. CapEx vs OpEx Breakdown¶

(This section is for PMO and Finance use only. Do not apply CapEx/OpEx breakdowns during engineering estimation.)

The CapEx and OpEx splits presented below are derived from role-based activity approximations.

Examples:¶

• Roles such as Frontend Developer, Backend Developer, Architect, QA, and UX typically contribute to capitalizable activities like feature development, platform build-out, and architectural design.
• Roles including DevOps, Hypercare/Support, Security Audits, and PM oversight are considered OpEx, as they support operational or post-release activities.

These percentages are intended for estimation and planning purposes only, to help teams forecast budget allocation between capital and operational expenditure.

We are currently coordinating with the Technical Accounting team to validate and align this model with the official capitalization policy.
Once confirmed, a detailed role- and activity-based mapping will be included in Appendix D, incorporating Finance-approved classifications.

Note: The Finance team must confirm the final CapEx/OpEx classifications for financial reporting.
This model uses role-based heuristics aligned with current engineering practices and is intended for planning use only.

7. Hourly Rate Guidelines¶

(These rates are for budget modeling, not team estimation or velocity planning.)

The following rate table provides blended hourly rates used for initial project estimation.
These are planning-level benchmarks that should be refined using actual rate cards, especially for contractor-heavy or region-specific projects.

Indicative Hourly Rates by Location¶

These rates are high-level planning estimates.
Always use actual rate cards from Finance or Procurement when available.

Note: These rates are averages. Always refer to actual rate cards from Finance or Procurement wherever available.
These rates are for internal planning purposes only and must not be used for contracting, vendor negotiations, or formal financial commitments.

8. Budget Estimate Ranges¶

(This table is not to be used during backlog grooming or sprint planning. It’s intended to provide rough funding guidance during intake only.)

These cost estimates combine:

• Role-based effort hours (Section 5)
• Hourly rate assumptions (Section 7)
• CapEx vs OpEx splits (Section 6)
• Risk buffering (Section 10)

Note: The XXL buffer range has been expanded based on feedback to better reflect platform-scale project risks.
Cost ranges include both the risk buffer and standardized role-based effort estimates.
See Appendix B for example validations using custom team compositions.
All ranges already include risk buffers as outlined in Section 10, to reflect early-stage estimation uncertainty.

9. CapEx vs OpEx Classification Examples¶

Important: CapEx/OpEx is activity-driven, not purely role-driven.
Example: A Security Engineer performing feature development = CapEx;
the same engineer conducting security audits = OpEx.

10. Risk Buffering¶

Risk buffering accounts for uncertainty in early-stage estimates.
These buffers are applied to effort hours or cost estimates to reduce the risk of underfunding due to:

• Ambiguous or evolving scope
• External or cross-team dependencies
• Architecture or integration complexity
• Regulatory review or vendor delays
• Buffers do not change feature size
• Apply only after estimation
• Should not be used to “pad” velocity or manipulate scope planning

The following buffer ranges are applied based on T-shirt size:¶

For XXL epics, which typically span multiple quarters and cross-functional teams, we recommend planning with a 20–30% buffer.
This accounts for:

• Integration complexity
• Resource churn
• Architecture shifts
• Vendor delays
• Cross-functional risk exposure

Buffers do not replace formal change control; they help absorb early estimation volatility and reduce re-forecasting churn. Buffers are not an excuse for poor backlog hygiene or ambiguous acceptance criteria.

Notes:¶

• Buffers should be applied after calculating effort hours (see Section 5) and before converting to cost (see Section 8).
• Buffers are a protective measure, not a substitute for scope revalidation or governance.

Appendix A: How to Use This Document¶

Example: PO receives request for 6 screens + API + integration → L Size

• Estimate Size: “L”
• Role Effort (Section 5): ~284 hrs
• CapEx % (Section 6): ~62%
• Hourly Rates (Section 7)
• Cost Range (Section 8): $36K–$45K

Appendix B: Estimation Model Integrity – Example Validation (M & XL)¶

Medium (M) Example¶

Section 8 Benchmark: $14,880 ± 10% → Validated

Extra Large (XL) Example¶

Section 8 Benchmark: $92,160 ± 10% → Validated

Note: These examples use specific FTE mixes and hourly rates.
Actual estimates may differ slightly from Section 8’s standardized cost ranges.

If you're between two sizes (e.g., between M and L), always start with the larger size.
This approach helps prevent underestimation, ensures better sprint coverage, and absorbs unknown complexity.

Appendix C: Reconciliation of Naresh’s Table¶

Appendix D: Finance Table for CapEx & OpEx¶

Appendix D will be finalized in collaboration with Finance and PMO by Q3 FY25. Appendix E will evolve in sync with sourcing strategy updates.

Appendix E: Sample Squad Composition & Cost Models¶

Linked to Section 7: Hourly Rate Guidelines

This Appendix provides standardized reference models for estimating the cost of a typical Agile delivery squad.
These models are helpful when:

• Estimating multi-sprint delivery costs for large projects
• Budgeting at a program or feature set level without line-item breakdowns
• Needing consistent, defensible estimates for cross-functional teams with varied sourcing models

E.1 Purpose¶

Project estimators often face uncertainty in team composition during early planning.
This Appendix offers predefined cost models for standard squad configurations, based on regional and sourcing assumptions outlined in Section 7.

E.2 Standard Squad Composition (10-person team)¶

E.3 Example Squad Mix Models¶

These models allow estimators to apply blended hourly rates (from Section 7) based on planned sourcing strategies.