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 Item | Status | Notes |
|---|---|---|
| Scope definition | In Progress | Event features being clarified |
| Team role assignment | Done | |
| Task tracking board | Starting | Got access from previous team and started setting GitHub Project and coordination strategy |
| IT department contact | Done | Helaly 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
Resolve SSH Access Blocker
- Escalate to mentor/client
- Explore VPN solutions
- Consider alternative hosting
- Delegate to IT department
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?