marathon/docs/ESTIMATION.md

Estimation and Prioritization

This document defines how r3t Studios sizes, estimates, and prioritizes work. Our approach is grounded in Lean Software Development principles, adapted for indie game development.

---

Lean Principles as Evaluation Questions

Every sizing and prioritization decision should be evaluated through these questions:

Principle	Evaluation Questions
Eliminate Waste	Does this reduce waste? Is this the simplest solution? Are we building something nobody needs?
Amplify Learning	What will we learn from this? Does this reduce uncertainty? Should we prototype first?
Decide as Late as Possible	Do we have enough information to commit? Can this decision be deferred responsibly?
Deliver as Fast as Possible	What's the smallest increment that delivers value? What's blocking flow?
Empower the Team	Do I have what I need to do this? Who else should be involved in this decision?
Build Integrity In	Are we building quality in from the start? Will this create technical debt?
Optimize the Whole	Does this improve the whole system or just one part? Are we sub-optimizing?

---

Sizing

We use powers of 2 for effort estimation: 1, 2, 4, 8, 16, 32

This scale is intentionally coarse. Precision in estimation is waste—we optimize for fast, good-enough decisions.

Size	Points	Description
XS	1	Trivial change. A few lines, minimal risk. Less than 2 hours.
S	2	Small task. Well-understood, limited scope. Half a day.
M	4	Medium task. Some complexity or unknowns. About 1 day.
L	8	Large task. Multiple components or significant complexity. 2-3 days.
XL	16	Very large. Should probably be an epic. ~1 week.
XXL	32	Epic-scale work. Multi-phase refactoring or major features. 2-4 weeks.

Sizing Guidelines

Before assigning a size, ask:

• Eliminate Waste: Is this the smallest scope that delivers value?
• Deliver Fast: Can we break this down further?
• Amplify Learning: Is there uncertainty that inflates the estimate? Should we prototype/spike first?
• Optimize the Whole: Does the estimate account for integration, testing, and platform testing (iOS + macOS)?

If the size is XL (16) or larger:

This is epic territory. Break it into phases or sub-tasks. An XL/XXL indicates the work is not well-understood or needs careful sequencing. Consider writing an RFC for XXL work.

---

Priority

Priority is based on Cost of Delay—the impact of not doing this work now.

Label	Priority	Cost of Delay Profile	Description
P0	Critical	Expedite	Game-breaking bug, crash on launch, data loss, or blocks release. Drop everything. Every hour matters.
P1	High	Fixed Date / High Value	Release blocker, community-visible bug, or deadline-driven (demo, event, content creator access). Do this sprint.
P2	Medium	Standard	Normal feature work, engine improvements, content additions. Standard backlog work—prioritize by WSJF.
P3	Low	Intangible	Nice-to-have, polish, research, experiments. Do when capacity allows or inspiration strikes.

Priority Guidelines

Before assigning a priority, ask:

• Eliminate Waste: Should we do this at all? What happens if we never do it?
• Amplify Learning: Does doing this first reduce uncertainty for other work?
• Decide Late: Do we need to commit now, or can we learn more first? (Especially important for game design decisions)
• Optimize the Whole: Does this unblock other high-value work? Does it improve both engine (Marathon) and game (Aspen)?

---

WSJF (Weighted Shortest Job First)

For backlog ordering within a priority tier, we use WSJF:

WSJF = Cost of Delay / Job Size

Where Cost of Delay considers:

• Player Value: Does this improve player experience, immersion, or enjoyment?
• Time Criticality: Content creator previews, demo deadlines, platform submission windows
• Risk Reduction: Tech debt payoff, engine stability, enables future content/features

Higher WSJF = do it first.

Example (Game Dev Context)

Item	Player Value	Time Criticality	Risk Reduction	CoD	Size	WSJF
Spatial Audio	8	6	4	18	8	2.25
Agent AI Polish	6	2	2	10	16	0.63
Fix iOS Crash	10	10	8	28	4	7.0
Low-Poly Tree Assets	4	2	1	7	2	3.5

Order: iOS Crash (7.0), Tree Assets (3.5), Spatial Audio (2.25), AI Polish (0.63)

The crash gets fixed first (high value, small effort), then quick content wins, then larger features.

---

Area Labels and Work Types

Our area/ labels map to different types of work:

Area	Typical Work	Considerations
area/core	Engine foundation	High risk—test thoroughly, affects everything
area/rendering	Graphics, PBR, cameras	Test on iOS + macOS, check DPI scaling
area/audio	Spatial audio, sound	Requires device testing, earbuds vs speakers
area/networking	P2P, CRDT sync	Test with poor connections, edge cases
area/platform	iOS/macOS specific	Platform-specific testing required
area/simulation	Agent behaviors, AI	Needs playtesting, emergent behavior testing
area/content	Art, audio assets, dialogue	Artistic review, asset pipeline testing
area/ui-ux	Menus, HUD, accessibility	Needs user testing, various screen sizes
area/tooling	Build, CI/CD, dev tools	Verify on fresh checkout
area/docs	Technical specs, RFCs	Keep updated as code evolves
area/infrastructure	Deployment, hosting	Test in staging before production
area/rfc	Design proposals	Gather feedback before committing

---

Quick Reference

When Sizing

1. Compare to recent similar work
2. Use the Lean questions to validate scope
3. If XL or larger, consider making it an epic with sub-tasks
4. Bias toward smaller—deliver fast, learn, iterate
5. Remember: estimates are for ordering work, not commitments

When Prioritizing

1. Is it game-breaking (crash/data loss)? If yes, P0—do it now
2. Is there a deadline (demo/release)? If yes, P1—this sprint
3. Otherwise, score WSJF and order the backlog as P2
4. Nice-to-haves and experiments go to P3
5. Re-evaluate priorities weekly—inspiration and context change

For Solo Work

• Batching: Group similar work (all rendering tasks, all iOS fixes) to minimize context switching
• Flow: Protect deep work time—don't interrupt XL tasks with small P3 items
• Momentum: Sometimes doing a quick XS/S task builds momentum for harder work
• Inspiration: If you're excited about a P3 item, that's valuable—creative energy matters in game dev

---

References

• Poppendieck, Mary & Tom. Lean Software Development: An Agile Toolkit. Addison-Wesley, 2003.
• Reinertsen, Donald G. The Principles of Product Development Flow. Celeritas Publishing, 2009.
• Cost of Delay - Black Swan Farming
• WSJF - Scaled Agile Framework