WEB DEV

Appearance

Problem Breakdown: Decomposing Tasks 🧹🏗️ ​

In programming, if a function is 500 lines long, it is hard to read. You break it into 10 smaller functions. In Agile, if a Task is too big (like a "13" or "21"), we break it into smaller Tasks.

This process is called Refinement (or Grooming).

Key Activities in Refinement 💅 ​

Refinement isn't just about splitting tasks. It involves:

  1. Removing irrelevant items (The "We're never going to do this" items).
  2. Splitting large items (Epics) into smaller User Stories.
  3. Estimating items (Playing Planning Poker).
  4. Prioritizing items (Moving high-value items to the top).

When? Usually mid-sprint, preparing for the next sprint.

Definition of Ready (DoR) 🚦 ​

Before a task enters the sprint, it must be "Ready". Think of this like a checklist before running a script:

  • [ ] Clear Goal: Do we know what the output should be?
  • [ ] Estimated: Have we guessed the points?
  • [ ] Small Enough: Is it small enough to finish in a few days?
  • [ ] Dependencies Resolved: Do we have all the libraries/API keys we need?

Strategies to Break it Down (The SPIDR Method) 🛠️ ​

Just like refactoring code, we refactor tasks. We can use the SPIDR method:

  1. S - Spikes: Don't know how to do it? Create a research task first.
  2. P - Paths: Happy Path vs. Unhappy Path (Error Handling).
  3. I - Interfaces: Logic vs. UI.
  4. D - Data: Simple Data vs. Complex Data.
  5. R - Rules: Basic Rules vs. Complex Logic.

Example: "Build a Chess Game" ♟️ ​

Original Task: "Build a Chess Game" (21 Points - Too Big!)

Splitting using SPIDR:

  1. Interface Split:

    • Task A: Write the Board class in Python (Backend).
    • Task B: Draw the board using pygame (Frontend).

  2. Data Split:

    • Task C: Make it work with just Pawns.
    • Task D: Add Knights and Bishops.

  3. Path Split:

    • Task E: Valid moves only.
    • Task F: Prevent invalid moves (e.g., moving through other pieces).

Case Study: "The Python Bookstore" 📚🐍 ​

Let's apply everything we've learned to a full feature lifecycle.

1. The Vision 🔭 ​

We want to build an online bookstore specifically for Python books.

2. The Backlog (Initial) ​

  1. Show list of books.
  2. Search for books.
  3. Buy books (Too Big!).
  4. User profile.

3. Refinement (Breaking it down) 🔨 ​

The "Buy books" item is an Epic. Let's split it using SPIDR (Interface/Steps):

  • Story A: "Add book to cart".
  • Story B: "View cart".
  • Story C: "Checkout process".
  • Story D: "Payment integration".

4. Writing the User Story 📝 ​

Story A: Add book to cart.

"As a Shopper, I want to click an 'Add' button so that the book is saved for later purchase."

Acceptance Criteria:

  • Given I am on a book detail page.
  • When I click "Add to Cart".
  • Then the cart counter in the navbar increments by 1.
  • And the button text changes to "Added!".

5. Estimation (Planning Poker) 🃏 ​

  • Dev A: "3 points. Just a session update."
  • Dev B: "5 points. What about handling out-of-stock items?"
  • Discussion ensues...
  • Consensus: 5 points (Handling edge cases increased complexity).

6. The Sprint (Development) 🏃 ​

  • Daily Standups: Tracking progress.
  • Coding: Using Python/Django.
  • Testing: Using Pytest.

7. Review & Retro 🎁 ​

  • Review: Show the "Add to Cart" feature to the stakeholders.
  • Retro: "Our estimates were good, but we need to clarify the 'Out of Stock' behavior earlier next time."

Why do this? 🎓 ​

By breaking it down:

  1. You get working code faster (Story A works on Day 1!).
  2. You feel progress.
  3. If you run out of time, you still have a Calculator that adds and subtracts (better than nothing!).