Team projects are where many CS students learn the most, and where TAs get pulled into the hardest conversations: the teammate who disappears, the student who rewrites everyone's code, the team that hasn't merged anything in two weeks. The instructor designs the project and decides grading policy, but TAs usually run the check-ins, notice problems first and mediate. Most team trouble is predictable and much of it is preventable. This page covers forming teams, setting them up, checking in, spotting trouble early, handling uneven contribution and conflict, and grading individuals fairly.
Defaults that work. If you only take four things from this page:
- Every team writes a short charter in week one: how they communicate, when they meet, what "done" means, what happens when someone misses a deadline.
- Check in with every team on a schedule, and ask the quieter members first.
- Catch problems early: a two-minute weekly team survey finds most struggling teams by the midpoint.
- Ask why before assuming a free rider. Low contribution often has a reason you can fix.
Forming teams
Team formation is usually the instructor's decision, but you may be asked to help.
- Assign teams rather than letting students choose. Students tend to describe self-chosen groups as their worst team experiences, and self-selection quietly leaves some students out.
- Three or four people, five at most. Pairs are fragile; teams of six or more usually have a passive member.
- Don't leave one student isolated, for example the only woman on a team, especially in early courses.
- Use a short survey of schedules and skills, and check that members share blocks of free time. Tools such as CATME Team-Maker can balance teams on criteria the instructor sets.
Setting teams up
- A team charter in week one: the communication channel and expected response time, meeting times, the definition of done, how code gets reviewed and merged, and what happens when someone misses a deadline.
- Roles that rotate at each milestone: for example, a coordinator who runs meetings, a reviewer who checks merges, and an integrator who keeps the main branch working.
- Light agile practice: a visible task board with small, estimated issues, and a short retrospective at each milestone. Students struggle most with breaking work into tasks and estimating how hard they are; help with that pays off.
- The rules for serious problems, in writing on day one: how a team can raise a problem, and what the instructor will do if it continues.
The check-in
A regular short meeting with each team, weekly or each sprint, is where you see trouble before it spreads. A ten-minute agenda:
| Time | What happens |
|---|---|
| 0 to 2 min | Show the board or a demo: what was merged since last time? |
| 2 to 5 min | Each person names one thing they did and one thing they'll do next. Ask the quieter members first. |
| 5 to 7 min | Blockers, risks, and what is due next. |
| 7 to 9 min | "How is the team working, 1 to 5? What would raise it by one?" |
| 9 to 10 min | Action items with owners. You write a two-line note for yourself. |
Spotting trouble early
- A weekly two-minute team survey (what went well, what didn't, how the team is working) caught most struggling teams in a software engineering course, usually by the halfway mark.
- Watch for a quiet board, the same person doing every merge, missed check-ins, and answers like "we'll catch up this weekend."
- Treat git history as a lead, not a verdict. Commit counts miss design, testing, review and pair programming. Use them to start a conversation, never to settle one.
Uneven contribution
Students name free riders as their biggest worry about group work, but low contribution often comes from something other than laziness: a heavy course load, a student who feels behind and is afraid to touch the code, or a teammate who took everything over. Ask first.
A way to open it at a check-in: "Before we look at the board, I want to check how the work is spread out. Last sprint some of you carried more than others. That happens, and it's easier to fix now than in week ten. What's getting in the way for anyone right now? Let's rebalance the next three issues before we leave."
Conflict: an escalation ladder
- The team works it out using its charter.
- It comes up at a check-in, or the weekly survey flags it.
- You mediate a short meeting. Each person gets two uninterrupted minutes, then the other sums up what they heard until the first says "yes, that's it." Then each person names one change for the week.
- The team writes a plan with owners and dates, and you check again in a week.
- You bring it to the instructor, with your notes.
- The instructor meets the team and applies the course's policy.
Skip straight to the instructor for harassment, discrimination, safety, academic integrity or a student in distress. See Handle It or Hand It to the Instructor?.
A message to the instructor: "Team 7 has had a contribution problem for two sprints. What we've done: check-ins on [dates], a mediated meeting on [date], and a written plan. It hasn't improved: two of four issues are still unassigned, and the peer evaluation flags it (attached). Could you meet with the team this week? I'll bring my notes."
Grading individuals within a team
These are the instructor's decisions, but you can suggest them:
- Peer evaluation early (as practice), at the midpoint and at the end. Rate team behavior (contributing, communicating, keeping the team on track, expecting quality), not "what percent did each person do," which favors the strongest students.
- Adjust individual grades from peer ratings, for example the team grade times a peer-rating factor. Studies of this approach found it works well as a rule.
- Keep individual parts in the grade: a contribution statement, an individual reflection, or a short individual quiz on the team's code.
Remote and asynchronous teams
- A written standup thread with a response window, instead of live meetings everyone can't make.
- Decisions recorded in the repository or wiki, not only in chat.
- The communication channel and response time named in the charter.
Further reading
Guides
- Oakley, Felder, Brent and Elhajj, "Turning Student Groups into Effective Teams" (2004) (PDF): the classic practical guide, with an appendix on handling non-contributing teammates.
- CMU Eberly Center, What are the challenges of group work and how can I address them? and its sample team contracts and peer evaluations.
- Cornell Center for Teaching Innovation, Evaluating Team Projects and Designing Longer-Term Team Projects.
- UC Berkeley GSI Teaching & Resource Center, Structure Group Work to Foster Belonging and Engagement.
- CATME Peer Evaluation and CATME Team-Maker.
Research
- Ohland et al., "The Comprehensive Assessment of Team Member Effectiveness" (2012).
- Kaufman, Felder and Fuller, "Accounting for Individual Effort in Cooperative Learning Teams" (2000).
- Layton et al., "Design and Validation of a Web-Based System for Assigning Members to Teams" (2010) (PDF).
- Hall and Buzwell, "The problem of free-riding in group projects" (2013).
- Presler-Marshall, Heckman and Stolee, "Identifying Struggling Teams in Software Engineering Courses Through Weekly Surveys" (SIGCSE 2022).
- Presler-Marshall, Heckman and Stolee, "What Makes Team[s] Work? A Study of Team Characteristics in Software Engineering Projects" (ICER 2022).
- Iacob and Faily, "Exploring the gap between the student expectations and the reality of teamwork in undergraduate software engineering group projects" (2019).
- Gitinabard et al., "Student Teamwork on Programming Projects: What can GitHub logs show us?" (2020).
Related pages: Getting a Quiet Section to Talk and Handle It or Hand It to the Instructor?.