Sprint 1 Review & Sprint 2 Start

Session Timeline

Learning Objectives

• Conduct effective sprint reviews and demonstrations
• Run productive sprint retrospectives
• Understand advanced Git workflows (branching, rebasing, conflict resolution)
• Master pull requests and code review processes
• Learn from Sprint 1 successes and challenges
• Plan Sprint 2 with improved velocity estimates
• Identify and address team blockers
• Continuously improve team processes

Sprint Review vs Sprint Retrospective

Conducting an Effective Sprint Review

Review Structure:

1. Introduction (2 min): Sprint goal reminder, what was planned
2. Demo (15-20 min): Show working features (live, not slides)
3. Discussion (5-10 min): Questions, feedback, suggestions
4. Backlog Update (5 min): Adjust priorities based on feedback

Demo Presentation Tips

Tell a Story:

Preparation:

• Test demo flow beforehand (no surprises!)
• Have backup screenshots if live demo fails
• Assign who presents which feature
• Keep within time limit (5-7 min for student teams)

The Purpose of Sprint Retrospectives

Three Core Questions:

1. What went well? (Celebrate successes, repeat these)
2. What didn't go well? (Identify problems, don't blame)
3. What will we change? (Actionable improvements for next sprint)

Retrospective Format: Start-Stop-Continue

Process:

1. Everyone writes ideas on sticky notes (5 min)
2. Group similar items (5 min)
3. Discuss each category (15 min)
4. Vote on top 3 action items (5 min)
5. Assign ownership and track (5 min)

Example Retrospective Outcomes

Git Branching Strategies

Branch Types:

• main: Production-ready code (always deployable)
• develop: Integration branch (optional for larger teams)
• feature/*: New features (feature/user-login)
• bugfix/*: Bug fixes (bugfix/login-error)
• hotfix/*: urgent production fixes (hotfix/security-patch)

Advanced Git Workflow

# Keep your branch up-to-date with main
git checkout main
git pull origin main
git checkout feature/my-feature
git merge main  # Or: git rebase main (advanced)

# Interactive staging (commit parts of file)
git add -p  # Review each change and stage selectively

# Amend last commit (fix typo in message/add forgotten file)
git add forgotten-file.js
git commit --amend --no-edit

# Stash changes temporarily (switch branches without committing)
git stash
git checkout other-branch
# ... do work ...
git checkout feature/my-feature
git stash pop

# View commit history graphically
git log --oneline --graph --all

Resolving Merge Conflicts

// Example conflict in code
function getUserName() {
<<<<<<< HEAD
  return user.fullName;  // Your change
=======
  return user.displayName;  // Teammate's change
>>>>>>> feature/update-user-display
}

Resolution Steps:

1. Open conflicted file in editor
2. Look for conflict markers (<<<<<, =======, >>>>>)
3. Decide which change to keep (or combine)
4. Remove conflict markers
5. git add resolved file
6. git commit to complete merge

Pull Request Best Practices

Writing Good PR Descriptions:

## What
Implements user registration feature (#23)

## Changes
- Added registration form component
- Created POST /api/register endpoint
- Added email validation and password hashing
- Updated user schema with email_verified field

## Testing
- Manually tested happy path
- Tested validation errors
- Checked database insertion

## Screenshots
[Screenshot of registration form]

Tip: Link to user story/issue number for traceability

Code Review Checklist

What to Check:

• Functionality:
  • Does it meet acceptance criteria?
  • Are there edge cases to consider?
• Code Quality:
  • Readable and well-structured?
  • Follows team conventions?
  • No code duplication (DRY principle)?
• Security:
  • Input validation present?
  • No hardcoded secrets?
• Testing:
  • Are there tests?
  • Do existing tests still pass?

Part B: Sprint 1 Review & Sprint 2 Planning

Review Structure:

1. Quick introduction - sprint goal and stories planned
2. Live demo of completed work
3. Mention incomplete items honestly
4. Answer questions
5. Gather feedback

Demo Day Guidelines

For Presenting Teams:

• Show working software (not code or slides)
• Demonstrate from user perspective
• Stick to time limit (5-7 minutes)
• Be prepared for questions

For Audience Teams:

• Take notes on interesting approaches
• Ask constructive questions
• Share ideas and suggestions
• Learn from others' successes and challenges

Understanding Velocity

Using Velocity:

• Helps predict what team can achieve
• Use average of last 2-3 sprints
• Don't over-commit in Sprint 2
• Velocity typically increases over time (team gets faster)

Planning Sprint 2

Planning Process:

1. Review Backlog: Look at prioritized user stories
2. Consider Velocity: How much did you complete in Sprint 1?
3. Select Stories: Choose stories totaling ~your velocity
4. Apply Retrospective Learnings: Use improved processes
5. Break into Tasks: Detail technical work needed
6. Set Sprint Goal: One sentence objective

Introducing Continuous Integration (CI)

Benefits:

• Catch bugs immediately when code is pushed
• Ensure tests pass before merging
• Maintain code quality standards
• Team confidence in main branch

# .github/workflows/test.yml - GitHub Actions example
name: Run Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test

Establishing "Definition of Done"

Managing Technical Debt

Common Sources:

• Skipping tests to save time
• Copy-pasting code instead of making reusable
• Hardcoding values instead of configuration
• Missing documentation

Managing It:

• Track debt items in backlog (label as "tech-debt")
• Allocate 20% of sprint to paying down debt
• Don't let it accumulate (harder to fix later)
• Refactor as you go when touching code

Before Next Lecture

1. Start Sprint 2 Work:
   • Begin assigned tasks
   • Apply retrospective action items
   • Hold regular standups
2. Document Sprint 1:
   • Save retrospective notes (docs/retrospectives/sprint1.md)
   • Update README with Sprint 1 achievements
3. Improve Processes:
   • Implement action items from retrospective
   • Update team conventions if needed
4. Read About Ethics:
   • Review BCS Code of Conduct (link on Moodle)
   • Skim GDPR basics