Cost Estimation (Time & Price)

Salary

This task pays a fixed salary of 12 MVP points, plus up to 30 quality points for exceeding the minimum requirements — for a total of 42 points, with a maximum of 7 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)¶

By the end of this task every feature has two estimates: (1) a time cost in person-hours and (2) a price in team points agreed with the tutor (the “customer”). Your goal is to make planning real: how long will it probably take, and how many points is it worth if delivered? Keep numbers simple (whole hours/points where possible) so the team can compare items at a glance.

To complete the MVP, for each feature issue add two labels following a consistent pattern: cost : <N> person hour and price : <M> point. The time cost comes from your team’s estimate. The price is finalized after you interview the tutor (preferably during class); record the agreement on the issue (label + short comment like “Tutor set price on 2025-09-18”). No feature should be left without both labels.

Example: Team 'ByteBusters' get their prices

They estimate "Add book" at 3 person-hours and "List books" at 2 person-hours. In class they show their plan; the tutor sets price 12 points for the first and price 8 points for the second. Issues receive labels cost : 3 person hour, price : 12 point, etc., plus a one-line comment noting the date and details of agreement.

Technical Details¶

A simple way to estimate time is relative story points → hours conversion:

1) Pick a tiny reference task you understand (e.g., “print menu + read choice”) and call it 2 points.
2) Compare other features to it (2, 3, 5, 8 points—keep the scale small).
3) Do/recall one similar task to calibrate: if your 2-point task took ~3 hours, then 1 point ≈ 1.5 person-hours. Convert all features to hours with this ratio and round to simple numbers. If unsure, ask the tutor to double-check your hour estimates—it’s expected at this level. Add a small buffer (+10–20%) only if you have a known risk (new library, tricky parsing).

For price, book a 5–10 minute tutor interview (ideally in class): show your feature list with costs, explain expected value for the user, and ask for a price. The tutor decides the final price; you then add price : <M> point and a brief comment. Keep your labels uniform (cost : N person hour, price : M point) so sorting/filtering works well in GitLab.

Quality¶

Quality means your estimates are reasoned, consistent, and documented. In each feature issue add a short “Why this cost?” line (1–2 sentences: assumptions, risks, who will do it) and note any dependency that might change the effort. After you finish your first delivered feature, quickly re-check your calibration (did 3h actually take 4h?) and adjust the point→hour ratio for the remaining items. Good teams keep estimates alive, not frozen.

Also make your price discussion transparent: write one sentence about why the feature is valuable (who benefits and how), so the tutor’s decision is clear to future readers. Optionally, summarize in README.md a tiny table of Feature → cost (ph) → price (pt) to help planning. The aim is not perfect prediction, but shared expectations and a plan you can actually follow.

Example: Team 'NullPointers' recalibrate early

Their 2-point reference took 4 hours (not 3), so they adjust: 1 point ≈ 2h and update remaining issues. They add a sentence like “Parsing CSV is new to us; +1h buffer included.” After a short tutor chat, prices are confirmed and noted on each issue.

Example: Team 'PixelPenguins' keep it simple

They use points {1,2,3,5} only. Menu work is 2 points (~3h), file save is 3 points (~5–6h). They ask the tutor to sanity-check their hours (“We’re beginners—does 6h for save/load seem fair?”). The tutor adjusts one item’s price and they record it with the label and a dated comment.