Project scoping

A scope is a bounded list of what your project will do and, equally important, what it won't.

Your project is a static multi-page web app: multiple HTML pages, CSS, and JavaScript. No server, no database, no login system. That constraint keeps the scope honest.

The scope worksheet

Fill in these four sections:

• Page list: what HTML files exist and what each one contains. Example: index.html (headline + search bar), resources.html (full list), about.html (team + why you built this). Three pages is a solid scope for four days of building.
• Must-have features: what has to be working on Demo Day for the project to feel done. Aim for 3–5 items. More than that and nothing gets polished.
• Nice-to-have features: bonuses. If you don't build them, the project is still done.
• Core user action: complete this sentence — "A visitor lands on our site and the most important thing they can do is ___." If you can't finish that sentence, the scope isn't ready yet.

Why scope creep kills projects

The instinct right now is to list everything your project could do. Resist it. Every feature added after scoping is a trade-off against finishing the core thing. "Done and working" beats "ambitious and broken" every time.

When you're tempted to add a feature mid-sprint, check: is it on the must-have list? If not, it goes to nice-to-have.

Share-out

Each team reads their core user action aloud. Post your scope worksheets on the wall — they stay up for the rest of the hackathon as a reference point.