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)¶

Prepare your issues so that the customer can understand what belongs together and what you would show first.

When an issue is related to another issue, reference the connected issue in its description using GitLab issue references.

Briefly explain why and how they are related. For example, one feature may depend on another, extend it, or together they may form a larger user-visible feature.

You do not need to create an order between issues just because they are in the same MoSCoW category.

Create the user demo order¶

Manually sort the GitLab Issue List into the order in which you would demonstrate the features to a potential customer.

This is not the implementation order.

Think of it as a marketing or sales demonstration: put the features near the top that are most likely to make the customer interested in the product and willing to pay more for it. You may use ideas from the Kano model: attractive/delighter and strong performance features are often good candidates to demonstrate early.

The tutor will act as the customer and use this demo order when determining the product's price.

Add a ## Priority Order section to README.md and link the manually sorted Issue List.

Quality¶

Quality work should make the product easy to understand and convincing from the customer's point of view. Important relationships between issues should be clearly referenced and briefly explained. Phrases such as “depends on”, “extends”, or “supports” are only examples of possible relationships, not a fixed list: the team must explain the concrete reason the issues are connected. For example, instead of writing “Issue #12 depends on #8”, explain that “#12 shows previously saved customer profiles, while #8 creates those profiles; without #8, #12 has no data to work with.” Instead of “#15 extends #9”, explain that “#9 allows users to search products by name, while #15 adds filtering by category and price to the same search flow.”

The manually sorted Issue List should form a deliberate demo order. Features shown early should be understandable and valuable even to someone who does not already know the implementation details or internal project context. The strongest, most attractive, or most useful features should appear near the top. For the first few issues, explain in writing why each feature is placed there from the customer's point of view. The first few issues should give the customer a clear and convincing picture of what makes the product worth buying.

The devil is in the details...

The below examples show how to explain the reasoning behind the demo order. The team should write a few sentences for each of the first few issues in their sorted list, explaining why they are placed there from the customer's point of view.

“The interactive route planner is shown first because a customer can immediately enter a start and destination and see the main purpose of the application without any explanation.”
Or: “The automatic report generator is shown before the administrator settings because it produces a visible result from the user's data, while the settings page mainly supports later configuration.”
Or: “The live dashboard is placed before CSV export because the dashboard is the feature users interact with directly and is more likely to demonstrate the value of the product during a short demo.”