MVP Development and Execution (Stage 4)

Stage 4 turns the Stage 3 technical documentation into an execution plan for the Rizi MVP. The stage is planned from April 30, 2026 to May 22, 2026 and uses Jira, GitHub, Vercel, Next.js, and Supabase as the working toolchain.

0. Assignment Context

1. Objectives

• Implement the MVP based on the reduced technical documentation from Stage 3.
• Divide work into short Agile sprints with clear owners, deadlines, and dependencies.
• Use Jira project KAN to track planning, implementation, QA, bugs, reviews, and retrospectives.
• Use GitHub pull requests to protect branch quality and keep source-control history clean.
• Validate the MVP on the staging domain: https://staging.rizi.app.
• Collect evidence for manual QA review before the final submission date.

2. Roles and Responsibilities

All team members can implement assigned technical tasks, but PM, SCM, and QA responsibilities stay explicit during the whole stage.

3. Plan and Define Sprints

4. User Stories, Tasks, and Dependencies

The Stage 4 backlog breaks Stage 3 user stories into smaller Jira stories/tasks. Work is assigned with dependencies so the team can avoid blocked implementation.

5. Sprint Activities

Each sprint follows the same rhythm:

• Sprint planning: define sprint goal, scope, owners, due dates, and dependencies.
• Daily stand-up: each member reports completed work, next task, and blockers.
• Development: developers complete assigned Jira tasks and keep branches small.
• Code review: SCM checks pull requests before merge into staging.
• QA testing: QA validates completed work and reports issues in Jira.
• Sprint review: team demos completed work and records links/evidence.
• Sprint retrospective: team records what worked, what failed, and the change for the next sprint.

6. MoSCoW Prioritization

Must Have

• Stage 4 documentation page and deliverable section.
• Jira epic and full backlog.
• GitHub staging branch workflow and PR process.
• Staging deployment target confirmation.
• Supabase staging environment and RLS confirmation.
• Organizer registration and login.
• Event creation, editing, and publishing.
• Public event page.
• Guest registration.
• Guest list.
• Manual guest check-in.
• API testing evidence.
• Manual QA smoke test on staging.
• Final deliverable links and manual QA review request.

Should Have

• Google Maps venue details and directions validation.
• Agenda and speaker details.
• Sprint review notes and retrospective notes for each sprint.

Could Have

• Extra screenshots for non-critical flows.
• Extra polish for the docs portal if core deliverables are already ready.
• Additional automation beyond the required smoke checks.

Won't Have in Stage 4 MVP

• Online payments.
• Premium plans and billing.
• Marketplace modules.
• Custom domains as an MVP requirement.
• Advanced analytics beyond required validation evidence.

7. Execute Development Tasks

Development work follows the sprint plan:

• Developers work only on Jira-assigned tasks for the active sprint.
• Each implementation task uses a focused branch named with the Jira key.
• Pull requests must include the linked Jira issue, summary of changes, and validation notes.
• SCM confirms that branch scope, build status, and review feedback are handled before merge.
• QA tests completed tasks in staging or a preview deployment and records pass/fail evidence.

Example Sprint 2 API workflow:

• Owais implements or validates guest registration, guest list, and check-in endpoints.
• Shaden validates frontend integration with public event and organizer pages.
• Shaden/SCM reviews the PR before merge into staging.
• Nowal tests the endpoints with Postman/API checklist and records evidence.

8. Monitor Progress and Adjust

Progress is tracked in Jira and reviewed during daily stand-ups.

Sprint goals may be adjusted only by the PM after the blocker, impact, and replacement priority are recorded in Jira.

9. Jira Backlog

Primary Jira epic: KAN-24 Stage 4 - MVP Development and Execution

10. GitHub and Source-Control Workflow

• Implementation repository: TariqRash/Rizi_Events_Planner
• Documentation repository: TariqRash/RiziEvents
• Active implementation base branch: staging
• Short-lived branches:
  • feature/[jira-key]-short-name
  • fix/[jira-key]-short-name
  • docs/[jira-key]-short-name
• Every task must link its Jira issue, branch, and pull request.
• Pull requests target staging first.
• SCM verifies code review, branch scope, and build status before merge.
• main is updated only after sprint review, QA evidence, and staging validation.

11. Vercel, Next.js, and Supabase Execution Notes

• Staging domain: https://staging.rizi.app
• Production domain: https://www.rizi.app
• Docs domain: https://doc.rizi.app
• Web app stack: Next.js on Vercel.
• Backend platform: Supabase Auth, Supabase Postgres, Storage, and Row Level Security.
• SCM must confirm the Vercel project, branch mapping, build status, and environment variable names.
• Supabase/API owner must confirm migrations, core tables, RLS policies, and staging data access.

No secret values should be added to Jira, GitHub, or this documentation portal.

12. Progress Metrics

13. Sprint Reviews and Retrospectives

Sprint reviews happen at the end of Sprints 1, 2, and 3.

Review notes must include:

• Completed tasks and Jira keys.
• Demo scope.
• Blockers or risks.
• Follow-up tasks.
• Links to merged PRs or staging evidence.

Retrospectives must answer:

• What worked well?
• What challenges appeared?
• What should change in the next sprint?
• Are priorities or assignments still correct?

14. Final Integration and QA Testing

Final integration happens in Sprint 3 after core flows are available on staging.

• Validate that frontend pages correctly use Supabase-backed data.
• Validate that organizer-only views remain protected.
• Validate that public event pages only show published events.
• Validate that guest registration writes the expected guest record.
• Validate that guest list and manual check-in reflect the same source of truth.
• Fix critical bugs before final submission.
• Record staging URL, test date, tester, result, and evidence link for each required flow.

15. QA and Testing Plan

Automated checks

• Run the app build before staging deployment.
• Run existing unit/integration tests where available.
• Add targeted tests for high-risk auth, event, registration, and check-in behavior when time allows.

Manual QA scenarios

16. Requirement Coverage Matrix

17. Reference Resources

• Sprint planning: Scrum.org Sprint Planning
• Agile task tracking: Planyway Trello Agile project management
• Software testing basics: Guru99 Software Testing
• API testing: Postman learning center
• Browser testing: Chrome DevTools overview

18. Deliverables

19. Final Submission Checklist

• Stage 4 docs page is live.
• Jira epic and backlog exist.
• GitHub source repository is linked.
• Vercel staging environment is linked.
• Supabase staging validation task is tracked.
• Sprint review and retrospective tasks are ready for updates.
• Manual QA smoke-test task is ready.
• Manual QA review request task is ready for May 22.