CMU597: Industry Project - Lecture 3
Project Management & Sprint Zero
Part A: Agile & Scrum | Part B: Sprint Zero Setup
James Williams
Birmingham Newman University
jwilliams@staff.newman.ac.uk
3-hour session • 2 parts • 2 team tasks
Session Timeline
Part A: Agile, Scrum, Kanban & Backlogs (90 minutes)
30 minutes: Lecture on agile methodologies, user stories, sprint planning
45 minutes: Task 1 - Create team backlog with user stories
15 minutes: Break
Part B: Sprint Zero Setup (90 minutes)
30 minutes: Lecture on repository setup, folder structure, tooling
45 minutes: Task 2 - Complete Sprint Zero setup
15 minutes: Review and next steps
Learning Objectives
- Understand agile principles and why they matter for team projects
- Learn Scrum framework: sprints, roles, ceremonies
- Write user stories with acceptance criteria
- Create and prioritize product backlogs
- Use Kanban boards for visual workflow management
- Set up team repositories with proper structure
- Configure development environments and tooling
- Plan and execute Sprint Zero effectively
What is Agile Software Development?
Agile: An iterative approach to software development that emphasizes
flexibility, collaboration, and rapid delivery of working software.
Agile Manifesto Values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Key Idea: Rather than plan everything upfront (Waterfall), agile teams
work in short cycles, deliver incrementally, and adapt based on feedback.
Agile vs Waterfall
Waterfall (Traditional):
- Sequential phases (plan → design → build → test)
- All requirements defined upfront
- Testing at the end
- Late feedback, hard to change
- Risk of building wrong thing
Agile (Iterative):
- Short cycles (1-2 week sprints)
- Requirements evolve
- Continuous testing
- Early, frequent feedback
- Adapt quickly to changes
For This Module: You'll use 1-2 week sprints, delivering working features
each sprint and adapting based on progress.
Scrum Framework
Scrum: The most popular agile framework. Organizes work into fixed-length sprints
with defined roles and ceremonies.
Key Elements:
- Sprint: Fixed time period (1-2 weeks) to complete selected work
- Product Backlog: Prioritized list of all desired features/tasks
- Sprint Backlog: Features selected for current sprint
- Daily Standup: Quick daily sync (15 min)
- Sprint Review: Demo completed work at sprint end
- Sprint Retrospective: Reflect on what went well/improve
Scrum Roles (Adapted for Student Teams)
Traditional Scrum Roles:
- Product Owner: Defines vision, prioritizes backlog, accepts work
Your team: Can rotate weekly or assign to most organized member
- Scrum Master: Facilitates process, removes blockers, coaches team
Your team: Can rotate or share responsibility
- Development Team: Self-organizing, cross-functional, builds product
Your team: Everyone! All team members contribute to development
Recommendation: Keep roles lightweight. Focus more on collaboration than
strict role separation.
The Sprint Cycle
1-2 Week Sprint Flow:
- Sprint Planning (Start): Select backlog items, estimate effort, commit to
sprint goal
- Daily Work: Team works on selected items, holds daily standups
- Sprint Review (End): Demo working software to stakeholders/team
- Sprint Retrospective (End): Discuss what went well, what to improve
- Repeat: Plan next sprint with updated priorities
Your Timeline: With 12 weeks, you'll complete ~6 sprints (2 weeks each).
Sprint 0 (this week) sets up infrastructure.
Writing User Stories
User Story: A requirement written from the user's perspective,
describing WHO wants WHAT and WHY.
Standard Format:
"As a [type of user], I want [goal/desire] so that [benefit/reason]."
Examples:
"As a student, I want to search for available study spaces by location so that I can find a nearby
space quickly."
"As an admin, I want to view booking analytics so that I can understand space utilization patterns."
"As a shopper, I want to add items to my cart so that I can purchase multiple products at once."
Acceptance Criteria
Acceptance Criteria: Specific conditions that must be met for a user story
to be considered "done". Written in Given-When-Then format.
User Story:
"As a student, I want to search for available study spaces by location so that I can find a
nearby space quickly."
Acceptance Criteria:
- Given I am on the search page,
When I select a location from the dropdown,
Then I see only spaces in that location
- Given there are no available spaces,
When I perform a search,
Then I see a "No spaces available" message
- Given search results are displayed,
When I view a result,
Then I see space name, capacity, and availability status
Epic vs Story vs Task
Hierarchy of Work:
- Epic: Large body of work, spans multiple sprints
Example: "User Account Management" (includes registration, login, profile, password
reset)
- User Story: Single feature from user perspective, completable in 1 sprint
Example: "As a user, I want to register an account with email/password"
- Task: Technical work item to implement story, measured in hours/days
Example: "Create user registration API endpoint," "Build signup form UI"
Breaking Down Work: Epic → Stories → Tasks. Start with epics, break into
stories for backlog, then tasks during sprint planning.
Kanban Boards for Visual Workflow
Kanban: Visual system for managing work using columns representing workflow stages.
Basic Kanban Board Columns:
Backlog
All future work
|
To Do
Ready for sprint
|
In Progress
Actively working
|
Review
Code review/testing
|
Done
Completed
|
Tools: Trello, Jira, GitHub Projects, Asana, Notion
Story Point Estimation
Story Points: Relative measure of effort/complexity (not time).
Common scale: 1, 2, 3, 5, 8, 13 (Fibonacci sequence).
Estimation Guidelines:
- 1-2 points: Simple story, few hours of work, low complexity
- 3-5 points: Moderate story, takes 1-2 days, some unknowns
- 8-13 points: Complex story, takes several days, many dependencies
- 21+ points: Too large - break into smaller stories
Example Estimates:
2 points: "Add email validation to signup form"
5 points: "Implement user authentication with JWT"
8 points: "Build product search with filters and sorting"
Daily Standup Meetings
15-Minute Daily Sync:
Each team member answers three questions:
- What did I do yesterday? (accomplishments)
- What will I do today? (plan)
- Any blockers? (impediments preventing progress)
Best Practices:
- Same time daily (e.g., 10am)
- Stand up (keeps it short!)
- Focus on progress, not details
- Take detailed discussions offline
Your Team: Meet 2-3 times per week minimum. Can be async (Slack/Discord)
if schedules don't align.
Task 1: Create Team Product Backlog
Instructions (Work in your project teams):
- Identify Epics (10 min): Based on your design brief, list 3-5 major epics
- Example: "User Management," "Product Catalog," "Checkout Process"
- Break into User Stories (20 min): For each epic, write 3-5 user stories
- Use format: "As a [user], I want [feature] so that [benefit]"
- Aim for 15-20 total stories
- Add Acceptance Criteria (10 min): For your top 5 priority stories, add 2-3
acceptance criteria each
- Use Given-When-Then format
- Prioritize (5 min): Order stories by importance (MoSCoW from your brief)
- Create Kanban Board (10 min):
- Set up Trello/Jira/GitHub Projects
- Add all stories to "Backlog" column
- Invite all team members
Time: 45 minutes
Deliverable: Product backlog with 15-20 user stories in Kanban tool
Break Time
15 Minutes
Take a break. Next: Setting up your actual project repository!
Part B: Sprint Zero - Repository Setup and Configuration
Part B: Sprint Zero Setup
Sprint Zero: The setup sprint where you establish infrastructure,
tools, and conventions BEFORE building features.
Sprint Zero Goals:
- Set up version control repository
- Define project folder structure
- Install and configure tech stack
- Establish team coding standards
- Set up development environments for all team members
- Complete initial project skeleton
- Plan Sprint 1
Why Sprint Zero Matters
✓ With Sprint Zero:
- Everyone has working environment
- Team agrees on structure
- Version control from day 1
- Clear coding standards
- Ready to develop features
✗ Without Sprint Zero:
- Chaotic setup during development
- Inconsistent structures
- Merge conflicts nightmare
- Time wasted on setup
- Technical debt from start
Investment: Spend 1 week on Sprint Zero to save 4+ weeks later.
Setting Up Your Team Repository
Step 1: Create Repository
# On GitHub/GitLab:
# 1. Create new repository (one team member)
# 2. Name it clearly (e.g., "study-space-finder")
# 3. Add description
# 4.Initialize with README.md
# 5. Add .gitignore (select language template)
# 6. Choose license (MIT is common for student projects)
Step 2: Grant Team Access
- Settings → Collaborators → Add team members by username
- Give everyone "Maintainer" or "Write" access
Step 3: Everyone Clones
git clone https://github.com/your-team/your-project.git
cd your-project
Defining Project Folder Structure
project-root/
├── README.md # Project overview and setup instructions
├── .gitignore # Files to exclude from version control
├── docs/ # Documentation
│ ├── design-brief.md
│ ├── architecture.md
│ └── setup.md
├── frontend/ # Frontend application
│ ├── src/
│ ├── public/
│ ├── package.json
│ └── README.md
├── backend/ # Backend application
│ ├── src/
│ ├── tests/
│ ├── package.json (or requirements.txt)
│ └── README.md
├── database/ # Database schemas/migrations
│ ├── migrations/
│ └── seeds/
└── .github/ # GitHub Actions (CI/CD)
└── workflows/
Adjust based on your tech stack (mobile, ML, etc.)
Installing Tech Stack for All Team Members
Create setup.md with detailed instructions:
- Prerequisites:
- Node.js v16+ / Python 3.9+ / Java 11+ (specify versions)
- Database (PostgreSQL 14, MongoDB 5, etc.)
- Git 2.30+
- Installation Commands:
# Example for Node.js + React + Express
# Backend setup
cd backend
npm install
# Frontend setup
cd ../frontend
npm install
# Database setup
createdb project_db
- Environment Configuration: Create .env.example file with required variables
- Verification: Commands to test setup works
Establishing Team Coding Standards
Document in CONTRIBUTING.md:
- Code Style:
- Indentation (2 spaces vs 4 spaces vs tabs)
- Naming conventions (camelCase vs snake_case)
- File naming (PascalCase for components, kebab-case for files)
- Commit Messages:
- Format: "type: description" (e.g., "feat: add user login")
- Types: feat, fix, docs, style, refactor, test
- Branch Naming:
- Format: "type/description" (e.g., "feature/user-authentication")
- Code Review:
- All code requires 1+ reviewer approval
- No direct commits to main branch
Git Branching Strategy
Recommended: Feature Branch Workflow
# Main branch (always deployable)
main (or master)
# Create feature branch
git checkout -b feature/user-registration
# Work on feature, commit regularly
git add .
git commit -m "feat: add registration form validation"
# Push to remote
git push origin feature/user-registration
# Create Pull Request on GitHub
# → Team reviews code
# → Merge to main after approval
# → Delete feature branch
Rule: Never commit directly to main. Always use feature branches and PRs.
README.md Template
# Project Name
## Description
Brief description of what your project does and who it's for.
## Team Members
- Tom Johnson (Frontend Lead) - @Tomjohnson
- Bob Smith (Backend Lead) - @bobsmith
- Charlie Davis (Database) - @charliedavis
## Tech Stack
- Frontend: React 18, TypeScript
- Backend: Node.js, Express
- Database: PostgreSQL 14
- Hosting: Heroku
## Setup Instructions
\`\`\`bash
# See docs/setup.md for detailed instructions
npm install
npm run dev
\`\`\`
## Project Structure
See [Architecture Documentation](docs/architecture.md)
## Contributing
See [Contributing Guidelines](CONTRIBUTING.md)
## License
MIT
.gitignore Configuration
.gitignore: Specifies files that Git should ignore (not track).
# Example .gitignore for Node.js project
# Dependencies
node_modules/
package-lock.json (if using yarn)
# Environment variables
.env
.env.local
.env.production
# Build outputs
dist/
build/
*.log
# IDE
.vscode/
.idea/
*.swp
# OS
.DS_Store
Thumbs.db
# Database
*.db
*.sqlite
Critical: NEVER commit passwords, API keys, or credentials to Git!
Managing Environment Variables
Create .env.example (committed to Git):
# .env.example - Template for environment variables
DATABASE_URL=postgresql://username:password@localhost:5432/dbname
API_KEY=your_api_key_here
SECRET_KEY=your_secret_here
PORT=3000
Each team member creates .env (NOT committed):
# .env - Actual values (git ignored)
DATABASE_URL=postgresql://Tom:mypass@localhost:5432/project_dev
API_KEY=sk_test_abc123xyz
SECRET_KEY=my_super_secret_key_12345
PORT=3000
Why? Each developer has different local settings. Production has different
credentials. .env.example shows what's needed without exposing secrets.
Planning Sprint 1
Sprint Planning Meeting:
- Review Backlog: Look at your prioritized user stories
- Select Stories: Choose 3-5 stories team can complete in 1-2 weeks
- Break into Tasks: For each story, list technical tasks
- Assign Work: Team members volunteer for tasks
- Set Sprint Goal: One sentence describing sprint objective
Example: "Complete user authentication and basic product listing"
- Commit: Team agrees this is achievable
Tip: Better to under-commit and over-deliver than over-commit and fail.
Creating Initial Project Skeleton
Goal: Everyone can run "Hello World" from repo
Minimal Working Setup:
- Frontend: Single page that says "Hello World"
- Backend: Single API endpoint that returns JSON
- Database: One table with sample data
- All three connected and working
Test of Success: Any team member can clone repo, follow setup.md, and see
the app running locally in under 15 minutes.
Task 2: Complete Sprint Zero Setup
Instructions (Work in your project teams):
- Create Repository (5 min):
- One person creates GitHub repo
- Add team members as collaborators
- Everyone clones repo
- Define Structure (10 min):
- Create folder structure (frontend, backend, docs, etc.)
- Add README.md with project info
- Add .gitignore file
- Install Tech Stack (15 min):
- Each person installs required tools
- Document steps in docs/setup.md
- Test that basic skeleton runs
- Set Standards (5 min):
- Agree on coding style
- Decide on branch naming
- Create CONTRIBUTING.md
- Plan Sprint 1 (10 min):
- Select 3-5 user stories from backlog
- Move to "To Do" on Kanban board
- Assign initial tasks
Time: 45 minutes
Deliverable: Working repo with skeleton + documentation + Sprint 1 plan
Lecture 3 Summary
- Agile emphasizes iterative development and adaptability
- Scrum provides structure through sprints and ceremonies
- User stories capture requirements from user perspective
- Kanban boards visualize workflow and progress
- Sprint Zero establishes infrastructure before feature development
- Proper repository setup prevents chaos later
- Coding standards and workflows enable smooth collaboration
- Sprint 1 planning sets clear, achievable goals
Next Lecture:
Sprint 1 - Core System Foundations
Architecture patterns and building your first functional component
Before Next Lecture
- Submit to Moodle:
- Link to your team repository
- Screenshot of Kanban board with backlog
- Sprint 1 plan (selected stories + tasks)
- Complete Sprint Zero:
- Finalize repository setup
- Ensure all team members can run project
- Update documentation
- Start Sprint 1:
- Begin working on assigned tasks
- Hold first team standup
- Update Kanban board as you progress
- Research Architectures: Read about patterns relevant to your project (MVC, REST
API, etc.)
Help: Use Moodle forum for team questions or technical blockers.