📋 Competition · Team Operations

Project Management
for Student Robotics Teams

A robotics season is a 6-month project with a hard deadline. Teams that manage it with clear goals, milestones, and ownership out-execute teams that improvise. No MBA required.

1
Goals & Ownership
2
Milestones
3
Sprint Planning
4
Blockers & Risk
5
Notebook Connection
// Section 01
Defining Goals and Team Ownership
Clear ownership prevents both dropped tasks and three people doing the same thing.
The core principle: every task has exactly one owner. Not zero. Not two. When two people own something, neither does it.

Season Goal vs Session Goal

Season goal — what you want to achieve by State or your last competition. Be specific: “qualify for Regionals and earn Design Award consideration.”

Competition goal — what winning looks like at the next event: “finish in the top 8 alliance seed and pass robot inspection on first attempt.”

Session goal — what you need to finish today: “intake jam rate below 5% across 20 trials.”

The Ownership Map

🏎 Driver owns
  • Competition performance and match execution
  • Pre-match checklist — knows it without looking
  • Drive team communication protocol with operator
  • Driving drill log — cycle times, error counts per session
⚙ Engineer owns
  • Robot hardware — the only person who approves mechanical changes
  • Build log: every part added, removed, or modified
  • CAD model and BOM — current, not aspirational
  • Parts sourcing and inventory tracking
  • Code — version controlled, tagged before every competition
📊 Strategist owns
  • Game analysis and autonomous selection strategy
  • Scouting records and alliance partner research
  • Judge interview plan and notebook audit
  • Team calendar — competition dates, registration deadlines, milestones

Roles for Shared Tasks

Notebook documentation, outreach, award applications, and team logistics do not belong exclusively to one role. Assign these explicitly — name a person and a deadline. If you do not assign them, they will not happen.

At the start of the season, list every deliverable you need for competition. Assign each to a person. Review at the start of every session. This is the whole system.
// Section 02
Setting Milestones and Tracking Progress
A milestone is a specific, testable outcome — not a vague intention.
📅
Bad milestone: “finish the robot.” Good milestone: “autonomous scores 3 blocks from left side in 8/10 runs.” Good milestones have a number and a test condition.

Season Milestone Template

Week Milestone Done When…
3First driveRobot crosses the field, driver control functional
5Mechanism worksPrimary mechanism scores game elements with <10% fail rate over 20 trials
8Autonomous v1At least one auton routine runs >50% consistently
11Autonomous reliable8/10 runs within target on competition-surface tiles
13Driver ready3 cycles/min, <3 errors per match period, 10+ logged sessions
15Competition readyPasses inspection dry-run, notebook audit complete, interview practiced
16Event 1Debrief written same night, rebuild list ready for next sprint
Set milestones with the team, not for the team. Everyone should know the target and why it matters. A milestone the team does not own is a milestone nobody tracks.

What to Do When You Miss a Milestone

Critical Path — What Has to Happen Before Everything Else

Some tasks cannot start until other tasks are done. These form your critical path:

When planning a sprint, identify if any of your goals are blocked by an unfinished dependency. Finish the dependency first.

// Section 03
Running a Weekly Sprint
A sprint is one week of work with a defined goal. Short cycles catch problems before they compound.

The Sprint Board

The simplest sprint board is a piece of paper or whiteboard divided into 3 columns:

☐ To Do

Tasks assigned for this sprint with an owner and a done condition.

▶ In Progress

Being worked on this session. Move here when you start it.

✓ Done

Completed and tested. Move here only when it actually meets the done condition.

Online tools (Trello, Notion, Google Sheets) work too — but a physical board visible to the whole team during practice is faster. Use what you will actually check.

The Weekly Sprint Loop

  1. Monday (or first session): pick 1–3 goals for the week, assign each to one owner with a clear success condition
  2. Each session: 5-minute check-in — what are you working on, are you blocked?
  3. End of week: sprint review — what did you finish, what did you not, and why?
  4. Plan next sprint: pull from the backlog based on current priority stack
📊
The sprint review — 10 minutes: What did we complete? What did we not complete and why? What do we do differently next week? That’s the whole meeting.

Backlog Management

The backlog is everything the team wants to build, test, or fix that is not in the current sprint. It is not a failure pile — it is a prioritized list of future work.

Scope creep is the most common failure mode. Teams that try to build every mechanism they can think of end up with a robot that does nothing reliably. A robot that does one thing well wins more matches than a robot that does five things poorly.
// Section 04
Managing Blockers and Risk
Things will go wrong. The question is whether you are surprised or prepared.
⚠️
A blocker is anything preventing a task from being completed. Identify blockers at the start of every session and resolve them before they cost you a full practice.

Common Blockers and How to Clear Them

Parts not ordered yet

Clear by: finishing the CAD model, generating the BOM, and submitting the order this session — not next session.

Code does not compile

Clear by: identifying the exact error, not guessing. Use the PID Diagnostics guide if it’s a control problem. Check git history if a recent change broke it.

Key team member absent

Clear by: making sure no single task is owned by only one person who has not shared context. Document decisions so work can continue without them.

Decision the team cannot agree on

Clear by: running the test that would settle it. If you cannot run the test yet, use a decision matrix with weighted criteria. See Engineering Notebook for decision matrix format.

Pre-Competition Risk List

One week before each competition, run through this:

Post-Competition Rebuild List

Write this the night of the competition — while you remember what actually happened:

💡
The rebuild list is the sprint plan for the following two weeks. Do not carry more than 3 items from it into active development simultaneously.
// Section 05
Project Management and the Notebook
The engineering notebook is the paper trail for everything in this guide. Here's how they connect.
📝
Every project management tool in this guide — goals, milestones, sprint reviews, decision logs, rebuild lists — is also notebook evidence. You are not doing two things. You are doing one thing that gets documented.

What Goes in the Notebook from Project Management

Season goals

Your season goal statement and first competition goal belong in entry 1 of the notebook. This is the problem definition — the most important EDP step.

Milestone tracking

When you hit a milestone, write an entry. When you miss one, write an entry explaining why and what changed. Both are engineering evidence.

Decision log

Every team decision — design direction, autonomous selection, mechanism choice — logged with who was present, what was decided, and why. This is your decision matrix evidence.

Sprint reviews

The end-of-week review — what worked, what did not, what changes next — is an iteration entry. This is the loop judges want to see repeated 5–10 times across the season.

Rebuild list

Written the night of the competition. This entry demonstrates that your team evaluates its own performance honestly — a strong indicator for the Judges Award and Excellence Award.

What Judges See When You Do This Well

A notebook that reflects good project management shows:

None of these require extra work. They require that the work you already did gets documented in real time.

STEM
Agile Project Management in Industry
Sprints, backlogs, and retrospectives are not VRC inventions. They come from Agile software development methodology, now used across engineering, product design, and research teams worldwide. Running a sprint in VRC is practicing the same process used at NASA, Boeing, and every major software company. That is what “real-world skills” actually looks like.
Related Guides
⏰ Time Management → 📅 Season Timeline → 💰 Budget & Parts Planning → 📝 Engineering Notebook → 🔬 Testing, Data & Iteration → 🏆 Tournament Pit Crew →
← ALL GUIDES