Agile delivery · web app · Team of 2 · Advanced Software Engineering, JCU · 2025
Running the sprints and the docs for a two-person web app
A two-person Agile project: a booking system for the JCU Singapore gym. My teammate Sein Linn designed the system and wrote most of the code. I ran our sprints and led the documentation, so this case study is about how we planned, tracked and reported the work.
01 Overview
The project
For Advanced Software Engineering we built a web prototype that handles membership, session booking and administration for the James Cook University Singapore gym. We worked in two iterations with user stories, planning-poker estimates, a GitHub Project board, and burndown and velocity charts.
There were two of us. Sein Linn designed the architecture and wrote most of the application code. I ran the Scrum process and led the documentation: turning the brief into stories, planning and tracking both sprints, and writing up what happened.
02 Problem & users
Two kinds of users with different jobs
Members (students and staff)
- Register online with a JCU account
- Book sessions in advance, with live capacity
- See upcoming bookings and history
Administrators
- Approve, reject or suspend accounts
- Create and manage sessions
- Track usage, bookings and billing records
We wrote eight user stories with a first estimate of 27 days in total, and prioritised registration, session booking and admin user management as must-haves.
03 My role
What I did
- Scrum coordination: sprint planning and task allocation, the GitHub Project board (issues, labels, pull requests), and the burndown and velocity charts for both iterations.
- User stories: each with a priority, an estimate, acceptance criteria and a task breakdown.
- Documentation: iteration reports, retrospectives, technical documentation and the final report.
Sein Linn designed the system architecture and built most of the app, including session booking, the admin and analytics dashboards, reminders and the virtual tour.
04 Approach
How we ran the project
Write stories someone can test
Every story had acceptance criteria, not just a description. Registration, for example, needed a form with name, JCU email and password; password validation and hashing; a confirmation on signup; and secure storage. That gave us a clear definition of done for each feature.
Get a working prototype first
Iteration 1 took the high-priority stories (registration, session booking and admin user management) plus managing bookings, so the core flow worked end to end early. Iteration 2 added booking statistics, session reminders and the virtual tour.
Plan from measured velocity
Iteration 1 was planned at about 3.5 productive days per developer per week. Iteration 2 came in at 2.4, because its stories were heavier on logic (data aggregation and scheduling), and the velocity chart recorded that slowdown.
Make progress visible
Work was tracked on the GitHub Project board with issues, labels and pull requests, and I kept the burndown and velocity charts up to date through each iteration, so we could see whether we were on track.
Turn the retrospective into actions
After iteration 1 we agreed on specific changes: smaller tasks, backend-heavy work earlier, interface time planned in from the start, a test checklist for each story, and clear ownership of security-critical features.
05 The app
What the team delivered
The app uses the Next.js App Router, with API route handlers as the backend and PostgreSQL on Neon. New members register and wait for admin approval, then book sessions with live capacity; admins manage accounts, sessions, bookings and billing.
06 Results
What we delivered
- user stories planned and estimated
- 8
- iterations, 3 Jun – 30 Jul 2025
- 2
- person-days of work (32 + 21)
- 53
Why 27 days became 53. The first backlog estimate was 27 days for all eight stories. When we broke the stories into tasks at iteration planning, the estimate grew to 51 person-days (30 + 21), and we logged 53. Our retrospective names that underestimate as the main lesson.
By the end of the second iteration the app covered registration with admin approval, session booking with capacity tracking, booking history, an admin console with statistics and billing records, and a virtual gym tour. Session reminders reached a working backend.
07 Limitations & learning
What I’d do differently as Scrum coordinator
- Estimate at task level from the start. The first estimate nearly doubled once stories were broken into tasks. Tasking before committing would have given us a realistic plan on day one.
- Check acceptance criteria against the build before sign-off. Our registration story asked for passwords of 8+ characters with mixed case, a number and a symbol; the finished server accepts 6+. The per-story test checklist from our retrospective is exactly what catches gaps like this.
- Test edge cases inside the sprint. Duplicate bookings and bad inputs were tested late, so small bugs surfaced at the end instead of during development.
- Re-scope slipping stories early. Managing bookings ran over in iteration 1, and reminders finished with only the backend working. Splitting those stories sooner would have kept the board honest.
08 Links