Week 6: Cost Estimation

Goal

On this week teams will work on they own planed features, user stories, or use-cases for their project. They will estimate their required effort and gained value. This will help them to prioritize their work for the next milestones.

Expected Results Before This Week

Weekly Progress Check rules

  • Be prepared to show your results at the beginning of class.
  • Presenting teams are selected randomly each week. The same team may be selected repeatedly.
  • If your team is selected and there is no relevant work recorded before the session, 3 points will be deducted. Any relevant demonstrable work avoids the deduction: the weekly score is then between 0 and +3 points, depending on quality and completeness.
  • A missing expected result can cause a point deduction only once, but you should still catch up: later work may depend on it, and these results usually contribute to the tasks required for your desired grade. More about salary for tasks

How Weekly Progress Checks work · More about penalty and bonus points

This week's expected results

  • Define 6–8 concrete, user-visible features for your project as individual GitLab issues, following the Feature Definitions task: each issue should state the user value, show a small usage example, define what counts as done, and carry the feature label; list and link them from the README.md. These are your initial feature seedlings for this week's cost estimation and prioritization, so they should be distinct and concrete enough to compare, estimate, and order—not polished or final.
Title Duration
Moscow 10 minutes
Intermediate Topics -
TBA

Notes for tutors:  🗒️

1: Moscow (10 minutes)

Why is this useful for me?

Things you learn and experience in this session will help you to solve the following tasks:

Background

Prerequisites

  • Features or user stories are listed and described as GitLab issues or in a project management tool.

Activities

  • Each team will categorize the features or user stories into the following categories:
    • Must Have: Essential features that are critical for the project's success. Without these, the project would be considered a failure.
    • Should Have: Important features that add significant value but are not critical. The project can still succeed without them, but their absence may impact user satisfaction.
    • Could Have: Desirable features that enhance the user experience but are not essential. These can be included if time and resources permit.
    • Won't Have (this time): Features that are agreed to be excluded from the current project scope. These may be revisited in future iterations.

When everything is a Must, nothing is!

Now that you have categorized your features and user stories, take a closer look at your Must-have list. It is a common trap in software development to label too many things as absolute necessities. However, not all Musts are created equal. Discuss with your team: if you could only deliver one of these 'Must-have' items first, which one would it be? Take a step back and review your Must-have items. A common challenge in prioritization is realizing that some Musts are more critical than others. Your next task is to prioritize within your Must-have category. Ask yourselves: 'Which feature serves as the absolute foundation of our product?' Find the items that are true prerequisites for the others, and rank your Must-haves from the most critical to the least.

2: Intermediate Topics (-)

Why is this useful for me?

Things you learn and experience in this session will help you to solve the following tasks:

Kano Model

3: TBA ()

Section section\advanced\cost_estimation_points.md not found.