Below is a complete **Group Project Coordination System** tailored to the provided context: **Software Engineering Capstone — CS 401; 5-person senior undergraduate teams; 12-week full-stack web app MVP, client presentation, and technical report**. # Group Project Coordination System ## Software Engineering Capstone — CS 401 --- # 🧩 SECTION 1: TEAM FORMATION STRATEGY ## Approach A — Skill-Balanced Formation ### Purpose This approach forms teams so that each 5-member team has enough technical, managerial, communication, and documentation capacity to ship a working MVP, present to a client, and produce a technical report. ## Key Skill Categories Each student self-assesses across the following skill categories: | Skill Category | Why It Matters in CS 401 | | --------------------------------------- | --------------------------------------------------------------------------------------------- | | Frontend Development | Needed for usable UI, client demo, accessibility, and user-facing MVP quality | | Backend/API Development | Needed for business logic, authentication, data processing, and integration | | Database Design | Needed for data modeling, persistence, migrations, queries, and reliability | | DevOps/Deployment | Needed for CI/CD, hosting, environment management, and production readiness | | UI/UX Design | Needed for client-facing quality, usability testing, wireframes, and presentation polish | | Testing/QA | Needed for unit tests, integration tests, acceptance testing, and bug tracking | | Technical Writing | Needed for architecture documentation, technical report, user guide, and final submission | | Project Management/Client Communication | Needed for sprint planning, scope control, meeting notes, client updates, and risk management | ## Pre-Team Self-Assessment Survey Students complete this survey **5–7 days before team formation**. **Scale:** 1 = No experience / not confident 2 = Limited experience 3 = Moderate experience 4 = Strong experience 5 = Highly confident; could lead others | Question | Skill Revealed | | -------------------------------------------------------------------------------------------------- | ----------------------- | | I can independently build and debug a frontend interface using modern web technologies. | Frontend Development | | I can design and implement backend APIs, authentication, or server-side business logic. | Backend/API Development | | I can design a relational or document database schema and write queries effectively. | Database Design | | I can deploy a web application, configure environments, or troubleshoot hosting issues. | DevOps/Deployment | | I can translate user/client needs into wireframes, workflows, or usability improvements. | UI/UX Design | | I can write, organize, and edit a professional technical report or system documentation. | Technical Writing | | I can coordinate tasks, manage deadlines, communicate with stakeholders, and keep a team on track. | Project Management | Optional short-answer question: > Which one skill do you most want to develop during this project, even if it is not currently your strongest area? ## Instructor Team-Building Algorithm ### Step 1: Create Skill Profiles For each student, record their top 2 skills and bottom 2 skills. Example: | Student | Top Skills | Low Skills | Notes | | --------- | ----------------- | ----------------- | ---------------------------- | | Student A | Backend, Database | Presentation, UX | Strong technical contributor | | Student B | PM, Writing | DevOps, Backend | Good coordinator | | Student C | Frontend, UX | Database, Testing | Demo/UI strength | ### Step 2: Identify Critical Coverage Areas Each 5-person team must have at least one student rated **4 or 5** in each of the following: 1. Frontend Development 2. Backend/API Development 3. Database Design 4. Project Management/Client Communication 5. Technical Writing 6. Testing/QA or DevOps/Deployment A team should not be approved if it lacks both Testing/QA and DevOps capability. ### Step 3: Distribute High-Scorers Avoid placing all top technical students on one team. Use this distribution rule: | Skill | Distribution Rule | | ----------------------- | ----------------------------------------------------------------------------------------- | | Frontend | At least one 4–5 scorer per team where possible | | Backend | At least one 4–5 scorer per team where possible | | PM/Client Communication | At least one 4–5 scorer or strong communicator per team | | Writing | At least one 4–5 scorer per team | | DevOps | One 4–5 scorer per team where possible, or pair teams with limited DevOps support clinics | | Testing | At least one 3+ scorer per team | ### Step 4: Manage Dominant Personalities Ask students to optionally answer: > I prefer to take charge when a team is uncertain. > Scale: 1 = rarely; 5 = almost always Formation rules: * Avoid placing multiple “5” leadership-preference students on the same team unless they have complementary roles. * Pair dominant technical leaders with strong project managers who can structure discussion. * Avoid placing quiet students together without at least one strong communicator. * Use role charters to prevent one student from becoming unofficial lead of everything. ### Step 5: Avoid Critical Skill Deficiency Before finalizing teams, flag any team with: * No backend-capable member. * No frontend-capable member. * No student willing to own project coordination. * No student comfortable with writing/report production. * More than two students with very low availability. * More than two students who selected the same “I strongly prefer not to do this” skill. Instructor action: * Swap one member. * Require a mentor pairing with another team. * Provide targeted scaffolding, such as a DevOps workshop or writing clinic. * Adjust scope only if the team has unavoidable structural constraints. ## Team Compatibility Matrix Template | Proposed Team | Frontend | Backend | Database | DevOps | UX/UI | Testing | Writing | PM/Client | Risk Notes | Approved? | | ------------- | -------: | ------: | -------: | -----: | ----: | ------: | ------: | --------: | ----------- | ----------- | | Team 1 | 5, 3 | 4 | 3 | 2 | 5 | 3 | 4 | 5 | Weak DevOps | Conditional | | Team 2 | 4 | 5, 3 | 4 | 3 | 2 | 4 | 3 | 4 | Balanced | Yes | | Team 3 | 2 | 4 | 5 | 4 | 3 | 2 | 5 | 2 | Weak PM | Needs swap | ### Best Suited For * Senior capstone courses. * Large classes where instructors need equitable team quality. * Projects with technical dependencies and real client expectations. * Classes where student skill variation is significant. ### Pros 1. Produces more evenly capable teams. 2. Reduces the risk of one team lacking essential technical skills. 3. Helps instructors justify team formation transparently. ### Cons 1. Requires survey analysis before teams are formed. 2. Students may exaggerate or underestimate abilities. 3. Interest and motivation may be secondary to skill coverage. ### Implementation Timeline | Time Before Project Start | Action | | ------------------------- | ---------------------------------------------- | | 7 days | Release skill survey | | 5 days | Close survey | | 4 days | Instructor creates draft teams | | 2 days | Instructor reviews risks and makes adjustments | | Project start | Teams announced and Team Charter assigned | --- ## Approach B — Interest-Aligned Formation ### Purpose This approach forms teams based on what students are motivated to contribute, not only what they already know. It is useful when student engagement and ownership are major course goals. ## Interest/Motivation Survey Students complete this survey before sign-ups. **Scale:** 1 = Not interested 2 = Slightly interested 3 = Neutral 4 = Interested 5 = Very interested / eager to contribute | Question | Motivation Profile Revealed | | ------------------------------------------------------------------------------------------------------- | ---------------------------------- | | I am excited to interact with the client, clarify requirements, and translate needs into project scope. | Client-facing / Product-minded | | I am excited to design the architecture, backend logic, database, or core system structure. | Technical Systems Builder | | I am excited to create a polished user interface and improve user experience. | UX/UI-Focused Builder | | I am excited to test, debug, refactor, and improve reliability. | Quality-Focused Executor | | I am excited to coordinate schedules, organize tasks, track progress, and keep the team accountable. | Project Organizer | | I am excited to write the technical report, document decisions, and prepare the final presentation. | Documentation / Communication Lead | Optional short answer: > What kind of project problem would make you excited to work hard for 12 weeks? ## Motivation Profiles | Profile | Strength | Needs Complement | | ------------------------- | -------------------------------------- | ------------------------------ | | Big-Picture Thinker | Vision, architecture, client framing | Detail-oriented executor | | Detail-Oriented Executor | Reliability, implementation discipline | Product/context thinker | | UI/UX Enthusiast | Client demo quality, usability | Backend/data support | | Technical Systems Builder | Core implementation | Documentation and user empathy | | Project Organizer | Accountability and planning | Technical depth | | Communication Lead | Presentation/report quality | Implementation ownership | ## Forming Teams Around Complementary Motivation Each team should ideally include: 1. One student excited about product/client communication. 2. One student excited about backend or architecture. 3. One student excited about frontend or UX. 4. One student excited about quality/testing/deployment. 5. One student excited about coordination or documentation. Students may fill multiple profiles, but no team should be composed entirely of the same motivation type. ## Three-Step Self-Selection Process with Guardrails ### Step 1: Open Sign-Ups Students view project themes or client briefs and sign up for preferred project teams. Rules: * Maximum 5 students per team. * Students must list primary and secondary role interests. * Each team must complete a preliminary “motivation coverage” table. Example: | Team | Client/Product | Backend | Frontend/UX | Testing/QA | PM/Docs | Risk | | ---- | -------------- | -------- | ----------- | ---------- | ------- | -------------- | | A | Sara | Deniz | Mina | — | Ali | No QA owner | | B | — | Can, Ece | Ece | Murat | Leyla | No client lead | ### Step 2: Instructor Review Instructor reviews: * Team size. * Motivation diversity. * Critical role gaps. * Overconcentration of friends or prior partners. * Whether any team has no implementation-focused students. ### Step 3: Final Adjustments Instructor may: * Move one student from an overfull team. * Ask for volunteers to switch. * Assign missing roles. * Approve conditional teams only after they identify a plan for role gaps. ## Best Suited For * Courses where student motivation is a major success factor. * Project-based classes with multiple project/client options. * Cohorts with reasonably comparable technical ability. * Teams expected to self-direct. ## Pros 1. Increases ownership and motivation. 2. Gives students agency in choosing work they care about. 3. Helps align roles with intrinsic interest. ## Cons 1. Can produce technically imbalanced teams. 2. Popular projects may become overloaded. 3. Friend groups may self-select without sufficient diversity. ## Implementation Timeline | Time Before Project Start | Action | | ------------------------- | ----------------------------------- | | 10 days | Release project/client descriptions | | 8 days | Release motivation survey | | 6 days | Open sign-ups | | 4 days | Instructor reviews teams | | 2 days | Adjustments finalized | | Project start | Teams confirmed | --- ## Approach C — Random + Recalibration ### Purpose This approach uses random assignment for fairness while creating a formal safety valve for serious incompatibility. ## Structured Random Assignment Process ### Step 1: Collect Minimal Constraints Before random assignment, students submit: * Known schedule constraints. * Prior unresolved team conflict with specific students. * Accessibility or accommodation-related needs. * Hard technical constraints, such as no laptop access or limited development environment compatibility. ### Step 2: Randomize Teams Instructor randomly assigns students into teams of 5. Rules: * Avoid placing students together if there is a documented prior serious conflict. * Avoid teams where all students have similar schedule limitations. * Avoid isolating the only student with a specific accommodation need if support is required. ### Step 3: Week 1 Recalibration Window During Week 1, students complete: * Team Charter. * Role assignment. * Initial project plan. * First working session. Students may submit a formal Recalibration Request only if they believe the team structure will prevent success. ## Recalibration Request Form **Deadline:** End of Week 1 **Submitted to:** Instructor only **Confidentiality:** Shared only as needed to resolve the issue | Field | Required Student Response | | --------------------------- | --------------------------------------------------------------------------------------------------------- | | Structural Concern | Describe the specific team composition issue. Avoid personality labels. | | Evidence | Provide concrete observations from Week 1, such as missed meetings, role gaps, or incompatible schedules. | | Attempted Resolution | Describe what the team tried before submitting this request. | | Requested Instructor Action | State whether you request mediation, role adjustment, schedule intervention, or team reassignment. | ### Threshold for Instructor Action Instructor acts only if one or more are true: 1. Two or more members independently report the same structural issue. 2. A critical project role has no owner after documented attempts. 3. Schedule incompatibility prevents regular synchronous work. 4. There is evidence of hostility, exclusion, academic misconduct risk, or harassment. 5. A student’s ability to participate is materially affected by accessibility or documented personal constraints. ## Best Suited For * Classes where fairness and mixing social groups are priorities. * Instructors who want to avoid popularity-based team formation. * Cohorts with similar skill levels. * Situations where students need practice working with unfamiliar peers. ## Pros 1. Perceived as fair and impartial. 2. Prevents cliques from dominating team formation. 3. Mimics workplace conditions where teams are assigned. ## Cons 1. May create uneven skill distribution. 2. Can reduce student ownership. 3. Requires careful Week 1 monitoring. ## Implementation Timeline | Time Before Project Start | Action | | ------------------------- | --------------------------- | | 5 days | Collect constraints | | 3 days | Randomize teams | | 2 days | Check for severe conflicts | | Project start | Announce teams | | End of Week 1 | Recalibration window closes | --- # 🎭 SECTION 2: ROLE ASSIGNMENT FRAMEWORK For a 5-member team, use **six project roles**, with one student holding a primary role and one secondary role where needed. Some roles may be paired or shared. ## Role 1: Product & Client Liaison ### 🎯 Core Responsibilities * Schedule and prepare client meetings. * Convert client needs into user stories and acceptance criteria. * Maintain the product backlog with prioritized features. * Track scope changes and confirm them with the team and instructor. * Prepare client-facing progress updates. * Ensure the MVP solves the agreed problem, not just a technical problem. * Gather client feedback after demos and translate it into action items. ### 🤝 Collaboration Touchpoints | Collaborates With | Frequency | Purpose | | -------------------------- | --------- | ------------------------------------------------ | | Project Coordinator | Weekly | Align scope with timeline | | Architecture/Backend Lead | Weekly | Confirm feasibility | | Frontend/UX Lead | Weekly | Validate user workflows | | Report & Presentation Lead | Biweekly | Capture client rationale for report/presentation | ### 📊 Deliverables Owned * Client meeting notes. * Requirements document. * User stories and acceptance criteria. * Scope change log. * Client demo feedback summary. ### ⚠️ Common Failure Modes 1. **Acts as messenger, not translator** Warning sign: client requests are copied into the backlog without clarification. 2. **Allows scope creep** Warning sign: new features are accepted without timeline impact analysis. 3. **Under-communicates with client** Warning sign: team guesses client expectations. ### 💡 Success Indicators * Client expectations are clear. * MVP scope is stable and documented. * Team can explain why each feature matters. * Client feedback is incorporated systematically. --- ## Role 2: Project Coordinator & Scrum Facilitator ### 🎯 Core Responsibilities * Create and maintain the 12-week project schedule. * Run weekly team meetings. * Track tasks in Trello, Jira, GitHub Projects, Notion, or equivalent. * Maintain sprint goals and sprint retrospectives. * Identify blockers and assign owners. * Ensure milestones are submitted on time. * Alert instructor early when risk becomes significant. ### 🤝 Collaboration Touchpoints | Collaborates With | Frequency | Purpose | | ------------------------ | ------------- | -------------------------------- | | All roles | Weekly | Task tracking and accountability | | Product & Client Liaison | Weekly | Scope and client commitments | | QA/DevOps Lead | Weekly | Release readiness | | Instructor | At milestones | Risk reporting | ### 📊 Deliverables Owned * Project schedule. * Weekly meeting notes. * Sprint board. * Risk register. * Milestone submission checklist. ### ⚠️ Common Failure Modes 1. **Becomes team boss instead of facilitator** Warning sign: assigns tasks without discussion. 2. **Tracks tasks but not blockers** Warning sign: board looks organized but progress stalls. 3. **Avoids hard conversations** Warning sign: missed deadlines are normalized. ### 💡 Success Indicators * Everyone knows what they own each week. * Blockers are visible within 48 hours. * Milestones are rarely surprising. * Workload is distributed transparently. --- ## Role 3: Architecture & Backend Lead ### 🎯 Core Responsibilities * Define backend architecture and API structure. * Own server-side implementation standards. * Coordinate database schema with the Data Lead or assigned teammate. * Review backend pull requests. * Ensure authentication, authorization, validation, and error handling are implemented. * Maintain API documentation. * Coordinate integration points with frontend. ### 🤝 Collaboration Touchpoints | Collaborates With | Frequency | Purpose | | ----------------- | ------------------------------- | ----------------------------- | | Frontend/UX Lead | Twice weekly during development | API contracts and integration | | QA/DevOps Lead | Weekly | Testing and deployment | | Product Liaison | Weekly | Requirements feasibility | | Report Lead | Milestones | Architecture documentation | ### 📊 Deliverables Owned * Architecture diagram. * API specification. * Backend codebase. * Database integration notes. * Security and validation notes. ### ⚠️ Common Failure Modes 1. **Builds too much infrastructure too early** Warning sign: no user-facing feature works by Week 4. 2. **Does not document APIs** Warning sign: frontend waits for verbal explanations. 3. **Centralizes backend knowledge** Warning sign: only one person can fix server issues. ### 💡 Success Indicators * APIs are documented and testable. * Backend supports core MVP workflows. * Frontend integration is not blocked by ambiguity. * Backend decisions are explained in the technical report. --- ## Role 4: Frontend & UX Lead ### 🎯 Core Responsibilities * Create wireframes or screen flow diagrams. * Implement core user-facing views. * Ensure frontend code is organized and reusable. * Coordinate API integration with backend. * Conduct lightweight usability testing. * Maintain consistent visual and interaction patterns. * Prepare demo-ready user flows. ### 🤝 Collaboration Touchpoints | Collaborates With | Frequency | Purpose | | ----------------- | ------------------------------- | ------------------------------------- | | Product Liaison | Weekly | Confirm user needs | | Backend Lead | Twice weekly during integration | API usage | | QA/DevOps Lead | Weekly | Browser testing and release readiness | | Presentation Lead | Final 3 weeks | Demo flow and visuals | ### 📊 Deliverables Owned * Wireframes. * Frontend implementation. * User flow map. * Usability feedback summary. * Demo script support. ### ⚠️ Common Failure Modes 1. **Prioritizes polish before core functionality** Warning sign: UI looks good but workflows do not complete. 2. **Waits passively for backend** Warning sign: frontend progress stops instead of using mock data. 3. **Ignores usability** Warning sign: users need verbal instructions to complete tasks. ### 💡 Success Indicators * MVP workflows are easy to demonstrate. * UI supports real user stories. * Integration problems are identified early. * Client can understand product value quickly. --- ## Role 5: QA, Testing & DevOps Lead ### 🎯 Core Responsibilities * Define the team’s testing strategy. * Set up deployment pipeline or hosting environment. * Maintain release checklist. * Track bugs and verify fixes. * Ensure basic unit, integration, or end-to-end tests exist. * Confirm the MVP runs in a clean environment. * Prepare backup demo plan. ### 🤝 Collaboration Touchpoints | Collaborates With | Frequency | Purpose | | ------------------- | ------------- | ----------------------------- | | Backend Lead | Weekly | API testing and deployment | | Frontend Lead | Weekly | UI testing and browser checks | | Project Coordinator | Weekly | Bug prioritization | | Presentation Lead | Final 2 weeks | Demo reliability | ### 📊 Deliverables Owned * Test plan. * Bug tracker. * Deployment guide. * Release checklist. * Final deployed MVP link. * Backup demo package. ### ⚠️ Common Failure Modes 1. **Testing starts too late** Warning sign: first serious test happens in Week 10. 2. **Deployment depends on one laptop** Warning sign: app only works locally. 3. **Bug tracker is ignored** Warning sign: bugs are discussed repeatedly but not assigned. ### 💡 Success Indicators * App is deployable before final week. * Critical bugs are tracked and resolved. * Demo has a backup plan. * Technical report includes credible testing evidence. --- ## Role 6: Technical Report & Presentation Lead ### 🎯 Core Responsibilities * Maintain the report outline from Week 2 onward. * Collect technical decisions, diagrams, and evidence throughout the project. * Coordinate final presentation structure. * Ensure report sections have owners and deadlines. * Edit for coherence, formatting, and professionalism. * Prepare final slide deck. * Coordinate demo script and speaker transitions. ### 🤝 Collaboration Touchpoints | Collaborates With | Frequency | Purpose | | -------------------------- | ------------- | --------------------------------------- | | All roles | Biweekly | Gather evidence and artifacts | | Product Liaison | Biweekly | Client/problem framing | | Backend and Frontend Leads | Milestones | Architecture and implementation details | | QA/DevOps Lead | Final 4 weeks | Testing and deployment evidence | ### 📊 Deliverables Owned * Technical report outline. * Final technical report. * Slide deck. * Demo script. * Presentation rehearsal checklist. ### ⚠️ Common Failure Modes 1. **Report begins too late** Warning sign: no outline exists by Week 4. 2. **Writes without technical evidence** Warning sign: report contains generic descriptions but no diagrams, metrics, or decisions. 3. **Presentation is disconnected from MVP** Warning sign: slides explain features the app cannot demonstrate. ### 💡 Success Indicators * Report evolves throughout the semester. * Slides tell a coherent product and technical story. * Demo and presentation are rehearsed. * Final submission looks professional and unified. --- ## Role Rotation Policy ### Recommendation Use **partial rotation**, not full rotation. Because this is a 12-week senior capstone with real implementation dependencies, fully rotating all roles may create confusion. However, partial rotation helps prevent silos and gives students leadership experience. ## Recommended Schedule | Weeks | Role Policy | | ----------- | -------------------------------------------------- | | Weeks 1–4 | Primary roles assigned | | Week 5 | Role health review; secondary shadows assigned | | Weeks 6–8 | Rotate secondary ownership for learning and backup | | Week 9 | Freeze primary ownership for final delivery | | Weeks 10–12 | No major role rotation; focus on completion | ### Required Shadowing Each critical role has a secondary backup: | Primary Role | Required Backup | | ------------------- | ---------------------------------- | | Backend Lead | Frontend or QA Lead | | Frontend Lead | Backend or Product Liaison | | QA/DevOps Lead | Backend Lead | | Report Lead | Product Liaison | | Project Coordinator | Any member with strong reliability | ## Role Conflict Resolution If two students want the same role: ### Step 1: Evidence-Based Preference Discussion Each student explains: * Prior experience. * Motivation. * Availability. * What they would contribute. * What they want to learn. ### Step 2: Split Primary and Secondary Ownership Possible arrangements: * One becomes primary, one becomes deputy. * One owns implementation, one owns documentation. * One owns Weeks 1–6, the other owns Weeks 7–12 if role rotation is safe. ### Step 3: Team Vote with Criteria Team votes using these criteria: 1. Project need. 2. Student capability. 3. Student motivation. 4. Workload fairness. 5. Risk reduction. ### Instructor Escalation If unresolved after 24 hours, the instructor assigns roles based on: * Survey data. * Prior evidence. * Team balance. * Critical project risk. * Equity of workload. ## Unassigned Role Protocol If no one wants a critical role, especially QA/DevOps, Project Coordination, or Technical Writing: ### Assignment Criteria Instructor or team assigns the role to the student who has: 1. The closest relevant skill. 2. The most available schedule. 3. The fewest other high-load responsibilities. 4. The strongest need for development in that area, if risk is manageable. ### Compensation Mechanism The student assigned to an unwanted critical role receives one or more of: * Reduced scope in another deliverable. * Explicit recognition in peer evaluation. * Grade rubric credit for taking on a high-risk coordination role. * Instructor coaching. * Permission to pair with another student for difficult tasks. * Additional office-hour support. --- # 📅 SECTION 3: MILESTONE CHECKPOINT SYSTEM ## 12-Week Phase Structure | Phase | Weeks | Guiding Objective | | -------------------- | ----------: | ----------------------------------------------------------------- | | Phase 1: Initiation | Weeks 1–2 | Define problem, team process, scope, and technical direction | | Phase 2: Development | Weeks 3–7 | Build core MVP functionality through iterative implementation | | Phase 3: Refinement | Weeks 8–10 | Integrate, test, stabilize, improve UX, and prepare documentation | | Phase 4: Delivery | Weeks 11–12 | Finalize MVP, technical report, presentation, and client demo | --- ## Phase 1 — Initiation ### Duration Weeks 1–2 ### Guiding Objective Create a clear, feasible project foundation before coding accelerates. ### Team Deliverables Due at End of Phase 1. Team Charter. 2. Role assignment sheet. 3. Client/problem brief. 4. Initial requirements document. 5. MVP scope statement. 6. Initial architecture sketch. 7. Project schedule and task board. 8. Risk register. ### Instructor Checkpoint Format | Item | Details | | ------------------ | -------------------------------------------------------------- | | Format | 15-minute team meeting or written review | | Instructor Reviews | Scope, team roles, feasibility, risk register, initial backlog | | Time Per Team | 15–20 minutes | | Output | Instructor approval, conditional approval, or revision request | ### Student Self-Check Before submitting Phase 1 deliverables, the team confirms: * We can explain the client/user problem in one paragraph. * We have identified MVP features versus stretch features. * Every role has a primary owner and backup. * Our team has agreed communication and meeting norms. * We have a task board with work assigned for Week 3. ### Red Flags and Corrective Actions | Red Flag | Corrective Action | | ------------------------------------ | --------------------------------------------------------------------- | | MVP scope includes too many features | Instructor requires MoSCoW prioritization: Must, Should, Could, Won’t | | No clear backend/frontend/data plan | Team submits architecture revision within 72 hours | | Role assignments are vague | Instructor requires role cards with named deliverables | --- ## Phase 2 — Development ### Duration Weeks 3–7 ### Guiding Objective Build the core working MVP with visible progress every week. ### Team Deliverables Due at End of Phase 1. Working vertical slice. 2. Updated backlog. 3. API documentation. 4. Database schema or data model. 5. Initial deployed version or deployment plan. 6. Test plan draft. 7. Mid-project peer evaluation. 8. Progress demo. ### Instructor Checkpoint Format | Item | Details | | ------------------ | ------------------------------------------------------------------------- | | Format | 10-minute live demo plus 10-minute technical Q&A | | Instructor Reviews | Working functionality, code repository, backlog, risks, division of labor | | Time Per Team | 20 minutes | | Output | Continue, scope reduce, or intervention required | ### Student Self-Check * We can demonstrate at least one complete user workflow. * Our repository shows contributions from multiple members. * Our backlog is updated and prioritized. * Our database/API/frontend integration plan is clear. * We know the top three technical risks for the next two weeks. ### Red Flags and Corrective Actions | Red Flag | Corrective Action | | ---------------------------------------- | -------------------------------------------------------- | | No integrated feature by Week 5 | Require vertical-slice sprint with reduced scope | | One student owns most commits | Conduct workload audit and role redistribution | | Team is coding without client validation | Require client feedback checkpoint before next milestone | --- ## Phase 3 — Refinement ### Duration Weeks 8–10 ### Guiding Objective Move from “features exist” to “system is usable, testable, stable, and explainable.” ### Team Deliverables Due at End of Phase 1. Feature-complete MVP candidate. 2. Test results and bug tracker. 3. Deployment link. 4. Updated architecture diagram. 5. Draft technical report. 6. Draft presentation outline. 7. Usability or client feedback summary. ### Instructor Checkpoint Format | Item | Details | | ------------------ | ----------------------------------------------------------------------- | | Format | MVP review and report draft review | | Instructor Reviews | Stability, testing evidence, deployment, report quality, demo readiness | | Time Per Team | 25 minutes | | Output | Final delivery readiness rating | ### Student Self-Check * The MVP can run outside the original developer’s machine. * Critical bugs are documented and assigned. * The technical report draft includes real project evidence. * The demo path is realistic and rehearsable. * We have cut or deferred nonessential features. ### Red Flags and Corrective Actions | Red Flag | Corrective Action | | --------------------------------------------- | ------------------------------------------------------------------------ | | App still runs only locally | Mandatory deployment support session | | Report has no technical depth | Require architecture, testing, and decision-log sections within 72 hours | | Team adds new features instead of stabilizing | Instructor freezes scope | --- ## Phase 4 — Delivery ### Duration Weeks 11–12 ### Guiding Objective Deliver a stable MVP, professional client presentation, and polished technical report. ### Team Deliverables Due at End of Phase 1. Final MVP. 2. Final deployed application link. 3. Source code repository. 4. Final technical report. 5. Final presentation deck. 6. Demo script. 7. Final peer evaluations. 8. Individual reflection. ### Instructor Checkpoint Format | Item | Details | | ------------------ | ------------------------------------------------------------------------------------- | | Format | Final presentation, demo, report evaluation | | Instructor Reviews | Product quality, technical quality, professionalism, individual contribution evidence | | Time Per Team | 20–30 minute presentation/demo plus Q&A | | Output | Final project grade and individual adjustment review | ### Student Self-Check * The demo has been rehearsed at least twice. * The report is edited as one coherent document. * The deployed app and backup demo both work. * Every team member has a speaking or Q&A role. * Final peer evaluations are submitted individually and confidentially. ### Red Flags and Corrective Actions | Red Flag | Corrective Action | | ---------------------------------------------- | --------------------------------------------------------- | | Final demo depends on unstable live data | Require backup video or seeded demo database | | Report assembled at the last minute | Instructor grades individual report section ownership | | One or more students cannot explain the system | Conduct individual oral checks or contribution interviews | --- ## Weekly Meeting Agenda Template **Duration:** 30–45 minutes **Required every week** | Time | Agenda Item | Owner | | --------: | ------------------------------------------------------------ | ------------------- | | 0–5 min | Confirm agenda and review previous action items | Project Coordinator | | 5–15 min | Progress updates: each member answers “done, doing, blocked” | All | | 15–25 min | Blockers and dependency resolution | Project Coordinator | | 25–30 min | Sprint/task board update | Project Coordinator | | 30–35 min | Risk review: timeline, scope, technical issues | Rotating | | 35–40 min | Role-specific check-in | Rotating role owner | | 40–45 min | Confirm next actions, owners, and deadlines | All | ### Rotating Agenda Items | Week Type | Rotating Item | | ---------------- | --------------------------------------------------- | | Odd weeks | Peer feedback: What helped? What needs to change? | | Even weeks | Risk review: What could prevent the next milestone? | | Before milestone | Submission checklist review | | After milestone | Retrospective: start, stop, continue | ### Documentation Requirement Each meeting must produce: 1. Date, time, attendees. 2. Completed work since last meeting. 3. Blockers. 4. Decisions made. 5. Action items with owners and deadlines. 6. Risks added or resolved. Stored in: * Shared Google Doc, Notion page, GitHub Wiki, or LMS project journal. * Must be accessible to instructor. --- ## Milestone Deviation Protocol ## Tier 1 — Minor Delay ### Definition * Delay of 1–3 days. * No major dependency failure. * Team has a realistic recovery path. ### Required Response Team submits a **self-correction note**: | Field | Response | | ------------ | ------------------------- | | Missed item | What was late? | | Cause | Why was it late? | | New deadline | When will it be complete? | | Owner | Who is responsible? | | Prevention | What changes next week? | --- ## Tier 2 — Moderate Delay ### Definition * Delay of 4–7 days. * Milestone partially incomplete. * Integration or team coordination issues present. ### Required Response Instructor intervention and Catch-Up Plan required. ## Catch-Up Plan Template | Field | Team Response | | --------------------------- | ------------- | | Missed milestone component | | | Current project status | | | Root cause | | | Features to cut or defer | | | Required instructor support | | | Revised task list | | | Owner for each task | | | 72-hour deliverable | | | One-week deliverable | | | Risk if not completed | | --- ## Tier 3 — Critical Delay ### Definition * Delay of more than 7 days. * No working core product by late Development Phase. * Team conflict prevents execution. * Academic integrity or nonparticipation concerns exist. ### Required Response Formal remediation process: 1. Instructor meets with team. 2. Individual contribution evidence is reviewed. 3. Scope is reduced. 4. Individual responsibilities are reassigned. 5. Weekly instructor check-ins begin. 6. Grade implications are documented. 7. Academic process begins if needed. --- # ⚖️ SECTION 4: PEER EVALUATION INSTRUMENT ## Mid-Project Formative Peer Evaluation ### Purpose Used at the end of Phase 2 to identify contribution, communication, and team health issues early enough to fix them. ### Rating Scale 1 = Serious concern 2 = Inconsistent 3 = Adequate 4 = Strong 5 = Excellent --- ## Dimension 1: Contribution Quality | Score | Behavioral Anchor | | ----: | ----------------------------------------------------------------------------------------- | | 1 | Work is missing, unusable, or creates significant rework for others. | | 2 | Work is often incomplete or below agreed standards. | | 3 | Work usually meets basic expectations. | | 4 | Work is reliable, useful, and improves project progress. | | 5 | Work is consistently high-quality, well-tested, documented, and helps others move faster. | Open-ended questions: 1. What is one specific way this person could improve the quality or usefulness of their contributions? 2. What is one specific contribution from this person that helped the project? --- ## Dimension 2: Reliability and Follow-Through | Score | Behavioral Anchor | | ----: | ---------------------------------------------------------------------------------- | | 1 | Frequently misses deadlines or disappears without notice. | | 2 | Sometimes completes tasks late and needs repeated reminders. | | 3 | Usually completes assigned work on time. | | 4 | Consistently meets commitments and communicates early about risks. | | 5 | Anticipates problems, follows through reliably, and helps stabilize team progress. | Open-ended questions: 1. What would help this person become more reliable or predictable for the team? 2. When has this person followed through in a way that supported the team? --- ## Dimension 3: Communication | Score | Behavioral Anchor | | ----: | ------------------------------------------------------------------- | | 1 | Rarely responds, withholds information, or creates confusion. | | 2 | Communicates inconsistently or too late to help coordination. | | 3 | Provides necessary updates when asked. | | 4 | Communicates clearly and proactively. | | 5 | Keeps the team aligned, documents decisions, and reduces ambiguity. | Open-ended questions: 1. What communication habit should this person improve? 2. What communication behavior from this person has helped the team? --- ## Dimension 4: Collaboration and Respect | Score | Behavioral Anchor | | ----: | --------------------------------------------------------------- | | 1 | Dismisses others, creates tension, or refuses collaboration. | | 2 | Participates unevenly or has difficulty accepting feedback. | | 3 | Works respectfully with others most of the time. | | 4 | Actively supports teammates and resolves issues constructively. | | 5 | Builds trust, shares knowledge, and improves team morale. | Open-ended questions: 1. What is one way this person could collaborate more effectively? 2. What is one example of this person supporting the team? --- ## Dimension 5: Initiative and Problem-Solving | Score | Behavioral Anchor | | ----: | --------------------------------------------------------------- | | 1 | Waits to be told everything and does not help resolve blockers. | | 2 | Takes limited initiative and avoids ambiguous tasks. | | 3 | Completes assigned tasks and occasionally identifies problems. | | 4 | Proactively identifies issues and proposes solutions. | | 5 | Takes ownership of uncertain problems and helps the team adapt. | Open-ended questions: 1. What is one area where this person could take more initiative? 2. What problem has this person helped solve? --- ## Overall Team Health Score Each evaluator answers: > Overall, how healthy and functional is this team right now? | Score | Meaning | | ----: | ------------------------------ | | 1 | Team is at serious risk | | 2 | Team has unresolved problems | | 3 | Team is functioning adequately | | 4 | Team is working well | | 5 | Team is highly effective | ### Composite Calculation For each student: ```text Formative Peer Score = Average of 5 dimension scores Team Health Score = Average of all team health ratings ``` ### Support Request Field Each evaluator completes: > What does this team member need from the group to perform better? Examples: * Clearer task definitions. * Earlier feedback. * More pair programming. * Better meeting attendance. * Reduced interruptions. * More technical support. * More accountability. --- # Final/Summative Peer Evaluation Administered after final submission. ## Same Five Dimensions 1. Contribution Quality 2. Reliability and Follow-Through 3. Communication 4. Collaboration and Respect 5. Initiative and Problem-Solving ## Final Contribution Weight Slider For each teammate, students answer: > Estimate what percentage of the total project workload this person carried. Rules: * Total across all five members must equal 100%. * Equal contribution would be 20% each. * Students must justify any rating below 15% or above 25%. Example: | Team Member | Estimated Workload % | | ----------- | -------------------: | | A | 24% | | B | 21% | | C | 20% | | D | 18% | | E | 17% | | Total | 100% | ## Contribution Timeline Rate each team member’s effort in each phase. | Team Member | Phase 1 Initiation | Phase 2 Development | Phase 3 Refinement | Phase 4 Delivery | | ----------- | -----------------: | ------------------: | -----------------: | ---------------: | | Student A | 4 | 5 | 5 | 4 | | Student B | 3 | 3 | 4 | 5 | | Student C | 5 | 4 | 3 | 3 | Scale: 1 = Minimal contribution 2 = Below expected contribution 3 = Expected contribution 4 = Strong contribution 5 = Exceptional contribution ## Most Valuable Contribution Field > What was this person’s most valuable contribution to the project? ## Confidential Concern Flag Visible only to instructor: > Do you have any concern about this person’s contribution, conduct, academic integrity, or treatment of teammates? Options: * No concern. * Low concern. * Moderate concern. * Serious concern. Required explanation for moderate or serious concern. --- # Grade Weighting Policy ## Recommended Grade Architecture | Component | Weight | | ---------------------------- | -----: | | Group MVP/Product | 30% | | Group Technical Report | 20% | | Group Presentation/Demo | 10% | | Individual Role Deliverables | 15% | | Individual Reflection | 5% | | Peer Evaluation Adjustment | 20% | | Total | 100% | ## Peer Evaluation Formula Start with the group project subtotal, then apply an individual multiplier based on peer evaluation. ```text Individual Final Grade = (Group Components × Peer Multiplier) + Individual Role Deliverables + Individual Reflection ``` ### Group Components ```text Group Components = MVP + Report + Presentation = 60 points ``` ### Peer Multiplier | Peer Score | Multiplier | | ---------: | ------------------------------------------------------: | | 4.5–5.0 | 1.05 | | 4.0–4.49 | 1.00 | | 3.5–3.99 | 0.95 | | 3.0–3.49 | 0.90 | | 2.5–2.99 | 0.80 | | Below 2.5 | Instructor review required; multiplier may be 0.60–0.80 | Multiplier should not be automatic below 3.0. Instructor must review evidence. ## Example Calculation ### Student A: High-Quality Technical Work, Low Peer Scores * Group components: 54/60 * Individual role deliverables: 14/15 * Reflection: 5/5 * Peer score: 3.1 → multiplier 0.90 ```text Final = (54 × 0.90) + 14 + 5 Final = 48.6 + 19 Final = 67.6 / 80 equivalent before scaling ``` Interpretation: Student A may have produced strong code but harmed team reliability, communication, or collaboration. Instructor reviews comments before finalizing. ### Student B: Moderate Work, High Peer Scores * Group components: 54/60 * Individual role deliverables: 11/15 * Reflection: 5/5 * Peer score: 4.6 → multiplier 1.05 ```text Final = (54 × 1.05) + 11 + 5 Final = 56.7 + 16 Final = 72.7 / 80 equivalent before scaling ``` Interpretation: Student B may not have produced the strongest technical artifact but contributed reliably, supported coordination, and helped the team succeed. ## Instructor Override Conditions Instructor may disregard or adjust peer scores when: 1. Scores show clear collusion, such as all students giving all 5s without meaningful comments. 2. Scores show retaliation or targeting inconsistent with evidence. 3. Repository, meeting, or deliverable evidence contradicts peer reports. 4. A student had documented illness, accommodation, or approved constraint. 5. A conflict was reported and unresolved through formal channels. 6. Academic misconduct concerns are present. 7. One student’s invisible labor, such as coordination or report editing, is underrecognized. --- # Anti-Gaming Safeguards ## Mechanism 1: Forced Written Justification Any score of 1, 2, or 5 requires specific behavioral evidence. ## Mechanism 2: Distribution Review Instructor compares: * Peer ratings. * Contribution percentages. * Git commit history. * Meeting notes. * Role deliverables. * Issue/task board completion. ## Mechanism 3: Calibration Warnings Before evaluations, tell students: > Peer evaluation is not a popularity vote. Scores must reflect observable contribution and professional conduct. ## Mechanism 4: Outlier Detection Instructor flags: * One student rated low by all others but with strong evidence of contribution. * One student rating everyone much lower than the rest of the team. * All students giving identical perfect scores. * Workload percentages that do not total realistically. * Comments that are vague, hostile, or unrelated to project behavior. ## Score Distribution Analysis For each team, instructor checks: | Pattern | Possible Meaning | Instructor Action | | ------------------------------------- | ------------------------------------- | ---------------------------------------- | | All 5s, no details | Collusion or superficial evaluation | Request clarification | | One member rated very low by all | Possible free-riding or conflict | Review evidence and meet individually | | One evaluator rates everyone low | Possible resentment or high standards | Compare to other data | | High workload % but low quality score | Student worked hard but ineffectively | Adjust feedback, not automatically grade | | Low workload % but high collaboration | Support role may be undercounted | Review meeting notes and deliverables | --- # 🔥 SECTION 5: CONFLICT RESOLUTION PROTOCOLS ## Three-Tier Conflict Resolution System --- # TIER 1 — Peer-Level Resolution ## Days 1–3 of Conflict Students should attempt structured resolution without instructor involvement unless the issue involves harassment, discrimination, threats, academic dishonesty, or severe misconduct. ## Conflict Conversation Guide **Duration:** 20–30 minutes **Facilitator:** Project Coordinator, unless involved in the conflict. If involved, another neutral member facilitates. ### Step 1: Opening Frame — 3 minutes Script: > “The goal of this conversation is not to blame anyone. The goal is to identify what is blocking the team and agree on specific changes. We will focus on observable behavior, project impact, and next actions.” Rules: * Use “I” statements. * No interruptions. * No personal insults. * Focus on future behavior. * Document agreements. ### Step 2: Issue Identification Round — 7 minutes Each person answers: 1. What issue am I seeing? 2. What specific behavior or event led me to see it? 3. How is it affecting my work or the project? Required sentence frame: > “I noticed ___, and it affected the project because ___.” ### Step 3: Impact Acknowledgment — 5 minutes Each person reflects back: > “What I heard you say is ___. The impact on you or the project is ___.” The original speaker confirms or corrects. ### Step 4: Solution Brainstorm — 7 minutes Each person proposes one concrete change. Examples: * “I will post blockers within 24 hours.” * “We will define task acceptance criteria before assigning work.” * “We will use GitHub issues instead of verbal task assignments.” * “We will pair program on integration problems.” ### Step 5: Agreement Documentation — 5 minutes Team records: * What changes. * Who owns the change. * Deadline. * How success will be checked. * What happens if the issue recurs. ## Conflict Log Template | Field | Response | | ---------------------- | -------- | | Date of conversation | | | Participants | | | Issue discussed | | | Project impact | | | Agreed changes | | | Owners | | | Deadline/check-in date | | | Escalation trigger | | --- # TIER 2 — Facilitated Mediation ## Days 4–7 of Conflict Triggered when: * Tier 1 fails. * Conflict recurs. * Team cannot discuss the issue productively. * A milestone is at risk because of team dynamics. ## Pre-Mediation Written Statement Template Each involved party submits privately to instructor: | Prompt | Response | | ------------------------------------------------- | -------- | | What is the conflict about? | | | What specific behaviors or events are relevant? | | | How has this affected your work or the team? | | | What have you already tried? | | | What outcome would allow the project to continue? | | | What are you willing to change? | | ## Instructor Mediation Process ### Before the Session Instructor: 1. Reads written statements. 2. Reviews team charter, meeting notes, and task board. 3. Identifies whether this is a workload, communication, respect, quality, or conduct issue. 4. Sets ground rules. ## Mediation Session Agenda **Duration:** 30–45 minutes | Time | Activity | | --------: | ------------------------------------------------------ | | 0–5 min | Ground rules and purpose | | 5–15 min | Each party speaks without interruption | | 15–25 min | Instructor identifies common ground and project impact | | 25–35 min | Parties propose specific behavioral commitments | | 35–45 min | Formal agreement written and signed | ### Ground Rules * Speak from evidence. * No personal attacks. * No interrupting. * Instructor may pause discussion. * Agreement must be specific and measurable. ## Post-Mediation Follow-Up | Timing | Check-In | | -------------- | --------------------------------------------------------- | | 48 hours later | Instructor checks whether agreement has started | | 1 week later | Team submits short progress note | | Next milestone | Instructor reviews whether conflict affected deliverables | ### Success Criteria * Agreed behaviors are visible. * Communication improves. * Missed work is reassigned or completed. * No retaliation occurs. * Team can continue productively. ## Mediation Agreement Document | Field | Agreement | | ------------------------------ | --------- | | Date | | | Participants | | | Conflict summary | | | Agreed behavior changes | | | Task/workload changes | | | Communication expectations | | | Follow-up date | | | Consequence if agreement fails | | | Student signatures | | | Instructor signature | | --- # TIER 3 — Formal Academic Process ## Day 8+ or Severe Conflicts Triggered by: * Persistent dysfunction. * Academic dishonesty suspicion. * Harassment, discrimination, threats, or intimidation. * Collapse of team cohesion. * Serious nonparticipation. * Safety or wellbeing concerns. ## Four Categories of Tier 3 Conflicts | Category | Examples | Institutional Response | | ----------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------ | | Persistent Nonparticipation | Missing meetings, no deliverables, no communication | Individual contribution review, grade adjustment, formal warning | | Academic Integrity Concern | Code plagiarism, fake commits, unauthorized AI use, falsified contribution | Academic conduct referral according to university policy | | Harassment or Hostile Conduct | Threats, discriminatory comments, bullying, exclusion | Immediate escalation to department/student conduct office | | Team Breakdown | Refusal to collaborate, repeated mediation failure, project cannot continue | Team restructuring, individual work track, instructor-managed task split | ## Instructor Escalation Checklist Instructor documents: * Team Charter. * Meeting notes. * Task board history. * Git/repository evidence. * Peer evaluations. * Conflict logs. * Mediation statements. * Mediation agreement. * Emails or messages relevant to the issue. * Instructor observations. * Applicable university policy. ## Possible Outcomes 1. Team restructuring. 2. Individual grade adjustment. 3. Required individual deliverable. 4. Removal from team workflow. 5. Withdrawal from group component. 6. Academic conduct referral. 7. Student support referral. 8. Revised project scope. 9. Instructor-supervised work plan. --- # Proactive Conflict Prevention ## Week 1 Team Charter Template Each team completes and signs this document. ## Team Charter ### 1. Team Identity | Field | Response | | -------------- | -------- | | Team name | | | Project/client | | | Members | | | Shared goal | | ### 2. Communication Norms | Question | Team Agreement | | ----------------------------- | -------------- | | Primary communication channel | | | Expected response time | | | Emergency channel | | | Meeting day/time | | | How absences are reported | | ### 3. Work Standards | Standard | Team Agreement | | --------------------------- | -------------- | | Definition of “done” | | | Code review expectations | | | Documentation expectations | | | Testing expectations | | | Minimum weekly contribution | | ### 4. Decision-Making Process | Decision Type | Process | | ---------------------- | ------- | | Technical architecture | | | Feature scope | | | Design/UI choices | | | Client communication | | | Conflict escalation | | ### 5. Consequences for Non-Compliance | Issue | First Response | Second Response | Third Response | | ----------------- | ----------------- | -------------------- | --------------------- | | Missed task | Team reminder | Reassignment and log | Instructor notified | | Missed meeting | Catch-up required | Written explanation | Instructor notified | | Poor-quality work | Revision request | Pair support | Role adjustment | | Noncommunication | Direct message | Team discussion | Instructor escalation | ### 6. Signatures Each member signs: > I agree to follow this charter, communicate early, document my work, and participate in conflict resolution professionally. --- ## Psychological Safety Check Administer anonymously every 2 weeks. **Scale:** 1 = Strongly disagree 5 = Strongly agree | Question | | ------------------------------------------------------------------- | | I feel comfortable raising concerns or blockers with this team. | | Team members listen respectfully when someone disagrees. | | Workload feels visible and fairly discussed. | | I can ask for help without feeling judged. | | I believe our team can address problems before they become serious. | Instructor flags teams with: * Average below 3.2. * Any question average below 3.0. * A drop of 1.0 or more from prior survey. * Multiple comments indicating exclusion, fear, or silence. ## Team-Building Micro-Activities ### Activity 1: Working Style Snapshot **Time:** 10 minutes Each member answers: 1. I do my best work when… 2. I get frustrated when… 3. The best way to ask me for help is… 4. One thing teammates should know about my schedule is… Outcome: * Shared working-style notes added to Team Charter. --- ### Activity 2: Failure Pre-Mortem **Time:** 15 minutes Prompt: > Imagine it is Week 12 and the project failed. What caused the failure? Each member lists two possible causes. Team groups them into risks and adds prevention steps. Outcome: * Initial risk register. --- ### Activity 3: Technical Teach-Back **Time:** 15 minutes Each member teaches one thing they know well for two minutes: * Tool. * Framework. * Debugging trick. * Design pattern. * Testing habit. * Writing/presentation method. Outcome: * Team identifies hidden strengths and potential mentors. --- # 📊 SECTION 6: INSTRUCTOR DASHBOARD & IMPLEMENTATION GUIDE # Pre-Project Setup Checklist ## Instructor Preparation | Task | Complete? | | --------------------------------------------------------- | --------- | | Finalize project/client descriptions | | | Decide team formation approach | | | Prepare skill or motivation survey | | | Prepare Team Charter template | | | Prepare role cards | | | Create LMS project page | | | Create milestone submission links | | | Create peer evaluation forms | | | Create grading rubric | | | Create conflict protocol page | | | Create sample technical report outline | | | Create sample architecture diagram | | | Prepare Git/repository expectations | | | Prepare deployment guidance | | | Schedule milestone checkpoint slots | | | Prepare client communication expectations | | | Prepare academic integrity guidance for code and AI tools | | ## Student Materials to Release 1. Project overview. 2. Team formation survey. 3. Team Charter template. 4. Role assignment framework. 5. Milestone roadmap. 6. Peer evaluation policy. 7. Conflict resolution protocol. 8. Grading rubric. 9. Technical report template. 10. Presentation/demo expectations. --- # Week-by-Week Instructor Actions | Week | Instructor Actions | | ------: | ------------------------------------------------------------------------------ | | Week 1 | Form teams, review Team Charters, approve roles, verify communication channels | | Week 2 | Review requirements, MVP scope, initial architecture, and risk register | | Week 3 | Check task boards and ensure coding has started | | Week 4 | Review first technical progress; look for integration plan | | Week 5 | Require vertical slice demo or evidence of integration | | Week 6 | Administer mid-project peer evaluation and psychological safety check | | Week 7 | Conduct development milestone demos and intervene with at-risk teams | | Week 8 | Review testing, deployment progress, and scope reduction decisions | | Week 9 | Review report draft outline and architecture documentation | | Week 10 | Conduct refinement checkpoint; freeze scope where necessary | | Week 11 | Review final demo readiness, presentation structure, and backup plan | | Week 12 | Evaluate final demo/report; collect final peer evaluations and reflections | --- # Common Failure Patterns and Proactive Interventions ## 1. The “One Hero Developer” Problem ### Pattern One student builds most of the system while others become passive. ### Early Signs * Commit history dominated by one student. * Other members cannot explain the system. * Meetings become status reports to the hero developer. ### Intervention * Require task ownership by role. * Require pair programming. * Conduct individual oral checks. * Grade individual role deliverables separately. --- ## 2. The “Pretty UI, No Backend” Problem ### Pattern Team focuses on frontend mockups but lacks functioning data/API logic. ### Early Signs * Demo is static. * No database schema. * No API documentation. * Backend tasks repeatedly deferred. ### Intervention * Require vertical slice by Week 5. * Freeze UI polish until one core workflow works end-to-end. * Ask team to demonstrate create/read/update flow. --- ## 3. The “Architecture Astronaut” Problem ### Pattern Team over-engineers architecture and delays implementation. ### Early Signs * Many diagrams, little working code. * Excessive debate over tools. * No user story completed by Week 4. ### Intervention * Require one simple workflow implementation. * Limit tool changes after Week 3. * Cut architecture scope. --- ## 4. The “Silent Conflict” Problem ### Pattern Team appears fine publicly, but members are frustrated privately. ### Early Signs * Low psychological safety scores. * Vague peer evaluation comments. * Uneven meeting attendance. * Students contact instructor separately. ### Intervention * Require Tier 1 conflict conversation. * Meet with team. * Use mediation before milestone failure occurs. --- ## 5. The “Last-Minute Report Assembly” Problem ### Pattern Team treats report as an afterthought. ### Early Signs * No report outline by Week 4. * No decision log. * Diagrams missing. * Report Lead inactive. ### Intervention * Require report skeleton early. * Assign section owners. * Require evidence collection every milestone. * Grade report process artifacts. --- # Grading Architecture ## Recommended Grade Split | Category | Weight | Type | | --------------------------------------- | -----: | ---------------------------- | | MVP/Product Functionality | 25% | Group | | Technical Architecture and Code Quality | 15% | Group/Individual evidence | | Technical Report | 20% | Group with section ownership | | Final Presentation and Demo | 10% | Group/Individual speaking | | Individual Role Deliverables | 15% | Individual | | Peer Evaluation | 10% | Individual adjustment | | Individual Reflection | 5% | Individual | | Total | 100% | Mixed | ## Fairness Principles 1. Group work should reward shared success. 2. Individual role deliverables should prevent free-riding. 3. Peer evaluation should influence grades but not replace instructor judgment. 4. Technical and nontechnical labor should both count. 5. Invisible work must be documented. --- # Communication Templates ## Template 1: Project Launch Announcement **Subject:** CS 401 Capstone Project Launch: Teams, Roles, and Week 1 Requirements Dear CS 401 students, Today we are beginning the 12-week Software Engineering Capstone project. Each team will design, build, deploy, and present a full-stack web application MVP, supported by a technical report and final client-style presentation. By the end of Week 1, each team must submit: 1. Team Charter 2. Role assignment sheet 3. Initial project/problem statement 4. Communication plan 5. First weekly meeting notes Your team must assign the following responsibilities: * Product & Client Liaison * Project Coordinator * Architecture & Backend Lead * Frontend & UX Lead * QA/Testing & DevOps Lead * Technical Report & Presentation Lead Some students may hold one primary role and one secondary support role. Please remember: this project will be evaluated on both the final product and the professionalism of your collaboration process. Keep meeting notes, task boards, design decisions, and contribution evidence from the beginning. Best, [Instructor Name] --- ## Template 2: Mid-Project Check-In **Subject:** CS 401 Mid-Project Check-In: Demo, Peer Evaluation, and Risk Review Dear CS 401 teams, We are now entering the midpoint of the capstone project. At this stage, each team should be able to demonstrate at least one working vertical slice of the application. This week, each team must submit: 1. Progress demo or demo recording 2. Updated backlog 3. Current architecture/API documentation 4. Risk register update 5. Mid-project peer evaluation 6. Psychological safety check As you prepare, ask your team: * What core workflow works right now? * What is still blocked? * What feature should be cut if time becomes limited? * Is workload distributed fairly? * Are there any unresolved communication or collaboration issues? If your team is behind, do not hide it. A clear recovery plan is better than an optimistic but unrealistic status update. Best, [Instructor Name] --- ## Template 3: Final Evaluation Instructions **Subject:** CS 401 Final Submission Instructions: MVP, Report, Presentation, and Peer Evaluation Dear CS 401 students, Final project submissions are due this week. Each team must submit: 1. Final deployed MVP link 2. Source code repository 3. Final technical report 4. Final presentation deck 5. Demo script or demo plan 6. Testing/deployment documentation 7. Final peer evaluations 8. Individual reflections Your final presentation should clearly explain: * The client/user problem * Your MVP scope * Key technical decisions * System architecture * Live or recorded demo * Testing and deployment approach * Limitations and future work Each student must be prepared to answer questions about their own role and the overall system. Final peer evaluations are confidential and must reflect observable contribution, reliability, communication, collaboration, and initiative. Please verify that your deployed application and backup demo both work before the presentation. Best, [Instructor Name]