Week 4: Planning Sprint

✅ Week 4 Checklist Self-paced checklist — complete during and after this session

📋 Checkpoint Prep Form Book Checkpoint 1 before you leave today — send form 24h before

🤖 GitHub Copilot Free for students — claim it today, use it from Week 5

🌿 Git Basics New to Git? Read this before Week 5

Today’s goal

Leave this session with: roles agreed, a planning document started (you will build this during Mission 2), a prioritised feature list, and a task board with named owners.

You will not write code today. That starts next week. Planning done well now means building done fast later.

Two new concepts — read this first

Sprint — a short, focused period of building, usually one or two weeks. At the end of each sprint, you have something working to show. Today you plan your first sprint.

Kanban board — a visual task board with three columns: To Do / Doing / Done. Every task lives in one column. At a glance, anyone on the team can see who is doing what and what is finished. You may have seen this in 钉钉 (DingTalk), 飞书 (Feishu), or Teambition — it is the same idea.

How to use this guide

Missions 1–3 are whole-team. Everyone does them together.

Mission 4 is self-paced. Once your sprint goal is agreed, split up and follow the Week 4 Checklist at your own pace.

Returning mid-session? Go straight to the Week 4 Checklist — it has everything you need to pick up where you left off.

---

Before you start

Think of a team project from a previous semester — not this module. One that did not go as well as expected.

Write down one specific thing that went wrong. Not “communication was bad.” A real moment: “We had not spoken for two weeks and then panicked the night before” or “One person rewrote everything on their own” or “We started coding before agreeing what we were building.”

If you cannot think of one, write: “I have not had this problem yet — but I can see how it could happen.”

You will use this in Mission 1.

---

Mission 1 — Agree on roles (20 min — whole team)

Step 1 — Share your failure

Go around the table. Each person reads out their one failure from above (30 seconds each).

Look for patterns. You will almost certainly find them here:

What kept going wrong	The professional practice that fixes it
Nobody knew who owned what	Role assignment
One person did everything	Named task ownership
The scope kept expanding	MoSCoW prioritisation
The team built something users didn’t want	User validation before building
Problems were hidden until too late	Traffic light + checkpoints

These are not university exercises. Each one was invented because professional product teams kept failing in the same ways.

Step 2 — Assign the 7 roles

Each person picks their top 2 interests — what you want to learn, and what you already do well.

Role	Main responsibility	Assessed through
Product Manager	Sprint goals, standups, team direction	Dev Log quality, Checkpoint prep
UX / UI Designer	Figma mockups, user flows, visual design	Evidence links, usability test results
Frontend Developer	What users see — screens, buttons, interactions	GitHub commits, working features
Backend Developer	Data, APIs, server logic	GitHub commits, Technical Documentation
User Researcher	Interviews, usability sessions, findings	Validation Report, interview notes
Technical Lead	Architecture decisions, code quality, repo	Technical Documentation, code review
Documentation & IP	Dev Log quality, Technical Docs, IP section	Dev Log, Week 11 Portfolio

Every role needs one named owner. Overlap is fine. Gaps are not.

If your team has fewer than 7 people

One person can cover two roles. Record both in your Dev Log.

Non-technical roles are real roles

A User Researcher’s Week 4 tasks include: scheduling two user interviews, writing the question guide, and sharing findings with the team. These are measurable, evidenced contributions — not “support work.”

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

Step 3 — Record in your Dev Log

Write role assignments in this week’s Dev Log entry before you move on.

Format:

Roles — Week 4
[Name] — [Role]
[Name] — [Role]
(one line per person)

---

Mission 2 — Stress-test your Project Brief (25 min — whole team)

Your Project Brief was written last week. Before you build anything, check it is solid.

Stage 1 check — do this first

Did your team complete at least one validation path in Week 3 — talking to users, competitive benchmark, or secondary research?

• Yes, documented in Dev Log → you are done with Stage 1. Continue to Step 1.
• Yes, but not documented → take two minutes to add a summary and evidence link to your Week 3 Dev Log entry, then continue.
• No → your User Researcher’s first task this week is to talk to 3–5 people who match your target user before Week 5. See the Validation Guide for how to run a quick interview. Do not begin concept design without Stage 1 evidence.

Stage 1 asks: Is the problem real? Stage 2 (Week 5) asks: Does your solution make sense? You cannot validate a solution to a problem you have not confirmed.

Step 1 — AI critique

Open your Project Brief. Paste it with this prompt:

You are a critical product mentor reviewing a student project brief. Identify: (a) unclear assumptions about users or problems, (b) scope risks — features that could take 3× longer than expected, (c) success metrics that cannot actually be measured, (d) important questions not yet asked to real users. For each issue, suggest one concrete fix. Be direct.

Read the output as a team. Discuss: which critiques are fair?

Step 2 — Fix two gaps

Pick the two most useful critiques. Fix those sections in your Brief right now.

Common mistake

Do not use AI to rewrite your Brief for you. AI identifies the gaps. You decide what the fixes are. The strategic thinking must come from your team.

Step 3 — Sketch your PRD

A Product Requirements Document (PRD) turns your Brief into a building plan.

Open a new Word document in your XJTLU OneDrive — this is where your PRD will live for the rest of the semester and where your final submission comes from. Use this prompt:

Based on this project brief, generate a one-page Product Requirements Document with: 5–7 user stories in "As a [user], I want to [do X], so that [Y]" format; a feature list linked to each user story; and an initial technical architecture (front-end, back-end, data storage). Keep it simple and practical.

Review the output critically. Ask:

• Do the user stories match real users you identified?
• Is the architecture realistic for your team’s skill level?
• What would you change?

If you have time: run the same prompt in two different AIs and compare. Different tools make different assumptions — spotting the gaps is the skill.

Edit it until it reflects your team’s actual intentions. Paste the PRD link into your Dev Log.

The PRD is a living document

You will update this throughout Weeks 4–9. It is not a submission — it is your team’s shared building plan.

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

---

Mission 3 — Decide what to build (30 min — whole team)

Step 1 — MoSCoW

New to MoSCoW?

Read the two-minute overview before you start — it takes less time than getting the labels wrong.

List every feature your team has discussed. Each person independently labels each one:

	Meaning	Ask yourself
M — Must have	Product fails without this	”If missing, Demo Day fails?”
S — Should have	Important, not launch-blocking	”Would users notice and care?”
C — Could have	Nice if time allows	”Is this a bonus?”
W — Won’t have	Out of scope this semester	”Can we cut it entirely?”

Compare your labels. Discuss disagreements. Agree on your Must-haves.

Hard cap: 3 Must-haves maximum

If everything is a Must, nothing is. Three features done well beats ten features half-built. This is the hardest and most important decision of the semester — be ruthless.

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

Step 2 — Technical architecture with AI

You have agreed on your Must-haves. Now use AI to help plan how to build them.

I am building [brief one-sentence product description]. My three Must-have features are: [list them]. My team's technical skills are: [list languages, frameworks, tools you know]. Suggest a simple technical architecture — front-end, back-end, and data storage. Highlight the two biggest technical risks and how to reduce them.

Review the suggestion. Does it match your team’s skills? Add the agreed architecture to your PRD.

Your stack is your choice

There is no required technology for this module. UIFlow 2.0, a web framework, manual coding, Cursor-generated scaffolding — all valid. Choose what your team can actually finish and demo in 8 weeks. The assessment cares about process and validation, not which language you used.

Compare two AIs

Run the same prompt in two tools — try DeepSeek, Xipu AI (aiagent.xjtlu.edu.cn, has Sonnet and Opus), ChatGPT, or Claude. Different tools make different architecture assumptions. Which one matches your team’s skills better, and why? Debate it — that conversation is more useful than either output alone.

UX/UI Designer: while the architecture is being discussed, sketch the Must-have screens in Figma. You have Figma experience from last semester — now is when it connects. Your team needs to see what they are building before Week 5 coding starts.

Step 3 — Sprint goal

Agree on one sentence:

“By the end of Week 5, a real user can [do X] and [Y happens] — it works completely, not just as a mockup.”

“Working completely” means the full flow: the user does the action, real data is saved or processed, and the result appears on screen. A Figma design is not a working feature.

Write this sentence at the top of your Kanban board. This is your Week 5 commitment.

Where exactly is “the top”?

In GitHub Projects: click ”…” → Edit details and paste your sprint goal into the Description field. It appears at the top of the board and is visible to everyone with access.

---

Mission 4 — Set up and split (self-paced — individual)

Roles are agreed. Sprint goal is set. Now split up and follow the Week 4 Checklist at your own pace.

One board, one person sets it up

One team member (usually the Technical Lead or PM) creates the GitHub Project and invites everyone else as collaborators. “Individual” means each person manages their own task cards — not that everyone creates a separate board.

Make the board public so your pathfinder and Stefan can view it. Go to your Project → Settings → Visibility → Public. Your code repository can stay private — the board visibility is separate.

Keep this board for the whole semester. Move completed tasks to Done and add new tasks each week. Do not create a new board for each week.

Each person’s tasks:

1. Set up your Kanban board — watch this first, then set up together:

   Cannot play the video? For step-by-step GitHub Projects setup, watch the official GitHub guide on YouTube (8 min)

2. Add your tasks to the board — one card per task, your name on each

3. Move one task to “Doing”

4. Book Checkpoint 1 with your pathfinder before you leave

Free AI coding tool — claim it now

Verified students get GitHub Copilot free — unlimited completions, chat, and agent mode. Takes 10 minutes to set up. See the GitHub Copilot guide in Tools.

New to Git?

If you have never used Git before — or if branch, commit, push, and pull are still unclear — read Git Basics before next week. It covers exactly what you need to start your first sprint. Takes about 5 minutes.

Kanban board tools:

You may already use a tool with a similar task board feature — 钉钉 (DingTalk), 飞书 (Feishu), and Teambition all have one. For this module, use a tool that connects to your code repository:

Tool	Use if…
GitHub Projects	Your team uses GitHub
Gitee Projects	Your team uses Gitee

Three columns minimum: To Do / Doing / Done

Prefer to read? Step-by-step screenshots · Interactive course (free, self-paced, Microsoft Learn)

Once your tasks are in the board, see AI Coding Tools to compare your options before writing a line of code.

Course questions?

Use Ask Owl — an AI assistant tuned to ENT208TC. It searches this site to answer course-specific questions: Project Brief requirements, MoSCoW rules, Dev Log criteria, Checkpoint prep. For anything that needs Stefan’s judgement, it will tell you to message him directly.

---

Checkpoint 1

Checkpoint 1 happens between Weeks 4–6. Your pathfinder will tell you how to book a slot.

Book before you leave today. Do not leave it to next week.

What to prepare (at least 24 hours before)

Send this four-field form to your pathfinder — nothing more. Evidence links and individual contributions stay in your Dev Log; the pathfinder will ask to see them live during the session.

Checkpoint 1 Prep — [Team name] — [Date]

Sprint status: 🟢 On track / 🟡 At risk / 🔴 In crisis
One sentence why: ___________________________________________

Blocker:
[What exactly is stuck? Be specific — not "it's hard."]

Our question for the pathfinder:
[One question you want answered in this session]

Live work link:
[GitHub repo / Figma / working app URL]

Bring your Dev Log and Kanban board open on your laptop. The pathfinder will ask to see them.

💬

Live Q&A

● live

Ask → ⋯ ✓ Sent!

✓ Sent — see all questions and upvote →

---

Before you leave

🌱 Sprout — four things to have done today

• Roles recorded in Dev Log (Name — Role, one line per person)
• Sprint goal written (“By end of Week 5, a real user can…”)
• Kanban board exists with named task owners
• Checkpoint 1 is booked

If any of these are missing, do them before you go.

Team health check — does any of this describe you?

If this is your team…	What to do now
You have more than 3 Must-haves	Cut, don’t add. Three done well beats ten half-built.
All 3 Must-haves are technical features	Something is missing. What does the user see and do? UX and research tasks need owners too.
Non-technical team members didn’t contribute in Mission 3	Ask: whose problem does this solve? Who is the user? Those are their questions to own.
PRD or Kanban not started	Make it your first Checkpoint 1 requirement.
Stage 1 validation not done	Name the day this week your User Researcher talks to users. Put it in the Kanban.