Mapping Shape Up Scopes Instead of Tasks During the Building Phase
This skill teaches you to organize building-phase work into scopes, which are integrated slices of design, front-end, and back-end work that can be completed and verified independently, replacing traditional task lists with a structure that reveals real progress.
Start by identifying the natural boundaries in the shaped work, then group related front-end and back-end tasks into integrated slices called scopes. Each scope should be independently completable and demoable within a few days. Name each scope with a short phrase that describes the user-facing behavior it delivers, then track progress per scope using hill charts rather than checking off individual tasks.
Outcome: Your team replaces a flat task list with a living scope map of 3-8 integrated slices, each independently completable and trackable on a hill chart, giving you honest visibility into progress and enabling scope hammering when time gets tight.
Prerequisites
- Familiarity with the Shape Up method and its fixed-time, variable-scope philosophy
- A shaped pitch that has been bet on and assigned to a team for a build cycle
- Understanding of hill charts for tracking progress (see tracking-progress-with-hill-charts)
- Basic understanding of front-end and back-end concerns in your product's architecture
Overview
When a shaped project gets bet on and handed to a build team, the first instinct is usually to break it into tasks. Write API endpoint. Build form component. Add database migration. Style the confirmation page. This produces a flat list that looks productive but hides the real question: are we actually finishing things, or just staying busy? Shape up scopes solve this by organizing work into integrated, vertically sliced pieces of functionality. Each scope bundles the design, front-end, and back-end work needed to deliver one meaningful piece of the project. A scope is not a feature spec, not a user story, and not a ticket. It is a named slice of the project that a team member can pick up, work through from unknowns to completion, and demo to the rest of the team within a few days.
The scope map is the primary artifact this skill produces. It is a short list of 3-8 named scopes, each described in a phrase that captures the user-facing behavior it delivers. "Upload and preview" is a scope. "Send notification on approval" is a scope. "Migrate existing records" is a scope. The scope map replaces the backlog of tasks with a structure that makes real progress visible. When you track each scope on a hill chart, you can see at a glance which slices are still being figured out, which are being executed, and which are done. You can also see which scopes are dragging, which lets you decide whether to cut them, simplify them, or reassign them before you run out of cycle time.
Scope mapping does not happen once at the start of the cycle. The initial scope map is a draft. In Shape Up, teams discover the real scopes in the first few days of building as they dig into the shaped work and hit the actual edges of the problem. Scopes get renamed, split, merged, and occasionally cut as the team learns what the work actually requires. The scope map is a living document that reflects the team's evolving understanding. This is fundamentally different from a sprint backlog, which is locked at planning and treated as a commitment. Scopes are a thinking tool, not a contract.
The concrete output of this skill is a scope map with 3-8 named scopes, each one independently completable and demoable, ready to be placed on a hill chart. A well-mapped project gives the team autonomy to pick up scopes in any order, makes progress visible without status meetings, and provides the structure needed for scope hammering when time pressure arrives late in the cycle.
How It Works
The core insight behind scopes is that real progress on a product happens when you finish things, not when you start things. A flat task list creates the illusion of progress because you can check off items, but those items might be scattered across different parts of the project. You might have completed 60% of the tasks while having zero pieces of the project that are shippable. Scopes flip this by making the unit of progress a vertically integrated slice. When a scope is done, something works end to end.
Scopes work because they align with how product work actually unfolds. In practice, the design, front-end, and back-end work for a given piece of functionality are deeply entangled. The API shape depends on what the UI needs. The UI layout depends on what data is available. The database schema depends on how users will interact with the feature. Separating these into independent tasks creates artificial handoffs and coordination overhead. Grouping them into a scope lets one person (or a pair) own the entire slice and make tradeoffs locally without waiting for decisions from other parts of the team.
The naming convention matters more than it seems. A good scope name describes user-facing behavior, not implementation. "Upload and preview" tells you what the user will be able to do when the scope is done. "Build S3 integration" tells you about a technology choice but not whether the user can do anything new yet. When scopes are named after user-facing behavior, you can evaluate whether each scope is essential to the shaped solution or whether it could be cut or simplified under time pressure. This is the foundation of scope hammering, which is the Shape Up technique for staying within the fixed time box by reducing scope rather than extending deadlines.
The right number of scopes for most projects is between 3 and 8. Fewer than 3 means your scopes are too large, each scope will take more than a week, and you will not have enough resolution on your hill chart to see progress. More than 8 means your scopes are too granular, you are essentially back to task-level tracking, and the overhead of managing scope boundaries exceeds the benefit. The sweet spot is scopes that take 1-5 days to complete, which gives you enough granularity to see progress without drowning in coordination.
Scopes emerge from the shaped work, not from decomposition of a feature spec. The shaped pitch defines the problem, the solution approach, and the boundaries (rabbit holes to avoid, nice-to-haves that are explicitly out). When the team starts building, they discover the natural joints in the work. These joints are where one piece of the solution can be completed independently of another. Sometimes the joints are obvious from the pitch. Sometimes they only become clear after a day or two of exploration. This is why scope mapping is iterative: you draft an initial map, then refine it as the team learns.
The relationship between scopes and hill charts is symbiotic. Scopes without hill charts are just a different kind of list. Hill charts without well-defined scopes produce meaningless dots. Each scope sits on the hill as a single dot, moving from "figuring it out" (uphill) to "making it happen" (downhill). When you see a scope stuck on the uphill side for more than a few days, that is a signal to investigate. Maybe the scope is too big and needs splitting. Maybe there is an unresolved unknown that needs a spike. Maybe the team needs help. This diagnostic power is what makes scopes the right unit of tracking.
Step-by-Step
Step 1: Re-read the shaped pitch with the whole team
Before mapping any scopes, the entire build team (designer and programmer, or small team of two to three people) should read through the shaped pitch together. Pay attention to the problem statement, the proposed solution, the explicit boundaries (what is out of scope), and any rabbit holes the shaper flagged. Discuss what the pitch means in terms of the actual product. Identify the parts of the solution that feel clear versus the parts that feel uncertain.
This shared understanding is the foundation for scope discovery. Do not start coding or designing yet. The goal of this step is alignment on what done looks like and where the unknowns are.
Tip: Highlight the rabbit holes and boundaries from the pitch on a shared document or whiteboard. These boundaries will directly inform which scopes to cut or simplify later if time gets tight.
Step 2: Identify the natural joints in the work
Walk through the shaped solution and look for places where one piece of functionality can be completed independently of another. Ask: if we finished this part but nothing else, could we demo it? Could a user do something new? These are the natural joints.
For example, in a project to build a reporting dashboard, the ability to filter by date range might be independent of the ability to export to CSV. Both are part of the solution, but they can be built and verified separately. Sketch these joints on a whiteboard or in a shared doc. Do not worry about perfect boundaries yet.
You are looking for the rough shape of 3-8 slices.
Tip: A useful heuristic: if you can describe the slice with a verb phrase from the user's perspective ('upload a file,' 'see weekly totals,' 'invite a teammate'), it is probably a good scope boundary.
Step 3: Group related front-end and back-end work into each scope
For each joint you identified, list the work involved. This includes the database changes, API endpoints, UI components, validation logic, and any design decisions needed. Group these into the scope they belong to. The critical rule is that each scope must be vertically integrated: it contains everything needed to make that slice work end to end.
If a scope requires an API endpoint but the UI work is in a different scope, you have split along the wrong axis. Horizontal slices (all the API work, then all the UI work) destroy the benefit of scopes because nothing is completable until everything is done. Vertical slices let you finish and demo one piece at a time.
Tip: If you find that two scopes share a dependency (like a shared database table or component), assign the dependency to whichever scope will be started first, or create a tiny scope just for the shared infrastructure if it takes more than a few hours.
Step 4: Name each scope with user-facing behavior
Give each scope a short, descriptive name that captures what the user will be able to do when the scope is complete. Use plain language, not technical jargon. 'Filter by date range' is better than 'implement DateRangePicker component.' 'Send approval email' is better than 'integrate SendGrid.' The name should make it obvious to anyone on the team, including non-technical stakeholders, what finishing this scope means. Good names also make scope cutting easier later: when you read 'batch import from CSV,' you can quickly evaluate whether that capability is essential to the core value of the project or a nice-to-have that could be cut.
Tip: Test your scope name by asking: if I told a customer we shipped this scope, would they understand what they can now do? If the answer is no, the name is too technical.
Step 5: Validate scope size and independence
Review each scope and estimate whether it can be completed in 1-5 days. If a scope feels like it will take more than a week, it is too big and should be split. If a scope feels like it will take less than half a day, it is too small and should be merged with a related scope or treated as a task within a scope. Also check independence: can this scope be started without waiting for another scope to finish?
Some sequencing is natural (you might need the data model before you can build the reporting view), but most scopes in a well-mapped project can be worked on in parallel or in any order. If your scopes have strict sequential dependencies, reconsider whether you have drawn the boundaries in the right places.
Tip: Count your scopes. If you have more than 8, you are probably tracking at the task level. If you have fewer than 3, you probably cannot see progress until late in the cycle. Aim for 4-6 scopes on a typical 6-week project.
Step 6: Place scopes on the hill chart
With your scope map drafted, place each scope as a dot on a hill chart. Position each dot based on your current understanding: scopes with significant unknowns go on the left (uphill, figuring it out), scopes where the approach is clear go further right (downhill, making it happen). At the start of a cycle, most scopes will be on the left side. This is expected and healthy.
The hill chart gives you a visual dashboard of progress. Update it at least twice per week. Moving a dot is a judgment call by the person working on the scope, not a mechanical calculation.
Tip: Do not wait until scopes are perfectly defined to put them on the hill. The act of placing a scope on the hill forces a conversation about how well understood it is, which is the whole point.
Step 7: Refine scopes during the first few days of building
Expect your initial scope map to change. In the first two to three days of actual building, the team will discover things the shaped pitch did not anticipate. A scope that seemed simple might turn out to have a hidden complexity that warrants splitting it into two. Two scopes that seemed separate might share so much work that merging them makes more sense.
A new scope might emerge for work that was not visible in the pitch. Treat the scope map as a living document. Update it, rename scopes, add or remove scopes as needed. The scope map is a thinking tool that reflects your current understanding, not a plan you committed to.
Tip: If a scope keeps getting renamed or redefined after the first week, that is a signal the team has not resolved a fundamental unknown. Pause and spike on the unknown before continuing.
Step 8: Use scopes for scope hammering when time gets tight
As the cycle progresses, refer to your scope map to make cutting decisions. If you are in week 4 of a 6-week cycle and a scope is still stuck on the uphill side of the hill, you have a choice: simplify the scope (reduce what it delivers), cut the scope entirely (if it is a nice-to-have), or reassign resources from a completed scope. This is scope hammering, and it only works when your project is organized into independent scopes. With a flat task list, cutting is painful because tasks are entangled.
With scopes, you can drop an entire slice without affecting the rest of the project. The scope names (which describe user-facing behavior) make it clear what you are trading away.
Tip: Mark scopes as 'must-have' or 'nice-to-have' early in the cycle so that cutting decisions are not emotional debates when time pressure hits.
Examples
Example: SaaS onboarding flow for a 6-week cycle (small team of 2)
A designer and a programmer are building a new user onboarding flow for a B2B SaaS product. The shaped pitch describes a 4-step wizard that collects company info, invites team members, configures initial settings, and shows a getting-started dashboard. The team is two people working a 6-week cycle.
After reading the pitch together, the team identifies four natural joints matching the wizard steps plus one additional scope for the overall wizard navigation and progress bar. They create five scopes: 'Set up company profile' (form, validation, API, database), 'Invite teammates' (email input, invitation sending, acceptance flow), 'Configure workspace settings' (preferences form, defaults logic, persistence), 'Getting-started dashboard' (checklist UI, completion tracking, first-run content), and 'Wizard navigation' (step indicator, back/forward, skip logic, progress persistence). Each scope is independently demoable. They mark 'Set up company profile' and 'Wizard navigation' as must-haves, 'Invite teammates' and 'Configure workspace settings' as must-haves with room to simplify, and 'Getting-started dashboard' as nice-to-have.
By week 3, the dashboard scope is still uphill and the team decides to simplify it to a static checklist page rather than a dynamic dashboard, cutting the scope down to a 2-day effort. They ship all five scopes on time.
Example: E-commerce returns feature for a 6-week cycle (team of 3)
A team of one designer and two programmers is building a self-service returns feature for an e-commerce platform. The shaped pitch covers return initiation, label generation, refund processing, and a returns dashboard for customer service agents. The team has 6 weeks and the appetite is firm.
The team drafts an initial scope map with six scopes: 'Start a return' (order lookup, item selection, reason capture), 'Generate return label' (carrier API integration, PDF generation, email delivery), 'Track return status' (status model, customer-facing tracking page, status update webhook), 'Process refund' (refund calculation, payment provider integration, confirmation), 'CS agent dashboard' (list view, filters, detail view, manual override), and 'Return policy enforcement' (eligibility rules, time window checks, category exclusions). In the first two days of building, the team discovers that 'Generate return label' and 'Track return status' are more entangled than expected because the carrier API handles both. ' They also discover that 'Return policy enforcement' touches every other scope and is not independently completable. They dissolve it, distributing the eligibility checks into the 'Start a return' scope where they naturally belong.
The revised map has four scopes. By week 5, the CS agent dashboard is lagging. They simplify it to a basic list view without filters, cutting roughly 3 days of work. They ship the core returns flow on time.
Example: Internal reporting tool for a 3-week cycle (solo developer)
A single developer is building an internal weekly metrics report for the operations team. The shaped pitch describes pulling data from three sources, computing key metrics, and displaying them in a simple dashboard with email delivery. The cycle is 3 weeks with a fixed appetite.
Working alone, the developer maps three scopes: 'Aggregate data sources' (connect to the three APIs, normalize data into a common format, store weekly snapshots), 'Compute and display metrics' (calculation logic for 5 key metrics, dashboard page with charts, date range selector), and 'Email weekly report' (scheduled job, HTML email template, recipient management). Each scope can be built and verified independently. The developer starts with 'Aggregate data sources' because the other scopes depend on having data available. By the end of week 1, the first scope is done and the second scope is halfway down the hill.
In week 2, the developer realizes the email scope is more complex than expected because of HTML rendering edge cases across email clients. They simplify by sending a plain-text email with a link to the dashboard instead of an inline HTML report. This cuts the scope from 3 days to 1 day. All three scopes ship within the 3-week cycle.
Example: Mobile app feature for a 6-week cycle (cross-functional team of 4)
A team of two mobile developers, one backend developer, and one designer is adding a social sharing feature to a consumer fitness app. The shaped pitch covers share cards, social platform integrations, in-app activity feeds, and friend challenges. The team is large by Shape Up standards and coordination is a concern.
The team maps seven scopes: 'Design share card' (card layout, stat selection, branding), 'Generate share image' (server-side image rendering, caching, CDN delivery), 'Share to Instagram Stories' (Stories API integration, deep link handling), 'Share to other platforms' (generic share sheet, Twitter/Facebook metadata), 'Activity feed' (feed data model, feed UI, pagination), 'Friend challenges' (challenge creation, invitation, progress tracking, completion), and 'Push notifications for social' (notification triggers, templates, delivery). They immediately mark 'Friend challenges' and 'Push notifications for social' as nice-to-haves. ' Scopes are picked up by pairs rather than individuals, which keeps coordination manageable. By week 4, the core sharing scopes are done.
The team has time to start 'Activity feed' but decides to cut 'Friend challenges' entirely, deferring it to a future cycle. They ship five of seven scopes, and the product is shippable and valuable without the cut scopes.
Best Practices
Name scopes after user-facing behavior, not implementation details. When scopes are named 'add Stripe webhook handler' instead of 'process payments,' the team loses the ability to evaluate business importance. User-facing names make scope cutting and prioritization conversations productive because everyone can assess the value of what is being traded.
Keep the total scope count between 3 and 8 for a standard 6-week cycle. Fewer than 3 scopes means each scope is too large to provide meaningful progress signals. More than 8 means you are back to task-level tracking with all its overhead. The sweet spot is 4-6 scopes, each taking 1-5 days to complete.
Always slice vertically, never horizontally. A scope must include all the work needed to make one user-facing slice function end to end: data model, API, UI, and design. If your scopes look like 'all database work' and 'all front-end work,' nothing is independently completable and your hill chart will flatline until the final integration scramble.
Treat the initial scope map as a draft that will change. Teams that lock in scopes on day one of the cycle end up with scopes that do not match the actual shape of the work. Plan to revise scopes during the first 2-3 days of building as the team discovers the real boundaries through hands-on exploration.
Update hill chart positions at least twice per week. Stale hill charts provide no value. The discipline of moving dots forces team members to honestly assess whether they are still figuring out a scope or actively executing. If moving the dot feels hard, that is diagnostic information that something is stuck.
Explicitly mark each scope as must-have or nice-to-have when you create the scope map. This annotation costs nothing at the start of the cycle but saves enormous stress when time pressure arrives. Without it, every cutting decision becomes a negotiation instead of a reference to an earlier decision.
Do not create scopes for non-customer-facing infrastructure unless that infrastructure is genuinely independent and takes more than a few hours. Database migrations, deployment setup, and CI configuration should be absorbed into the scopes that need them, not split out into separate 'infrastructure' scopes that distort the hill chart.
Common Mistakes
Slicing horizontally instead of vertically, creating scopes like 'backend API' and 'frontend UI'
Correction
Horizontal scopes look logical from a technical perspective, but they prevent the team from finishing anything until everything integrates at the end. This mistake usually happens when the developer and designer map scopes separately instead of together. The signal to watch for is scopes that cannot be demoed independently. If completing a scope requires work from another scope to be visible, you have sliced horizontally.
Redraw scope boundaries so each one includes all layers needed to deliver one user-facing slice.
Creating too many scopes, effectively recreating a task list with different labels
Correction
When a team creates 12 or 15 scopes for a project, they have not actually changed their mental model from task tracking to scope tracking. They have just renamed their tasks 'scopes.' This happens when people decompose work by asking 'what are all the things we need to do?' instead of 'what are the 4-6 independently completable slices?' Watch for scope names that describe single implementation steps rather than user-facing capabilities. Merge related micro-scopes until you have 3-8 slices, each taking 1-5 days.
Locking in scopes on day one and never revising them
Correction
Teams coming from Scrum often treat the scope map like a sprint backlog: defined at the start and committed to. In Shape Up, scopes are a thinking tool that evolves. If your scope map on day 10 looks identical to day 1, either your pitch was extraordinarily well-shaped or (much more likely) the team is not updating the map to reflect what they are actually learning. Check in during the first few days specifically to ask whether the scopes still match the real boundaries of the work.
Rename, split, or merge as needed.
Naming scopes with technical jargon that only developers understand
Correction
Scopes named 'refactor polymorphic association' or 'implement WebSocket layer' obscure the user value being delivered. This makes scope cutting nearly impossible because non-technical stakeholders cannot evaluate what is being traded away. It also prevents the team from assessing whether the scope is truly essential or a gold-plating exercise. The fix is simple: restate every scope name as something a user would recognize.
'Real-time status updates' is the scope. The WebSocket layer is an implementation detail within it.
Treating scopes as assignments rather than as units of work anyone can pick up
Correction
Some teams assign each scope to one person and treat them as individual commitments. This defeats the purpose of scopes as a team-level progress tool. When one person's scopes are done and another person is struggling, the team cannot rebalance. Scopes should be owned by the team, not individuals.
Any team member should be able to pick up the next scope when they finish one. The signal that something is wrong is when one hill chart dot is stuck while others are done and nobody shifts to help.
Other Skills in This Method
Managing Six-Week Build Cycles
How to structure and execute fixed-time build cycles including setting appetites, forming small teams, and enforcing the circuit breaker when time runs out.
Planning Cool-Down Periods
How to structure the cool-down period between cycles for bug fixes, technical debt, exploration, and preparing the next round of shaped work.
Setting Appetites and Cutting Scope
How to set a time appetite for a project and then deliberately cut scope and identify must-haves versus nice-to-haves to fit within the fixed timebox.
Shaping Product Pitches
How to define problems, set appetites, and craft shaped pitches with fat-marker sketches and breadboarding before committing engineering resources.
Tracking Progress with Hill Charts
How to use hill charts to visualize whether scopes are in the uphill (figuring it out) or downhill (executing) phase and communicate progress without status meetings.
Running Betting Table Sessions
How to facilitate the betting table meeting where stakeholders review shaped pitches and decide which projects to commit to in the next cycle.
Using Breadboards and Fat-Marker Sketches
How to use breadboarding for flow design and fat-marker sketching for visual concepts to define solutions at the right level of abstraction during shaping.
Frequently Asked Questions
How do I map shape up scopes when the shaped pitch is vague or underspecified?
If the pitch lacks enough detail to identify scope boundaries, spend the first day or two spiking on the unknowns rather than forcing a scope map. Build a throwaway prototype, sketch the data model, or test an API integration. The joints in the work will become visible once you have hands-on contact with the problem. Do not treat a vague pitch as an excuse to skip scoping. Instead, let the scoping emerge from early exploration. If the pitch is so vague that you cannot identify even two independent slices after two days of exploration, escalate back to the shaper for clarification.
Should I map scopes before or after tracking progress with hill charts?
Scopes come first because hill charts need scopes to track. You cannot place dots on a hill chart if you have not defined what the dots represent. Map your initial scopes in the first day or two of the cycle, then immediately place them on a hill chart. The two tools are designed to work together: scopes define what you are building, and hill charts show where each scope stands. See [tracking progress with hill charts](/skills/tracking-progress-with-hill-charts) for the companion skill.
How long should scope mapping take at the start of a cycle?
The initial scope map should take 1-2 hours of focused team discussion, typically on the first or second day of the cycle. Do not spend a full day on it. The first map is a draft that will change as you start building. Spending more than 2 hours on the initial map usually means you are trying to plan at the task level rather than identifying the natural joints. Get a rough map, start building, and refine scopes during the first few days as you learn.
Can I use shape up scopes alongside Jira or Linear tickets?
Yes, but with discipline. Each scope becomes a parent item (an epic in Jira, a project in Linear), and you can create sub-tasks within it for your own tracking. The critical rule is that progress is measured at the scope level, not the task level. Do not report on how many tickets are closed. Report on which scopes have moved on the hill chart. If you find yourself spending more time managing tickets than building, you have too many tickets per scope. Keep it simple: 3-8 tasks per scope at most.
Why does my scope map keep drifting and changing throughout the cycle?
Some drift is expected and healthy, especially in the first week. If scopes are still being redefined in weeks 3 or 4, something deeper is wrong. Common causes: the shaped pitch had unresolved unknowns that were not flagged, the team is not spiking on uncertainties early enough, or the scopes were drawn along horizontal (technical) lines instead of vertical (user-facing) slices. Horizontal scopes create hidden dependencies that only surface during integration, forcing late rework. Recheck your scope boundaries for vertical integration and spike on any remaining unknowns immediately.
How do shape up scopes differ from user stories or sprint backlog items?
'). Scopes describe a slice of the solution that delivers that capability end to end. A single scope might correspond to multiple user stories, or one user story might span multiple scopes. The key difference is that scopes are defined by the team during building based on the actual shape of the work, not predefined by a product owner before the sprint. Scopes are also intentionally mutable: they can be renamed, split, merged, or cut. Sprint backlog items are treated as commitments.
What if my project only has one or two natural scopes?
If you genuinely cannot find more than two independent slices, it might be a small-batch project that does not need formal scope mapping. For projects with appetites of one or two weeks, a simple task list may suffice. However, if the project has a 6-week appetite and you only see one or two scopes, you are likely looking at the work at too high a level of abstraction. Try asking: within this large scope, what could we demo after 2-3 days of work? That question usually reveals sub-boundaries. If a single scope will take more than a week, it almost certainly has internal structure worth surfacing.