Skip to content

Sprint 2 Retrospective

What Went Well

Client Communication

  • Clear progress on authentication discussion
  • Product vision becoming clearer with requirements documented
  • Identified concrete feature ideas (follow feature, location-based notifications)
  • Client receptive to process improvements (auto-approval, reporting system)
  • Started communication with IT department

Technical Direction

  • Migration blockers identified (SSH access issue for services outside campus)
  • Options for alternative approaches discussed (starting fresh, university GitHub, contact IT department to resolve the issue)
  • Database access pathway established through IT department

What did not go well

Requirements Gaps

  • Event types not clearly defined
  • Success metrics lack specificity
  • Required event information (host contact, etc.) not documented
  • User role definitions still pending

Action Items Status

From Previous Retrospective

Action ItemStatusNotes
Scope definitionIn ProgressEvent features being clarified
Team role assignmentDone
Task tracking boardStartingGot access from previous team and started setting GitHub Project and coordination strategy
IT department contactDoneHelaly and Client handling this

Sprint 2 Achievements

Requirements Engineering

  • Discussed requirements approach with mentor
  • Identified need for priority criteria
  • Discussed use case documentation needs
  • Identified inherited requirements consideration

Feature Discovery

  • Auto-approval concept for events
  • Reporting system consideration
  • Follow feature identified
  • Location-based notifications
  • University/partner events inclusion

Migration Planning

  • SSH access blocker identified
  • Alternative options discussed (fresh start, university GitHub, delegate it to IT department to resolve)
  • Database integration path discussed and waiting approval

Metrics & Success Criteria Discussion

Proposed Success Metrics (from mentor)

  • Event count threshold (e.g., 10 events)
  • Attendee diversity (e.g., 3+ different attendees per event)
  • Community engagement metrics

Pending Decisions

  • What event types count toward success?
  • What engagement types matter?
  • Specific numerical targets?

Lessons Learned

What Worked

  • Regular client meetings maintain momentum
  • Mentor guidance on requirements engineering is valuable
  • Early blocker identification prevents surprises

What Needs Adjustment

  • SSH access
  • Requirements need more specificity
  • Success metrics need definition earlier

Action Points

High Priority

  1. Resolve SSH Access Blocker

    • Escalate to mentor/client
    • Explore VPN solutions
    • Consider alternative hosting
    • Delegate to IT department
  2. Requirements Documentation

    • Create use case diagrams
    • Define event types and required fields
    • Document success metrics with specific thresholds
    • Include inherited requirements

Medium-Low Priorities

  • Feature specification (follow, location notifications)
  • Event auto-approval design

Questions

For Client

  • What specific event types are needed?
  • What success metrics matter most: events count or attendee count?
  • Can we get temporary SSH/VPN access?
  • Timeline for IT department response?

For Team

  • Fresh start vs. working with existing codebase?
  • University GitHub migration timeline?

IU Alumni Platform Documentation