Skip to content

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 9 points per person.

Background

This section guides you to some additional material that may help you understand the task better. It is not mandatory to read it.

Minimum Viable Product (MVP)

Your team turns the existing MoSCoW prioritization into one clear and doable development roadmap.

The roadmap must answer:

  • Which issue do we start with?
  • Which feature do we want to ship first?
  • What comes next?

Start from the MoSCoW priorities assigned during Cost Estimation. Features in different categories already have a broad priority, but features inside the same category still need to be ordered.

For every tie inside a MoSCoW category, compare the features and decide which one should come first. The final roadmap must have no unresolved ties.

Dependencies between issues must also be observed. A feature should not be placed before another feature that it requires.

Example: Team 'ByteBusters' break a Must Have tie

"Add book", "List books", and "Search by title" are all Must Have. "List books" requires books to exist, and "Search" becomes useful only after there is data to search. The team therefore orders them: Add book → List books → Search by title.

Technical Details

Use GitLab as the source of truth for the roadmap.

Create or use an Issue Board, or manually sort the Issue List, so the top-to-bottom order represents the planned development order. Add a ## Priority Order section in README.md and link the relevant board or issue list.

When building the roadmap:

  1. start from the existing MoSCoW classification;
  2. identify ties inside each category;
  3. check dependencies between issues;
  4. break each tie using a meaningful reason;
  5. order the features into a sequence the team can realistically follow;
  6. check that the early part of the roadmap leads toward a usable, demonstrable product.

Useful tie-breakers include:

  • one feature depends on another;
  • one feature unlocks several later features;
  • one feature is more important for the first usable version;
  • one feature reduces an important risk;
  • one feature enables earlier feedback or demonstration;
  • the customer considers one feature more important.

Alphabetical order, issue number, or an unexplained arbitrary choice are not meaningful reasons.

Quality

Quality means the roadmap is actionable, dependency-aware, and justified.

The order should not be only a sorted list. The team should be able to explain why the first feature comes first, why tied MoSCoW items were ordered as they were, and why the roadmap is realistic to execute.

Document important tie-breaking decisions and dependencies in the relevant issues or next to the priority order in README.md.

Revisit the roadmap when new information, blockers, or changed dependencies make the previous order impractical.

Example: Team 'NullPointers' create a doable roadmap

"Save to CSV" and "Load from CSV" are both Should Have. The team puts Save first because Load depends on the file format established by Save. They then place an independent feature after Save so the team still has useful work available if Load becomes blocked.