Priority Order
Salary
This task pays a fixed salary of 12 MVP points, plus up to 24 quality points for exceeding the minimum requirements — for a total of 36 points, with a maximum of 6 points per person.
Background¶
This section guide you to some additional material that will help you understand the task better. It is not mandatory to read it, but it can be useful for your team.
Minimum Viable Product (MVP)¶
Your team defines one clear development order for all features with no ties. Everyone should be able to answer: “Which feature do we build first, second, third…?” The goal is to avoid chaos, make planning simple, and let you deliver a small working slice early. Start from your six (or more) feature issues and agree on a strict sequence.
To complete the MVP, sort your GitLab issues into a single, unambiguous order (manual sorting in the Issue List or on the Issue Board). The order in the board/list must match the order you communicate in the project. This becomes your build plan for the next sprints and will guide demos and pricing.
Example: Team 'ByteBusters' lock the sequence
They set: Add book → List books → Search → Save to file → Load from file → Delete. No duplicates, no ties. Everyone can say the next two items without checking notes.
Technical Details¶
Create (or use) a GitLab Issue Board and drag features into a top‑to‑bottom list; or manually sort the issue list so it shows the same order. Add a ## Priority Order section in README.md and link the relevant issue board or list. If two items seem equal, pick one to go first—ties cause confusion and slow you down.
When ordering, keep it beginner‑friendly: build dependencies first (e.g., “Save” before “Load”), favor vertical slices that can be demoed (input → processing → output), and place MVP‑critical features early. Avoid spreading the team across too many items—finishing small pieces fully is better than starting many.
Quality¶
Quality means your order is well‑reasoned, explained in one short paragraph, and robust to surprises. In README.md (below the list), briefly justify the sequence using simple criteria: dependencies, user value, risk (do risky bits early), and learning value. Add two tiny contingency rules, e.g., “If blocked >1 day, swap with the next independent item,” and “Re‑check order after each demo.”
You can use a lightweight method like MoSCoW (Must/Should/Could) or a quick 1–5 value vs. 1–5 effort note in each issue to explain why some items come earlier. Link obvious dependencies between issues and mark at least one early demoable slice in the first three items to ensure visible progress.
Example: Team 'NullPointers' justify simply
They write: “We start with input/storage basics, then searching, then file I/O. This delivers a demo by week 2 and reduces risk.” Rule: “If Save blocks, we switch to Search for a day.”.
Example: Team 'PixelPenguins' plan for the unknown
For their cellular automaton: Grid → Toggle cell → Step one generation → Run N steps → Save pattern → Load pattern. They note: “If stepping logic is tricky, we pause Run N steps and finalize Save/Load to keep momentum.”