TODO

The progress-checklist.pdf is due on the Sunday, 7th of September.

Goal of this document

As highlighted in Harry’s presentation at the start of the W6 tutorial (see: W5-sprint-end.pdf), there is a significant amount of work ahead.

This document breaks down that workload into manageable tasks, making it easier to see what’s required, discuss priorities, and coordinate as a team.

General Advice

• Prioritise progress checklist tasks
  • Focus on activities that contribute directly to the progress checklist
  • While other tasks may seem interesting, they risk consiming tasks without moving us closer to the deadline
  • Even the “boring” jobs are important if they check boxes
• Don’t get stuck
  • If you’re blocked, ask for help/clarification
  • Switch to a different task
  • Routinely report your progress for feedback
• Unsure what do do
  • Ask what to do
  • Check if anyone needs help
  • Review/edit others work

Useful resources

• progress-checklist-marking.pdf - Note that marking criteria differ between projects, so this key won’t exactly match Harry’s expectations (see discussion in the sections below).
• W5-sprint-end.pdf - The workshop slides that discuss the project-checklist
• table-of-contents-exemplar.pdf - If you’re unsure where something belongs in the documentation, review this exemplar (or ask on Discord).

NOTE: For most tasks, make sure it’s added to GitHub Projects before you begin, and update it once you’ve completed it.

Adherence to Agile Ceremonies

W5-sprint-end, page 7

Doing OK. Making sure this is up-to-scratch is everyones responsibility, although overall management is left to @Julian as the Scrum Master.

• Backlog (a work in progress) Oliver Julian Everyone
  • Estimates / priority assignment for current sprint Everyone
• Ceremonies Julian Oliver
  • Sprint Planning (in-progress: W3-sprint-planning.pdf) Julian
  • Retrospective¹ (maybe figure out a template!) Julian
• (Optional) Edit the W5 - Stand Up notes to better reflect your activities. Everyone

Process

Role Assignments

W5-sprint-end, page 9

Effectively done. Roles were assigned a while ago, just make sure your communication and tasks reflect your role (this is something that’s graded)

• Roles and Responsibilities is already assigned and responsibilities described.

Group Decision Making

W5-sprint-end, page 10

Doing OK. Our Decision Log is a good concept, but needs more items.

• Fill in incomplete Decision Log decision records Everyone Zoy (for DR09 - UI Library)
• Add more Decision Records Everyone
  • Look at high-lvl-system-arch.pdf - justify choices²
    • Amazon EC2 Julian
    • Postgres DB Julian
    • Map box Matthew
• Add Change Log for any decisions that have changed Oliver

Meetings

W5-sprint-end, page 11

Doing OK. If time, we could make the meeting notes more detailed but not a priority.

• Meetings notes Everyone
  • Link more decision records (makes meeting outcomes clear) Oliver
  • Add more action items (can be backfilled) Everyone
• Have at least one more meeting (or async meeting)
  • Finish W6 - Meeting 1 notes Oliver Julian

Communication

W5-sprint-end, page 12

Probably, “Below Expectations”. Especially our Discord chat history. However, if we do the other sections well, this should improve organically.

Internal communication: Please actively engage! Everyone

• Post what you’re working on
• Ask questions
• Give others feedback
• Send at least one message a day

External communication: Client is making this tricky, but there are still things to do.

• Set up documentation for client interactions Oliver
  • Section noting client communication struggles
  • General questions for client
  • Link things awaiting client review / feedback
• Prepare plan for presenting to client next tutorial (W6 Thursday) Everyone

Artefacts

Requirements

W5-sprint-end, page 14

First stage done. Just needs to be broken down further into User Stories.

• Breakdown of Reqs³
  • Functional
  • Non-Functional
  • Out-of-scope
  • Review by all team members Everyone
  • (Maybe) change W3-sprint-planning.pdf to better match this. Julian
• IMPORTANT Break down into user stories Zoy Everyone
  • Also see: Breakdown of Reqs
  • Start with those specific to the current / next sprint (e.g. login / onboarding)
  • Remaining user stories
• Refined and add to GitHub projects⁴ Oliver Julian Everyone
  • Add user stories to epics/requirements/tasks (maybe in description section)
  • Priority assignment
  • Story point estimation
• Find a way to document (major) requirement changes (shouldn’t rely on commit history for this) Oliver

NOTE: Writing requirements is an incremental process - we’ll likely identify more throughout the project and have to add more user stories progressively.

Frontend Design

W5-sprint-end, page 15

Going well. However, frontend design is a large task and a major deliverable.

Proposal

The key point here is that for this sprint Harry is not expecting a high-fidelity UI prototype of the whole app - this is not realistic both due to the scale of the app and the lack of client interaction.

So, for this sprint/progress checklist, we should focus on the “initial-setup” phase of the app: login, authentication, onboarding (everything before the user enters the main app). We should get the UI design to a polished state up to this point, and not much further (for now) since we are under time-constraints.

That means completing the following artefacts for this section:

• Low-fidelity prototype (wireframe)
• High-fidelity prototype (Figma)

It would be more valuable to design a smaller section fully, rather than the whole app partially. With a fully complete design, frontend coding can confidently start. In general, an alternating design-code, design-code, etc. will be our main workflow.

• Make a (team) decision on whether we will use a UI Component Library⁵
• Low-fidelity prototype of setup
  • Mobile - (needs review: wireframe-app-setup.pdf) Oliver
  • Web - (not a priority, focus on mobile first)
• High-fidelity prototype of app setup (Figma)
  • Mobile
    • Documentation / Justification Alex Zoy Matthew (started for you by Oliver)
  • Web
• UI-Documentation (might just be one long page) Everyone
  • Description of methodology (e.g. are we “simple, but effective UI”)
  • Inspiration (e.g. Imprint, HappyCow, etc.)
  • Theme/colour palette (cite the brand-guidelines.pdf)
  • Justification / thought process behind decisions
• Low-fidelity prototype of other parts of the app - NOT a priority for this week.
  • Map
  • Map filtering

Architectural Design

W5-sprint-end, page 16

LOTS of work to do here. The L4-design.pdf lecture outlined the 4+1 architecture approach, which Harry also recommended. The exemplar followed this structure, with a page for each “view” containing the relevant artefacts and justifications (see: table-of-contents-exemplar.pdf). The list below is not exhaustive - there may be other diagrams worth including - but aim for at least one artefact per view.

• Architecture goals and constraints (see: L4-design, page 13)
• System diagram (done: high-lvl-system-arch.pdf)
  • NOTE: We need to find out what ‘view’ this artefacts belongs in.
• Logical view
  • Domain / Class Diagram (maybe not necessary for us?)
  • Database diagram (definitely, at least a draft) Julian
• Development View (dynamic aspects of the system)
  • Maybe a web-flow routing for user sign-in/setup Oliver
  • System sequence diagrams (maybe not necessary)
• Process View
  • Package diagram (maybe) Oliver
• Physical View
  • Deployment pipeline (diagram + documentation) Julian

Just completing a diagram is not sufficient

Diagrams should have written notes linked with them that justify the decisions within them - perhaps link with a decision record / requirement. Justifications should include references to scalability, extendability, maintainability.

Software: preferred software for diagrams is Lucid Chart and export to pdf. For simple diagrams, consider Mermaid which is renders natively in Obsidian.

Codebase

W5-sprint-end, page 17

Setup required. As Harry noted, code is not the focus of this sprint and an MVP is not expected. The key client deliverable is the UI prototypes. Our priority should be to set up and organise the codebase so it’s ready for the next sprint. At most, this might include basic frontend/backend scaffolding, but this is not a priority compared to the other tasks listed.

• README Matthew (for Frontend), Julian (for Backend) Oliver (to help)
  • Project title / description
  • Installation / setup instructions (if code scaffold is setup)
  • Build & deployment instructions
  • Include links to relevant docs (e.g. contribution guidelines)
• Dev guidelines Julian Oliver
  • Contribution guidelines (done: Git Contribution Guidelines)
  • Code style enforcement (Prettier / ESLinter setup / guidelines - documentation needed too)
• Start coding (NOT a priority)
  • Backend setup Julian
  • Frontend setup Matthew

Testing & Deployment

W5-sprint-end, page 18

Some work required. Expectations for this sprint are low, but there are still tasks to complete. The main focus should be on researching, planning, and documenting these choices. If time permits, setting up and implementing basic scaffolds of the workflow can also be worthwhile, though this is secondary.

• Testing (research/plan) Oliver Everyone (e.g. postman for API)
  • Link to decision records if big
• Deployment (research/plan) Julian
  • Maybe a deployment pipeline diagram (see Architectural Design)
• Acceptance criteria for User Stories Zoy

Other

As mentioned in the intro, the above tasks are the priority - they are what’s going to be graded. Nevertheless, there are a few miscellaneous tasks:

• Quartz deployment of this documentation⁶ Julian
  • Index page
  • Custom theme (low priority)
  • Auto-deployment on push (low priority)
• General tidy-up of Obsidian docs before submission Oliver Everyone

Footnotes

1. Technically, this sprint does end soon, so we will need to do a retrospective - hopefully this week is productive so we have things to talk about! ↩

2. For areas with many interrelated decisions (e.g. backend architecture), a tailored note may be clearer than separate decision records. A single document can explain how the choices collectively support scalability, maintainability, and future extensibility, with alternatives mentioned more briefly. Link this instead of a decision record in the decision log. ↩

3. Where possible and appropriate, please refer to these requirements in written discussion using the tags. For example, “To support FR3 we chose this approach because…” ↩

4. Requirements might not map nicely to “Requirement” issue types - they may correspond to Epics, Requirements, or Tasks - or neither, in which case they should just be referenced. ↩

5. This is a very important decision, and should be made as a team (meeting/discord). If a UI Library is decided on, the high fidelity prototype should be built/adapted using it’s assets. ↩

6. In the progress-checklist.pdf we submit, we will include links to this, so it’s is important. ↩