> ## Documentation Index
> Fetch the complete documentation index at: https://docs.charle.agency/llms.txt
> Use this file to discover all available pages before exploring further.

# Scoping

> How to scope work effectively for accurate estimates

Scoping is the process of defining and breaking down work before estimation. Good scoping clarifies what's included, identifies risks, and ensures everyone has the same understanding of the deliverable.

**The principle:** You can't estimate what you don't understand.

## Why Scoping Matters

Clear scoping is the foundation of accurate estimation:

<CardGroup cols={2}>
  <Card title="Reduces Estimation Errors" icon="bullseye">
    Well-scoped work is easier to size accurately because complexity is visible upfront
  </Card>

  <Card title="Prevents Scope Creep" icon="shield">
    Explicit boundaries make it clear when a request goes beyond the original agreement
  </Card>

  <Card title="Improves Scheduling" icon="calendar">
    Broken-down work is easier to assign, track, and complete incrementally
  </Card>

  <Card title="Builds Client Trust" icon="handshake">
    Clear scope documents show professionalism and set realistic expectations
  </Card>
</CardGroup>

## The Scoping Process

Follow these steps to scope work effectively:

<Steps>
  <Step title="Understand the Requirement">
    **Goal:** Grasp what the client actually needs (not just what they said)

    **Questions to ask:**

    * What problem are we solving?
    * What's the desired outcome or user experience?
    * Who is the user or audience?
    * Are there examples or references we can look at?

    **Red flags:**

    * Vague language ("make it better," "improve performance")
    * Missing context (who, why, when)
    * Assumptions without validation
  </Step>

  <Step title="Define What's Included">
    **Goal:** Be explicit about deliverables and boundaries

    **Specify:**

    * Exact deliverables (e.g., "3 page designs," "API endpoint for user login")
    * Platforms or devices (desktop, mobile, tablet?)
    * Environments (development, staging, production?)
    * Documentation or handoff materials

    **Example:**

    * ✅ "Homepage hero section: desktop and mobile designs with 2 feedback rounds"
    * ❌ "Homepage design"
  </Step>

  <Step title="Define What's Excluded">
    **Goal:** Prevent scope creep by stating explicit boundaries

    **Common exclusions:**

    * Additional pages or features not mentioned
    * Content creation (copy, images, etc.)
    * Third-party integrations beyond specified ones
    * Performance optimization (unless explicitly included)

    **Example:**

    * "This quote includes the contact form only. Email template design is not included and can be quoted separately if needed."
  </Step>

  <Step title="Identify Dependencies and Risks">
    **Goal:** Surface blockers and complexity factors

    **Dependencies to note:**

    * Requires API from another task
    * Needs client to provide content or assets
    * Depends on third-party service or approval
    * Must wait for design/development from another requirement

    **Risks to consider:**

    * Unfamiliar technology or APIs
    * Legacy codebase or technical debt
    * Unclear or incomplete requirements
    * Tight deadline or hard launch date
  </Step>

  <Step title="Break Into Smaller Pieces">
    **Goal:** Split large work into estimable, deliverable chunks

    **Break by:**

    * **Phase:** Design → Development → Testing
    * **Component:** Header → Nav → Footer
    * **Feature:** User registration → Login → Password reset
    * **Platform:** Desktop → Mobile → Tablet

    **Rule of thumb:**

    * If it feels like XXL (40-120 hours), try to split it
    * Aim for pieces that are M (3-6 hrs) to L (8-16 hrs) when possible
    * Each piece should be independently deliverable and testable
  </Step>

  <Step title="Document the Scope">
    **Goal:** Create a written record that everyone agrees on

    **Include in the scope description:**

    * Summary of the work
    * What's included (bulleted list)
    * What's explicitly excluded
    * Assumptions and dependencies
    * Deliverables and acceptance criteria

    This becomes the scope description field in the quote requirement block.
  </Step>
</Steps>

## Scoping by Work Type

### Design Scoping

Design work needs clarity on deliverables, fidelity, and feedback rounds:

<AccordionGroup>
  <Accordion title="What to Include" icon="check">
    * Number of screens or pages
    * Fidelity level (wireframes, mockups, high-fidelity)
    * Responsive breakpoints (desktop, tablet, mobile)
    * Number of feedback rounds included
    * Assets provided (icons, images, or sourced by designer?)

    **Example scope:**
    "High-fidelity mockups for Product Listing page (desktop and mobile). Includes 2 feedback rounds. Client to provide product images."
  </Accordion>

  <Accordion title="What to Clarify" icon="question">
    * Is branding already defined, or is this part of the work?
    * Are there existing design systems or patterns to follow?
    * What format do deliverables need to be in (Figma, Sketch, PNG, etc.)?
    * Are animations or interactions included?
  </Accordion>

  <Accordion title="Common Pitfalls" icon="triangle-exclamation">
    * Not specifying number of feedback rounds (leads to endless revisions)
    * Unclear on responsive design expectations
    * Assuming client will provide assets when they expect you to source them
  </Accordion>
</AccordionGroup>

### Development Scoping

Development work needs technical clarity and boundaries:

<AccordionGroup>
  <Accordion title="What to Include" icon="check">
    * Functional requirements (what the feature does)
    * Technical approach (API endpoints, database changes, etc.)
    * Browser/device support
    * Testing scope (unit tests, integration tests, manual QA)
    * Deployment (dev, staging, production)

    **Example scope:**
    "Build product filter component with category and price range filters. Includes API endpoint, frontend UI (React), and unit tests. Supports Chrome, Safari, Firefox (latest versions)."
  </Accordion>

  <Accordion title="What to Clarify" icon="question">
    * Is the design finalized, or are we building based on wireframes?
    * Are there existing components or patterns to follow?
    * What's the acceptable loading time or performance threshold?
    * Does this need to work offline or with slow connections?
  </Accordion>

  <Accordion title="Common Pitfalls" icon="triangle-exclamation">
    * Not accounting for API changes or backend work
    * Assuming existing code is reusable when it's not
    * Underestimating complexity of third-party integrations
    * Forgetting about edge cases and error handling
  </Accordion>
</AccordionGroup>

## Scoping Complex Requirements

Large or complex requirements need structured breakdown:

### Example: E-commerce Checkout Flow

Instead of one massive requirement ("Build checkout"), break it down:

<Tabs>
  <Tab title="❌ Too Vague">
    **Requirement:** "Build checkout flow"

    **Problems:**

    * What's included? Cart, payment, shipping, order confirmation?
    * What payment methods?
    * Guest checkout or login required?
    * Shipping address, billing address, or both?

    **Result:** Impossible to estimate accurately. High risk of scope creep and overruns.
  </Tab>

  <Tab title="✅ Well-Scoped">
    **Broken into clear requirements:**

    1. **Cart Review Page**
       * Display cart items with quantities
       * Edit quantities, remove items
       * Apply promo codes
       * Show subtotal, taxes, total
       * Size: M (3-6 hours)
    2. **Shipping Information**
       * Form for shipping address
       * Address validation
       * Shipping method selection
       * Size: M (3-6 hours)
    3. **Payment Integration**
       * Stripe payment form
       * Card validation
       * 3D Secure support
       * Error handling
       * Size: L (8-16 hours)
    4. **Order Confirmation**
       * Success page with order details
       * Send confirmation email (using existing template)
       * Redirect to order history
       * Size: S (1-2 hours)

    **Total:** Well-defined scope with clear deliverables, easier to schedule and track
  </Tab>
</Tabs>

## Scoping in Quotes

When creating quotes in CharleOS, each requirement block includes a scope description:

### Anatomy of a Good Scope Description

```text theme={null}
**Summary:**
Build product filtering system for shop page

**Included:**
- Filter by category (dropdown, multi-select)
- Filter by price range (slider)
- Real-time results update (no page reload)
- "Clear filters" button
- Mobile-responsive UI
- Unit tests for filter logic

**Excluded:**
- Advanced filters (brand, rating, etc.) - can be quoted separately
- Filter persistence across sessions
- Analytics tracking

**Assumptions:**
- Product data is already in database
- Existing API supports filter parameters
- Design mockups provided by client

**Dependencies:**
- Requires Product API to support category and price filtering (separate task)

**Deliverables:**
- Filter UI component (React)
- Integration with product listing page
- QA-tested and deployed to staging

**Acceptance Criteria:**
- User can filter by category and price
- Results update without page reload
- Mobile layout matches design
- No console errors, passes QA
```

### Tips for Writing Scope Descriptions

<AccordionGroup>
  <Accordion title="Be Specific, Not Exhaustive" icon="bullseye">
    You don't need to list every line of code, but be clear on key deliverables and boundaries.

    **Good:** "Contact form with name, email, message fields. Includes validation and email sending."

    **Too vague:** "Build contact form."

    **Too detailed:** "Contact form with: firstName (string, required, max 50 chars), lastName (string, required, max 50 chars)..." \[continues for 20 lines]
  </Accordion>

  <Accordion title="Use Bullet Points" icon="list">
    Bulleted lists are easier to scan than paragraphs. Break up text into digestible chunks.
  </Accordion>

  <Accordion title="State Assumptions Explicitly" icon="lightbulb">
    If your estimate depends on something being true, say so:

    * "Assumes API docs are accurate"
    * "Assumes client provides copy and images"
    * "Assumes existing authentication system is functional"
  </Accordion>

  <Accordion title="Highlight Risks" icon="triangle-exclamation">
    If there are known risks or unknowns, call them out:

    * "Third-party API documentation is sparse—may require extra discovery time"
    * "Legacy codebase lacks tests—QA time may increase"
  </Accordion>
</AccordionGroup>

## Handling Ambiguous Requests

Sometimes clients provide vague or incomplete requirements. Here's how to handle them:

### Strategy 1: Ask Clarifying Questions

<Tabs>
  <Tab title="Client Says">
    "We need to improve the website performance."
  </Tab>

  <Tab title="You Ask">
    * Which pages are slow? (specific URLs or sections)
    * What's the current load time vs desired load time?
    * Are there specific metrics we're targeting? (Lighthouse score, LCP, etc.)
    * Are there known issues (large images, slow queries)?
    * What's the budget for this work? (helps scope the effort)
  </Tab>

  <Tab title="Outcome">
    **Revised requirement:**
    "Optimize homepage load time from 4.5s to under 2s. Focus on image optimization, lazy loading, and reducing JS bundle size. Target: Lighthouse performance score greater than 90."

    Now you can estimate accurately.
  </Tab>
</Tabs>

### Strategy 2: Offer a Discovery Phase

When unknowns are high, quote a small discovery task first:

<Note>
  **Discovery Task (S or M):** Investigate the requirement, document findings, and provide a detailed estimate for the implementation.

  **Benefits:**

  * Low-risk investment for the client
  * You get clarity before committing to a large estimate
  * Uncovers hidden complexity early
</Note>

**Example:**

* Client: "Integrate with \[third-party API]"
* You: "Let's start with a discovery task (S, 1-2 hours) to review their API docs, test authentication, and identify integration points. Then we'll provide a detailed quote for the implementation."

### Strategy 3: Provide Multiple Options

Offer tiered scopes with different levels of effort:

**Example: "Website Redesign"**

| Option       | Scope                                                        | Estimate           |
| ------------ | ------------------------------------------------------------ | ------------------ |
| **Basic**    | Homepage only, existing branding, 2 feedback rounds          | L (8-16 hours)     |
| **Standard** | Homepage + 3 key pages, existing branding, 3 feedback rounds | XL (24-40 hours)   |
| **Premium**  | Full site (10 pages), updated branding, unlimited feedback   | XXL (40-120 hours) |

Let the client choose based on budget and priorities.

## Scoping Red Flags

Watch out for these warning signs that scope is unclear:

<AccordionGroup>
  <Accordion title="Vague Language" icon="comment">
    **Red flags:**

    * "Make it look more modern"
    * "Improve the UX"
    * "Optimize the site"
    * "Add some features"

    **Fix:** Ask specific questions to clarify exactly what "modern," "better," or "optimized" means.
  </Accordion>

  <Accordion title="Open-Ended Scope" icon="infinity">
    **Red flags:**

    * "Design the homepage (and other pages as needed)"
    * "Build the feature (with integrations to be determined)"
    * "Unlimited revisions"

    **Fix:** Define clear boundaries. How many pages? Which integrations? How many feedback rounds?
  </Accordion>

  <Accordion title="Missing Acceptance Criteria" icon="question">
    **Red flags:**

    * No definition of "done"
    * No way to validate the work is complete
    * "We'll know it when we see it"

    **Fix:** Define explicit acceptance criteria (e.g., "Homepage loads in less than 2s," "User can filter by 5+ categories").
  </Accordion>

  <Accordion title="Unrealistic Expectations" icon="triangle-exclamation">
    **Red flags:**

    * "Build a Shopify competitor in 40 hours"
    * "Redesign the entire site by next week"
    * "Make it perfect with no bugs"

    **Fix:** Educate the client on realistic scope, timelines, and trade-offs. Break large work into phases.
  </Accordion>
</AccordionGroup>

## Scoping Best Practices

<AccordionGroup>
  <Accordion title="Start with the End in Mind" icon="flag-checkered">
    Define the desired outcome first, then work backward to scope the steps needed to get there.

    **Question:** What does success look like when this is done?
  </Accordion>

  <Accordion title="Use Examples and References" icon="image">
    Visual examples clarify ambiguity:

    * "Like the filter on Amazon"
    * "Similar to the hero section on \[example site]"
    * "Mockup attached showing the layout"
  </Accordion>

  <Accordion title="Involve the Team" icon="users">
    Don't scope in isolation. Get input from:

    * Designers (if dev work relies on design)
    * Developers (if design needs to be technically feasible)
    * PMs (for client context and history)
  </Accordion>

  <Accordion title="Document Assumptions" icon="file-text">
    Write down what you're assuming to be true:

    * "Assumes client provides content"
    * "Assumes existing API supports this use case"
    * "Assumes no major browser compatibility issues"

    If assumptions change, scope (and estimate) may need to change too.
  </Accordion>

  <Accordion title="Review Similar Past Work" icon="clock-rotate-left">
    Look at past quotes and tasks with similar scope:

    * How was the scope defined?
    * Did scope creep occur?
    * What was missed in the original scoping?

    Learn from history to improve future scoping.
  </Accordion>
</AccordionGroup>

## When Scope Changes

Even well-scoped work can encounter scope changes during delivery. Here's how to handle it:

### Recognize Scope Creep

**Signs that scope is expanding:**

* Client requests features not in the original scope
* "While you're at it, can you also..." requests
* Requirements that seemed simple turn out to be complex
* New stakeholders introduce new requirements

### How to Address It

<Steps>
  <Step title="Acknowledge the Change">
    "This request is outside the original scope of \[requirement name], which included \[original scope summary]."
  </Step>

  <Step title="Assess the Impact">
    * How much additional time is required?
    * Does it block current work?
    * Is it a small add-on or a significant change?
  </Step>

  <Step title="Propose a Solution">
    **Option 1:** "We can add this as a separate requirement (estimated M, 3-6 hours)."

    **Option 2:** "We can include this, but it will increase the estimate from M to L."

    **Option 3:** "We can do this in a future phase to keep the current work on track."
  </Step>

  <Step title="Get Agreement">
    Don't proceed with expanded scope without client approval and updated estimates.
  </Step>
</Steps>

<Warning>
  Saying "yes" to scope changes without adjusting the estimate creates overruns and erodes profitability. Protect the scope.
</Warning>

## Related Concepts

<CardGroup cols={2}>
  <Card title="T-shirt Sizing" icon="ruler" href="/concepts/estimation/t-shirt-sizing">
    How to apply t-shirt sizes once the work is scoped
  </Card>

  <Card title="Creating Quotes" icon="file-text" href="/user-guide/quotes/creating-quotes">
    Step-by-step guide to creating quotes with scoped requirements
  </Card>

  <Card title="Billing Model" icon="calculator" href="/concepts/billing/billing-model">
    How scoped work feeds into billing calculations
  </Card>

  <Card title="Requirement Blocks" icon="cube" href="/user-guide/quotes/requirement-blocks">
    How to structure requirements in quotes
  </Card>
</CardGroup>