Skip to main content
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:

Reduces Estimation Errors

Well-scoped work is easier to size accurately because complexity is visible upfront

Prevents Scope Creep

Explicit boundaries make it clear when a request goes beyond the original agreement

Improves Scheduling

Broken-down work is easier to assign, track, and complete incrementally

Builds Client Trust

Clear scope documents show professionalism and set realistic expectations

​
The Scoping Process

Follow these steps to scope work effectively:
1

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
2

Define What's Included

Goal: Be explicit about deliverables and boundariesSpecify:
  • 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”
3

Define What's Excluded

Goal: Prevent scope creep by stating explicit boundariesCommon 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.”
4

Identify Dependencies and Risks

Goal: Surface blockers and complexity factorsDependencies 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
5

Break Into Smaller Pieces

Goal: Split large work into estimable, deliverable chunksBreak 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
6

Document the Scope

Goal: Create a written record that everyone agrees onInclude 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.

​
Scoping by Work Type

​
Design Scoping

Design work needs clarity on deliverables, fidelity, and feedback rounds:
  • 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.”
  • 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?
  • 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

​
Development Scoping

Development work needs technical clarity and boundaries:
  • 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).”
  • 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?
  • 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

​
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:
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.

​
Scoping in Quotes

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

​
Anatomy of a Good Scope Description

​
Tips for Writing Scope Descriptions

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]
Bulleted lists are easier to scan than paragraphs. Break up text into digestible chunks.
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”
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”

​
Handling Ambiguous Requests

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

​
Strategy 1: Ask Clarifying Questions

“We need to improve the website performance.”

​
Strategy 2: Offer a Discovery Phase

When unknowns are high, quote a small discovery task first:
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
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” Let the client choose based on budget and priorities.

​
Scoping Red Flags

Watch out for these warning signs that scope is unclear:
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.
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?
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”).
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.

​
Scoping Best Practices

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?
Visual examples clarify ambiguity:
  • “Like the filter on Amazon”
  • “Similar to the hero section on [example site]”
  • “Mockup attached showing the layout”
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)
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.
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.

​
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

1

Acknowledge the Change

“This request is outside the original scope of [requirement name], which included [original scope summary].”
2

Assess the Impact

  • How much additional time is required?
  • Does it block current work?
  • Is it a small add-on or a significant change?
3

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.”
4

Get Agreement

Don’t proceed with expanded scope without client approval and updated estimates.
Saying “yes” to scope changes without adjusting the estimate creates overruns and erodes profitability. Protect the scope.

T-shirt Sizing

How to apply t-shirt sizes once the work is scoped

Creating Quotes

Step-by-step guide to creating quotes with scoped requirements

Billing Model

How scoped work feeds into billing calculations

Requirement Blocks

How to structure requirements in quotes