Estimation & Sizing

Estimation & Sizing

Guidance for estimating work and sizing engagements in the CSU SG Dev Crew. The scales below are soft references, not contracts — use them as a shared vocabulary, not a stopwatch.

Parent page: Agile Delivery

---

Why we estimate

• Forecast capacity — roughly how much can the team take into a sprint or release window
• Surface risk early — large or uncertain numbers are a signal to decompose or spike, not a commitment to deliver
• Drive scope conversations — gives BAs, devs, and customers a common language to negotiate trade-offs

Estimates are not performance metrics, individual commitments, or a substitute for delivery dates.

---

Story Point Scale

We use a modified Fibonacci-like scale. The man-day column is indicative effort only — use it as a sanity check, not a conversion formula.

Story Points	Indicative Man-Days	Complexity	Rationale
1	~1	Low	Small, clear, low risk
3	~2	Low	Small complexity added
5	~3	Medium	Moderate scope + some unknowns
10	~6	Medium	Large task, coordination required
15	~10	High	High uncertainty, likely needs decomposition
20	~15	High	Near-epic, multi-role work

How to apply the scale

• Estimate complexity, not duration. Effort follows from complexity, uncertainty, and coordination cost.
• Anchor against a known story. Pick a recently completed reference story everyone agrees was a "5" and compare to it.
• If > 10 points → decompose before committing. Anything in the 15–20 range is a signal that the work is not yet ready for a sprint. Either split it into smaller stories or run a spike first.
• Re-estimate only if scope materially changes. Don't re-score a story just because it turned out to be harder than expected — that's signal for retrospectives, not for inflating points.
• Estimate as a team. Planning poker or a quick async vote works fine. Divergent estimates are a useful prompt for discussion, not something to average away.

---

Project T-Shirt Sizing

For engagement-level or roadmap-level conversations (before stories exist), use T-shirt sizes based on total indicative man-days:

Size	Indicative Man-Days
S	20–30
M	30–40
L	40–50
XL	60–100
XXL	100+

T-shirt sizes are for coarse forecasting and prioritization only — once a project is committed, break it down into stories and estimate properly using the scale above.

---

Suggested Breakdown for Agent Projects

For agent / AI engagements, it helps to estimate against two parallel tracks. Treat this as a starting checklist, not a mandatory structure:

Agent Chassis (platform & enablement)

Foundational capabilities that make the agent runnable, secure, and operable. Typical line items:

• Authentication (e.g. Entra ID)
• Authorization (role-based access)
• Agent tracing and evaluation
• Agent-level Azure resources
• DevOps / CI-CD pipelines (SIT, UAT, PROD)
• External integrations (SFTP, SharePoint, SAP, M365 connectors, etc.)
• UAT support (user feedback and iteration)
• Project coordination (liaison, customer requests, formatting)

User Story / Administration (business functionality)

The features the customer actually asked for. Typical line items:

• User onboarding (login, signup, access control)
• Domain-specific user stories (validation, parsing, LLM invocation, etc.)
• Visualization / reporting

Not every project needs every line item. Drop what doesn't apply and add what does.

---

Worked Example

A small, illustrative estimate using the scale above:

Item	Description	Story Points	Indicative Man-Days
Authentication	Entra ID authentication	3	2
DevOps / CI-CD	GitHub Action pipelines for SIT, UAT, PROD	3	2
User onboarding	Login, signup, access control	3	2
Accommodation request validation	WebUI, validation logic, LLM invoking and parsing	5	3
Total		14	~9

Full estimate workbooks for live projects live in the project's folder in the WS09 – Pro Code Agent SharePoint, not in the wiki.

---

Common Anti-Patterns

• Converting points to days mid-sprint to chase a deadline — points exist to avoid this conversation
• Re-estimating after the fact to make velocity look better
• Single-person estimates for stories that touch multiple roles
• Estimating below the cut-line without acceptance criteria — push it back to Refinement / Ready first
• Skipping decomposition on 15+ point stories because "we'll figure it out as we go"