Estimation & Planning: Guessing Complexity 📊🗓️

Question: How long will it take to write a specific Python script? Answer: It depends! Is it a "Hello World" (easy) or a "Machine Learning Model" (hard)?

In Agile, we don't guess Hours. We guess Complexity.

Story Points: The "Difficulty Score" 🔢

We give each task a score based on how hard it feels. Think of it like game levels or "Big O" complexity.

The C.U.E. Framework

To find the score, look at three things:

1. Complexity: Is the logic tricky? (Nested loops? Recursion?)
2. Uncertainty: Have you done this before? (New library? New API?)
3. Effort: Is it just a lot of typing? (Renaming 100 files?)

The Fibonacci Scale 🐚

We use these numbers: 1, 2, 3, 5, 8, 13... Why? Because as tasks get bigger, they get harder to guess perfectly.

• 1 vs 2: Easy to tell apart.
• 13 vs 15: Hard to tell apart. So we just say "It's a 13".

Agile Estimation Reference Table 📏

It helps to have a baseline. Here are examples for a beginner Python team:

Points	Complexity	Python Example	Real Life Analogy
1	Tiny	Fixing a typo in a print() statement.	Blinking your eyes.
2	Small	Writing a simple function def add(a, b):.	Tying your shoelaces.
3	Medium	Writing a script to read a CSV file.	Cooking a simple omelet.
5	Large	Building a Tic-Tac-Toe game logic.	Cooking a full dinner for 4 people.
8	Huge	Building a Web Scraper that saves to a Database.	Painting a whole room.
13	Too Big	"Build Instagram". (Break this down!)	Building a house. (Call an architect!)

Rule of Thumb

If a story is estimated at 13 or higher, it should be split into smaller stories.

Planning Poker: A Real-World Scenario 🃏

Planning Poker helps avoid "Anchoring Bias" (where the senior dev speaks first, and everyone copies them).

Scenario: The team is estimating "As a User, I want to upload a CSV and visualize it."

Participants:

• Alice (Senior Python Dev)
• Bob (Junior Dev)
• Charlie (Frontend Dev)

The Process:

1. Scrum Master: "Story is: Upload CSV and show a bar chart. 3... 2... 1... Reveal!"
2. Cards Revealed:
   • Alice: 3
   • Bob: 8
   • Charlie: 5

The Discussion:

• Scrum Master: "Bob, you voted 8. Why?"
• Bob: "I've never used the visualization library before. I think parsing the CSV might fail if the format is bad."
• Scrum Master: "Alice, you voted 3. Why?"
• Alice: "We already have a CsvParser class from the last sprint. We just need to plug it into matplotlib. It's pretty standard."
• Bob: "Oh, I didn't know we had a parser ready! That makes it way easier."

Team re-votes.Cards Revealed: 3, 5, 5. Consensus: Team agrees on 5 (Safe bet).

Alternative Techniques 🛠️

T-Shirt Sizing 👕

Used for early planning when you don't need numbers.

• XS: Fix typo.
• S: Simple script.
• M: Standard feature.
• L: Major feature (needs splitting).
• XL: Huge project (needs breakdown).

The Cone of Uncertainty 📉

At the start of a project, your estimates will be wrong (4x off). As you learn more, you get more accurate. Lesson: Don't treat early guesses as promises.

Velocity & Capacity 🚀

• Velocity: The average points you completed in past sprints. (Your CPU clock speed).
• Capacity: How much time you actually have next sprint. (Available RAM).

Capacity Formula: Total Availability = (Number of Devs) × (Days in Sprint) × (Effective Hours per Day)

Example:

• 4 Developers.
• 10 Day Sprint.
• Focus Factor: 6 hours/day (No one codes 8 hours. Meetings happen).

Capacity = 4 × 10 × 6 = 240 Hours.

Note: Velocity tells you how many points you can do. Capacity tells you how many hours you have. They are different but related metrics.

Common Traps ⚠️

1. The "Just One Line" Trap

"It's just one line of code! It's a 1." Reality: It takes 1 minute to write, but 30 minutes to test and verify. Nothing is 0 points.

2. The "Manager Pressure"

Manager: "Can you do this 8-point task in 2 days?" Reality: Changing the estimate doesn't make the coding go faster. It just makes you rush and write bugs.

Task: Guess the Points 🧮

Task 1

Scenario: You need to write a Python script that asks the user for their age and prints "You are an adult" if age > 18.

Factors:

• Complexity: Very Low (One if statement).
• Uncertainty: Low (Standard input).
• Effort: Low (5 lines of code).

What point value is this?

Answer

Answer: This is a 1 or 2. It is very simple and standard.

Task 2: The "Refactor"

Scenario: You have a legacy Python script that is 2,000 lines long, no tests, and no documentation. It works, but it's slow. The Product Owner wants it "optimized".

Factors:

• Complexity: High (Spaghetti code).
• Uncertainty: Extremely High (If you touch it, it might break).
• Effort: Unknown.

Question: What estimate would you give?

Answer

Answer: This is likely a 13, 21, or Infinity. It's too big and risky. Better Approach: Do not estimate it yet. Create a Spike (Research Task) to analyze the code and write tests first.